Die Sandbox-Wette

25. Januar 2026: die Wette

Zwei Monate nach dem Start von LikeClaw trafen wir die Entscheidung, die das Produkt definieren würde. Wir setzten alles auf die E2B-sandboxed Ausführung.

Bis zu diesem Zeitpunkt führten unsere KI-Agenten Aufgaben auf relativ traditionelle Weise aus. Ab diesem Punkt lief jede Aufgabe — jede Codeausführung, jede Dateioperation, jeder Hintergrundjob — in einem isolierten E2B-Sandbox-Container.

Das war kein Sicherheitsfeature, das wir einfach hinzugefügt haben. Es war eine grundlegende architektonische Entscheidung, die die Funktionsweise der gesamten Plattform veränderte. Und es war die beste Entscheidung, die wir getroffen haben.

Warum Sandboxing wichtiger ist als alles andere

Schau dir die Landschaft der KI-Agenten Anfang 2026 an. Ein Muster wiederholt sich überall: Benutzer geben KI-Agenten uneingeschränkten Zugriff auf ihre Maschinen.

OpenClaw läuft auf deinem lokalen System. Es liest deine Dateien. Es führt Code mit deinen Berechtigungen aus. Es speichert API-Schlüssel im Klartext. Sicherheitsforscher haben weit verbreitete Sicherheitsanfälligkeiten in der Plattform und ihrem Marktplatz dokumentiert, was Warnungen von mehreren Sicherheitsorganisationen zur Folge hatte.

Die Ursache liegt nicht darin, dass OpenClaw schlecht programmiert ist. Es liegt daran, dass die Architektur grundsätzlich unsicher ist. Wenn du einem KI-Agenten direkten Zugriff auf dein System gibst, hat jeder Fehler — sei es durch die KI, durch einen Skill-Autor oder durch einen Prompt-Injection-Angriff — eine unbegrenzte Auswirkung. Ein schlechter Skill kann Malware auf deinem Gerät installieren. Eine Prompt-Injection kann deine SSH-Schlüssel auslesen. Ein halluzinierter Befehl kann deine Dateien löschen.

Sandboxing beseitigt die gesamte Risikokategorie.

Wie unsere Sandboxes funktionieren

Wenn du eine Aufgabe auf LikeClaw ausführst, passiert Folgendes:

Eine frische Sandbox wird erstellt. Ein isolierter E2B-Container wird in weniger als zwei Sekunden hochgefahren. Er hat sein eigenes Dateisystem, seinen eigenen Prozessraum, sein eigenes Netzwerk. Er ist vollständig isoliert von jeder anderen Sandbox und von jedem anderen Benutzer.

Deine Arbeitsbereichsdateien werden synchronisiert. Die Dateien in deinem Arbeitsbereich werden in die Sandbox kopiert. Die KI kann sie lesen, ändern, neue erstellen. Aber nur innerhalb der Sandbox.

Die KI führt die Aufgabe aus. Innerhalb der Sandbox hat die KI volle Möglichkeiten. Sie kann Code ausführen, Pakete installieren, Netzwerk-Anfragen stellen, Dateien lesen und schreiben. Es ist eine voll funktionsfähige Umgebung. Der Unterschied ist, dass “voll funktionsfähig” die Sandbox bedeutet, nicht dein Gerät.

Ergebnisse werden zurück synchronisiert. Wenn die Aufgabe abgeschlossen ist, werden die Dateien, die die KI erstellt oder geändert hat, in unseren verschlüsselten Speicher zurück in deinen Arbeitsbereich synchronisiert.

Die Sandbox wird zerstört. Weg. Jeder Prozess beendet. Jede Datei gelöscht. Jede Netzwerkverbindung geschlossen. Nichts bleibt bestehen. Nichts leckt. Nichts verweilt.

Wenn die KI etwas falsch macht — bösartigen Code ausführt, einer Prompt-Injection folgt, einen schlechten Skill ausführt — ist der Schaden auf eine Sandbox beschränkt, die in Sekunden zerstört wird. Dein Gerät, deine Dateien, deine API-Schlüssel, deine Anmeldeinformationen sind niemals in Gefahr.

Die technische Herausforderung

Sandboxing klingt einfach. “Führe es einfach in einem Container aus.” In der Praxis war es die komplexeste technische Herausforderung des gesamten Projekts.

Dateisynchronisation. Benutzer benötigen ihre Dateien in der Sandbox, und sie benötigen die Ausgaben der KI zurück in ihrem Arbeitsbereich. Diese bidirektionale Synchronisation muss schnell, zuverlässig und konfliktfähig sein. Wir haben eine VFS (Virtual File System) Synchronisationsschicht entwickelt, die Änderungen in beide Richtungen überwacht.

Ausführung von Hintergrundaufgaben. Geplante Aufgaben laufen ebenfalls in Sandboxes. Eine Aufgabe, die um 3 Uhr morgens läuft, muss eine Sandbox hochfahren, Dateien synchronisieren, ausführen, Ergebnisse zurück synchronisieren und aufräumen — alles, ohne dass ein Benutzer online ist.

Leistung. Die Erstellung von Sandboxes fügt Latenz hinzu. Wir haben die Hochlaufzeit auf unter zwei Sekunden optimiert. Benutzer bemerken es kaum. Aber um dorthin zu gelangen, waren sorgfältiges Template-Management, verzögerte Initialisierung und Vorwärmstrategien erforderlich.

Kosten. Jede Sandbox kostet Rechenressourcen. Wir mussten Sicherheit (immer Sandbox) mit Wirtschaftlichkeit (Sandboxes kosten Geld) in Einklang bringen. Die Antwort waren Sandbox-Limits pro Tier — kostenlose Benutzer erhalten eine festgelegte Anzahl von Ausführungen, Pro-Benutzer erhalten mehr, Power-Benutzer erhalten unbegrenzte.

Die Grenze im Sand

Hier ist das Ding mit der Sicherheit: man kann es nicht halbherzig machen.

Man kann einige Aufgaben sandboxen und andere nicht. Man kann kostenlose Benutzer sandboxen, aber bezahlte Benutzer Rohzugriff gewähren. Man kann die Codeausführung sandboxen, aber nicht den Datei Zugriff. Jede Lücke im Sandbox-Modell wird zu einem Angriffspunkt.

Also haben wir eine Grenze gezogen: alles läuft in einer Sandbox. Keine Ausnahmen. Keine Hintertüren. Kein “Expertenmodus”, der die Isolation umgeht.

Das bedeutet, dass einige Dinge etwas langsamer sind als lokal auszuführen. Das bedeutet, dass einige Dinge einen zusätzlichen Schritt erfordern (Dateien hinein und heraus synchronisieren). Das bedeutet, dass wir nicht den “vollen Maschinenzugriff” bieten können, den lokale KI-Agenten bereitstellen.

Das ist uns recht. Denn wir können auch keine Malware-Installation, keinen Diebstahl von Anmeldeinformationen oder keine Systemkompromittierung anbieten. Und unsere Benutzer auch nicht.

0 bösartige Skills. 0 kompromittierte Systeme. 0 Sicherheitsvorfälle.

Das ist die Sandbox-Wette. Und sie zahlt sich aus.