§ Plattform / Sicherheit
Sicherheit per Konstruktion, nicht per Richtlinie.
Scellis führt Code, den andere Leute geschrieben haben, auf deinem Rechner aus und gibt KI-Assistenten echte Kontrolle — Sicherheit kann hier also kein Policy-Dokument sein. Sie ist als Verweigerung gebaut: Nicht vertrauter Code läuft dort, wo ein Netzaufruf strukturell unmöglich ist, deine Zugangsdaten existieren auf keinem Server, wer aufruft, ermittelt der Server selbst, und kein Agent kann je Geld bewegen. Was zu verteidigen bleibt, ist klein, geschichtet und veröffentlicht — samt seiner Grenzen.
Eine bewusst kleine Angriffsfläche
Die Haltung beginnt mit Subtraktion. Scellis vergibt nie ein Passwort — der Login ist an GitHub delegiert, Account-Wiederherstellung und Zwei-Faktor liegen also bei dem Identity-Provider, dem du ohnehin vertraust. Konnektor-Geheimnisse werden auf deinem Gerät verschlüsselt und nie synchronisiert. Und weil die Berechnung local-first ist, verlangt Scellis nie, dass du Daten irgendwohin hochlädst: Was du nicht teilst, existiert schlicht auf keinem Server — und was nie existiert, kann weder erbeutet noch beschlagnahmt noch stillschweigend aufbewahrt werden.
Was ausgeliefert wird, ist genauso subtraktiv: Das Studio enthält überhaupt keine Third-Party-Analytics und darf nur mit einer einzigen, getesteten Liste von Zielen sprechen — jede andere Adresse weist der Browser selbst ab, eine Schicht unterhalb unseres eigenen Codes. Produkt-Telemetrie ist Opt-in und trägt keine personenbezogenen Daten. Was du hier vertrauen sollst, ist klein genug zum Aufzählen — und diese Seite zählt es auf.
Sieben Schichten, jede verweigert für sich
| Schicht | Mechanismus | Was sie verweigert |
|---|---|---|
| Identität | Jede Anfrage trägt ein Subjekt, das der Server etabliert hat — eine Session, einen gescopten API-Key oder ein zurechenbares anonymes Token. | Gefälschte oder anonyme Schreibzugriffe |
| Isolation | Row-Level Security in der Datenbank: Sichtbarkeit, Mitgliedschaft und Freigaben werden dort geprüft, wo die Daten liegen. | Lesen oder Schreiben über Konten hinweg |
| Compute-Sicherheit | Trust-Stufen, eine Sandbox, aus der das Netz herausgenommen wurde, eine Effekt-Policy und Ressourcen-Budgets. | Daten, die über nicht vertrauten Code abfließen |
| Integrität | Alles ist nach dem Hash seiner Bytes benannt; jeder Ladevorgang verifiziert diesen Hash vor der Nutzung. | Stille Manipulation oder Korruption |
| Nachvollziehbarkeit | Ein Append-only-Strom von Änderungen plus ein abfragbares Audit-Log. | „Wir wissen nicht, was passiert ist“ |
| Missbrauchs-Resistenz | Rate-Limits und gescopte Endpunkte auf dem Server; anonyme Identitäten bekommen strengere Budgets. | Flooding und Ressourcen-Missbrauch |
| Kommerzieller Zugriff | Die Entitlement-Prüfung läuft auf dem Server; der Client ist kosmetisch und gilt als fälschbar. | Im Client gefälschte Tarife oder Bezahlfunktionen |
Schichten versagen unabhängig: Ein Bug oberhalb trifft unterhalb auf die nächste Verweigerung. Keine Zeile ist eine Höflichkeit der Oberfläche.
Keine einzelne Schicht trägt allein. Identität wird auf dem Server etabliert und in jede Anfrage eingefädelt. Mandanten-Isolation setzt die Datenbank selbst durch, unterhalb jeder Route — ein Bug in der Oberfläche kann Zugriff nicht ausweiten, denn die Schicht, die verweigert, ist eine, um die kein Client herumkommt. Mit einer bestimmten Person zu teilen, ist eine Kante, die die Datenbank prüft — nie ein Flag, das ein Client bloß anzeigt.
Governance fährt auf derselben Durchsetzung. Eine Workspace-Richtlinie kann ausschließlich signierte Inhalte verlangen, Netzwerk-Effekte verbieten oder deterministische Ausführung festschreiben — und die Oberfläche kann sie nicht übersteuern, denn geprüft wird dort, wo die Daten liegen. Jede Änderung hinterlässt ein Event, das Audit-Log ist abfragbar — „wir wissen nicht, was passiert ist“ ist ein wegkonstruierter Fehlermodus, keine Hoffnung der Incident-Response.
User-Code läuft dort, wo es kein Netz gibt
Das harte Problem einer erweiterbaren Plattform: Alles, was Nutzer selbst schreiben — Kernels, Operatoren, Viewer, Konnektoren — ist Code, und er läuft auf deinem Rechner. Scellis führt ihn an einem Ort aus, aus dem die Netzwerk-Aufrufe des Browsers entfernt wurden: fetch, WebSocket und XMLHttpRequest sind dort schlicht nicht vorhanden — ein Netzaufruf aus User-Code ist strukturell unmöglich, nicht nachträglich erkannt, sondern gar nicht ausdrückbar. Die einzige Tür ist ein Gate, dem du zustimmen musst.
Effekte sind die ganze Policy: deklariert von dem, was sie nutzt, bei Unbekanntem standardmäßig verweigert, im entscheidenden Moment freigegeben und danach festgehalten. Die Berechnung selbst wird nie beschränkt — die Sandbox begrenzt Ressourcen und Seiteneffekte, nie Ausdruckskraft. Und Vertrauen wird verdient, nicht unterstellt: Code in der Sandbox weitet sein Standing über Konformitäts-Evidenz aus, nie darüber, wer ihn geschrieben hat.
Auch Komposition kann Privilegien nicht waschen. Was aufgerufen wird, läuft auf der strengsten Trust-Stufe seiner eigenen Aufrufkette — ein unverifizierter Helfer bleibt in der Sandbox, selbst wenn vertrauter Code ihn aufruft — und Effekte summieren sich entlang dieser Kette: Ein „purer“ Block kann keinen Netzaufruf über eine Abhängigkeit einschmuggeln. Dieselben Prüfungen gelten für die Inhalte, die wir mitliefern: Was du schreibst und was wir ausliefern, ist eine Pipeline — unsere zu privilegieren wäre ein Bug.
Signierte Inhalte, verdientes Vertrauen
Alles, was du installierst, kommt als signiertes, versioniertes Pack. Signatur und Content-Hash werden beide verifiziert, bevor irgendetwas aktiv wird, und was ein Bundle tatsächlich ist, entscheidet das Dekodieren und Validieren — nie der Dateiname. Signierschlüssel sind gewöhnliche Katalog-Einträge, ihre Rotation ist also eine gewöhnliche Katalog-Änderung; die private Hälfte bleibt auf dem Gerät der Autorin und wird nie synchronisiert.
Vertrauen ist ein lesbares Signal, kein Bauchgefühl: unverified → community → verified → official, verdient über Konformitäts-Evidenz und Review, unabhängig davon, wer es geschrieben hat — Community-Arbeit kann verified erreichen. Und weil die Bytes hinter einem veröffentlichten Hash nie still ausgetauscht werden können, bekommt eine Kompromittierung einen echten Kanal statt eines leisen Patches: Ein Advisory benachrichtigt alle, die daran gepinnt sind, markiert den Eintrag und kann neue Installationen blockieren — während alle, die es schon haben, weiterarbeiten und mit voller Information entscheiden.
Dasselbe Misstrauen gilt für Prosa. Jeder Text, den andere geschrieben haben — Beschreibungen, Notizen, Reviews, Method-Cards —, läuft durch einen einzigen Renderer, der alles Ausführbare entfernt, bevor es die Seite erreicht. Eine bösartige Beschreibung kann dein Studio nicht übernehmen, weil es keinen ungefilterten Pfad gibt, auf dem sie hereinkäme.
Volle Macht für Agenten — nie dein Geld
Der Copilot hält dieselben Verben wie du — seine Sicherheit kann also nicht darauf ruhen, dass er weniger kann. Durchgesetzt wird auf dem Server, immer: die Zustimmungsstufen und der serverseitig ermittelte Aufrufer werden bei jeder Anfrage geprüft, und Geld ist jedem maschinellen Aufrufer verwehrt — ein prompt-injizierter Copilot, ein geleakter API-Key, eine Headless-Session: Keiner von ihnen kann kaufen.
Der Zugang externer Agenten über MCP ist Ende-zu-Ende spezifiziert und wird gerade für den Early Access gebaut; wie diese Oberfläche generiert wird und was ein Agent anfassen darf, steht auf der API-Seite. Was keine Architektur eliminieren kann — ein injizierter Agent missbraucht einen Scope, den du selbst freigegeben hast —, steht klar in den ehrlichen Grenzen, statt weggerundet zu werden.
Was du bekommst — per Konstruktion
| Eigenschaft | Garantie |
|---|---|
| Signierte Inhalte | Signatur und Content-Hash werden vor jeder Installation verifiziert; was ein Bundle ist, entscheidet die Validierung, nie der Dateiname. |
| Delegierte Identität | Der Login ist GitHub OAuth; Wiederherstellung und Zwei-Faktor liegen beim Identity-Provider — Scellis vergibt nie ein Passwort. |
| Zugangsdaten bleiben bei dir | Konnektor-Geheimnisse werden auf deinem Gerät mit AES-256-GCM verschlüsselt und nie synchronisiert — es gibt keine Server-Kopie, die man stehlen könnte. |
| Ein Studio, das niemanden anruft | Keine Third-Party-Analytics; die App spricht nur mit einer getesteten Liste von Zielen — den Rest weist der Browser selbst ab. |
| Löschen, das es ernst meint | Personenbezogene Daten liegen in einem Speicher pro Person, dessen Schlüssel zerstört werden kann; Löschen zerstört den Schlüssel, und Append-only-Logs tragen nie identifizierende Daten. |
| Atomare Engine-Updates | Eine neue Engine wird vor der Aktivierung gegen einen signierten Hash verifiziert und dann in einem Schritt getauscht — eine halb aktualisierte Engine läuft nie. |
| Isolation in der Datenbank | Row-Level Security unterhalb jeder Route — um die Schicht, die verweigert, kommt kein Client herum. |
Jede Eigenschaft unten benennt die Struktur, die sie durchsetzt, und wo eine Garantie eine Grenze hat, wird die Grenze veröffentlicht statt aufgerundet. Das Engineering hinter jeder Zeile steht im Security-Deep-Dive.
Eine Regel zieht sich durch alles: Ein Hash personenbezogener Daten ist weiterhin personenbezogen — wir nennen ihn nie „anonymisiert“. Löschen ist als Schlüsselzerstörung konstruiert: Identifizierende Daten liegen in einem Speicher pro Person, dessen Schlüssel zerstört werden kann, und die Append-only-Logs tragen sie von vornherein nicht — Löschen löscht also wirklich, statt nur zu verstecken.
Wenn etwas schiefgeht, ist der Weg veröffentlicht
Öffentliche Bereiche bekommen ein Governance-Rückgrat statt Improvisation pro Bereich — und es landet im Early Access genau in dieser Form: Alles Öffentliche ist meldbar, jede Meldung landet in einer Review-Queue, jede Maßnahme trägt eine schriftliche Begründung, und jede betroffene Autorin hat einen Einspruchsweg. Die Grenze hält auch unter Durchsetzung — eine Sperrung entzieht Plattform-Dienste wie Sync, Publishing und Pools, während lokales Rechnen auf schon vorhandenen Inhalten bedingungslos weiterläuft. Moderation beschränkt nie die Berechnung, und bereits installierte Inhalte werden nie ferngelöscht.
Die Plattform hält sich an dieselbe Disziplin. Eine Verletzung des Schutzes personenbezogener Daten wird der Aufsichtsbehörde auf der 72-Stunden-Uhr der DSGVO gemeldet und den Betroffenen, wenn das Risiko hoch ist — das Audit-Rückgrat existiert genau dafür, dass diese Bewertung beantwortbar ist. Schwachstellen-Meldungen laufen als koordinierte Offenlegung mit erklärtem Triage-und-Fix-Servicelevel: eine Bestätigung für jede Meldung, der Fix vor dem öffentlichen Detail, Namensnennung für alle, die sie möchten.
Etwas gefunden? Schreib an security@scellis.com — was du beobachtet hast, die Schritte zum Reproduzieren und den betroffenen Teil der Plattform. Wer in gutem Glauben meldet, wird als Partner der koordinierten Offenlegung behandelt, nie als Angreifer. Für alles, was keine Schwachstelle ist — Presse, Partnerschaften, Fragen — nutze die Kanäle auf der Kontaktseite.