YOLO-Modus – ohne meinen Laptop einem KI-Agenten zu überlassen

Ein gewöhnlicher Entwicklungscontainer eignet sich gut, um Abhängigkeiten zu kapseln. Eine robuste Sicherheitsgrenze bildet er jedoch nicht automatisch.

Häufig wird der Docker-Socket des Hosts eingebunden, damit ein Tool innerhalb des Containers weitere Container bauen und ausführen kann. Damit erhält das Tool faktisch die Kontrolle über den Docker-Daemon des Hosts. Bei einem autonomen Agenten untergräbt das einen großen Teil der beabsichtigten Isolation.

Docker Sandboxes verfolgen einen anderen Ansatz. Jede Sandbox läuft in einer microVM mit einer eigenen Linux-Umgebung, einem eigenen Dateisystem, einem eigenen Netzwerk und einer eigenen Docker Engine.

In dieser Umgebung kann der Agent:

• Pakete mit sudo installieren
• Images bauen
• Container starten
• Docker Compose ausführen
• seine Entwicklungsumgebung verändern

All das ist möglich, ohne ihm Zugriff auf den Docker-Daemon des Hosts oder auf Dateien außerhalb des Arbeitsbereichs zu geben, den ich bewusst freigebe.

Das Versprechen lautet nicht, dass der Agent keinen Schaden anrichten kann. Es lautet, dass sein möglicher Schadensradius kleiner und leichter nachvollziehbar ist.

Docker Sandboxes bieten zwei nützliche Möglichkeiten, ein Projekt freizugeben.

Direktmodus

Das Projekt wird mit Lese- und Schreibrechten eingebunden. Änderungen des Agenten erscheinen sofort in meinem lokalen Checkout. Diesen Modus nutze ich für die alltägliche Entwicklung, weil der Agent und ich mit denselben Dateien arbeiten können.

Der Nachteil ist klar: Das Repository bleibt Teil des möglichen Schadensradius.

Klonmodus

Bei noch unerprobten Agenten, potenziell destruktiven Experimenten oder parallelen Aufgaben bietet der Klonmodus eine robustere Sicherheitsgrenze. Das Repository des Hosts wird schreibgeschützt eingebunden, während der Agent in einem privaten Klon innerhalb der Sandbox arbeitet. Die Änderungen erreichen meinen lokalen Checkout erst, wenn ich sie ausdrücklich übernehme.

Der Klonmodus schützt das Repository vor Änderungen, nicht vor Einsichtnahme. Dateien im Repository können über die schreibgeschützte Einbindung weiterhin sichtbar sein – auch solche, die Git ignoriert. Secrets gehören deshalb nicht in den Arbeitsbereich.

Eine leere Sandbox löst das Isolationsproblem, nicht aber die Einrichtung.

Ich wollte nicht zu Beginn jeder neuen Sitzung ausführlich erklären müssen, welche nativen Bibliotheken das Projekt benötigt, welche Toolchain-Versionen für den Build erforderlich sind oder wie die Umgebung für lokale Modelle konfiguriert werden muss.

Docker Sandboxes unterstützen wiederverwendbare Projektkonfigurationen, sogenannte Kits. Mein Projekt-Kit beschreibt die Werkzeuge und Rahmenbedingungen, die der Agent benötigt, darunter:

• native Build-Abhängigkeiten
• Rust-Werkzeuge
• Abhängigkeiten für Browser-Tests
• Umgebungsvariablen
• den während der Einrichtung benötigten Netzwerkzugriff

Wichtiger als die konkrete Konfiguration ist das Prinzip: Das Wissen über die Einrichtung wird im Projekt festgehalten, statt jedes Mal aus dem Gedächtnis rekonstruiert zu werden.

Ein KI-Agent kann einen ersten Entwurf für eine projektspezifische spec.yaml erstellen, indem er das Repository untersucht und gezielt nach allem fragt, was sich daraus nicht ableiten lässt: Systempakete, Build- und Testbefehle, Hintergrunddienste, Netzwerkzugriffe, Ports und vom Host verwaltete Zugangsdaten.

Bei einer Webanwendung kann das Kit beispielsweise Playwright und einen Headless-Browser in der Sandbox bereitstellen. So kann der Agent Seiten rendern, End-to-End-Tests ausführen und Screenshots für die visuelle Kontrolle aufnehmen. Sofern der ausgewählte Agent und das Modell Bildeingaben unterstützen, kann er die Screenshots auch selbst prüfen. Dennoch muss die erzeugte Datei überprüft und mit sbx kit validate validiert werden.

Das Kit dient zugleich als Notizbuch für die Fehlersuche

Die erste Version des Kits war deutlich kleiner. Immer wenn eine Annahme an der Realität scheiterte, kam etwas hinzu.

Eine Version ersetzte PATH, statt die Variable zu erweitern. Dadurch verschwanden Pfade, die von der Sandbox-Laufzeitumgebung hinzugefügt worden waren, und der Coding-Agent konnte nicht mehr korrekt starten.

Eine andere Version setzte RUSTFLAGS global. Damit wurde versehentlich ein projektspezifisches CI-Flag überschrieben, mit dem Tests ausgeschlossen werden, die echte Anfragen an Modellanbieter senden.

Diese Probleme hätten im Shell-Verlauf oder in persönlichen Notizen verbleiben können. Stattdessen sind die Korrekturen heute in der Konfiguration selbst festgehalten – samt einer Erklärung, warum sie nötig sind.

Genau darin liegt der eigentliche Wert des Kits. Es installiert nicht nur Software, sondern macht Wissen über die Umgebung zu Projektcode, der sich prüfen, versionieren und verbessern lässt.

Im Entwicklungsalltag erstelle ich mit dem Projekt-Kit eine benannte Sandbox:

# Weitere unterstützte Agenten sind unter anderem claude, gemini und opencode.
sbx run codex \
  --name aitopus \
  --kit ./sandbox/aitopus/

Dabei wird das Projekt direkt eingebunden, sodass die Änderungen des Agenten in meinem Working Tree erscheinen.

Wenn ich eine robustere Sicherheitsgrenze benötige, kann ich stattdessen eine separate Sandbox im Klonmodus erstellen:

sbx run --clone --no-share-skills codex \
  --name aitopus-review \
  --kit ./sandbox/aitopus/

Die Ersteinrichtung kann aufwendig sein, weil die Umgebung native Toolchains, Browser-Binärdateien und Build-Abhängigkeiten umfasst. Dafür bleiben der Zustand der Sandbox und die Build-Caches zwischen den Sitzungen erhalten.

Nach der ersten Einrichtung kann ich mich erneut mit der benannten Sandbox verbinden, statt die Umgebung von Grund auf neu aufzubauen.

Ein Coding-Agent benötigt weiterhin Zugriff auf das Internet. Er muss unter Umständen den verwendeten Modellanbieter, Paket-Registrys, Quellcode-Repositorys und Release-Archive erreichen.

Bei sensibleren Sitzungen beginne ich mit einer restriktiven Netzwerkrichtlinie und erlaube nur die Dienste, die der Agent und der Build tatsächlich benötigen.

Der von Docker Sandboxes bereitgestellte Credential Proxy kann unterstützte Zugangsdaten auf dem Host belassen und nur für genehmigte Anfragen bereitstellen. Das ist besser, als einen langlebigen API-Schlüssel in die Sandbox zu kopieren und später nicht mehr zu wissen, wo er gespeichert wurde.

Auch Netzwerkkontrollen haben Grenzen. Ein freigegebener Dienst kann weiterhin alle Informationen empfangen, die der Agent an ihn sendet. Weniger zulässige Ziele verringern das Risiko einer Offenlegung; das macht jedoch nicht jede ausgehende Anfrage vertretbar.

Eine Sandbox begrenzt die Zugriffsmöglichkeiten, garantiert aber keinen korrekten Code. Ich behandle die Arbeit des Agenten wie einen Pull Request aus einer nicht vertrauenswürdigen Quelle.

• Korrektheit. Der Agent kann weiterhin eine Abhängigkeit mit Sicherheitslücke einführen, eine Anforderung missverstehen oder Code erzeugen, der zwar alle Tests besteht, aber gegen das vorgesehene Design verstößt.
• Auswirkungen auf den Host. Im Direktmodus kann der Agent weit mehr verändern als nur die üblichen Quelldateien. Git-Hooks, CI-Workflows, IDE-Tasks, Build-Skripte und Agentenkonfigurationen können später allesamt Code auf dem Host ausführen.
• Änderungen am Repository. Der Klonmodus verhindert direkte Schreibzugriffe auf den Checkout des Hosts. Alles, was später in den Host-Checkout übernommen wird, muss trotzdem geprüft werden.
• Zielplattformen. Eine Linux-Sandbox bietet eine sicherere und konsistentere Arbeitsumgebung, beweist aber nicht, dass die fertige Anwendung auf jeder Zielplattform korrekt funktioniert.

Berechtigungsabfragen sind hilfreich, wenn keine robustere Sicherheitsgrenze vorhanden ist. Sie sind jedoch kein guter Ersatz für eine bewusst gestaltete Sicherheitsgrenze.

Innerhalb einer eigenen microVM kann der Agent weitgehend autonom arbeiten. Er kann Compiler installieren, installierte Pakete ändern, Container bauen und einen vollständigen Debugging-Zyklus durchlaufen, ohne nach jedem Befehl auf eine Freigabe warten zu müssen.

Ich gebe ihm bewusst Zugriff auf das Projekt-Repository, nicht aber auf den Docker-Daemon des Hosts oder projektfremde Dateien. Auch auf den Rest meines Rechners erhält er keinen uneingeschränkten Zugriff.

Diese Arbeitsweise ist nicht nur sicherer. Sie ist auch produktiver.

Ich muss seltener Routineaktionen freigeben, verbringe weniger Zeit damit, lokale Toolchains zu reparieren, und muss die Entwicklungsumgebung in meinen Prompts nicht immer wieder erklären. Der Agent hat genug Freiraum zum Arbeiten; ich behalte eine klar überprüfbare Sicherheitsgrenze.

Dasselbe Prinzip gilt für lokale KI: festlegen, wo die Berechnung stattfindet, entscheiden, welche Informationen die Grenze überschreiten dürfen, und den Rest unter lokaler Kontrolle behalten.

Mit dieser Variante des YOLO-Modus fühle ich mich wohl:

kein blindes Vertrauen in einen Agenten, sondern die Gewissheit, selbst bestimmt zu haben, innerhalb welcher Grenzen sich seine Fehler auswirken können.

Hinweis: Kits für Docker Sandboxes sind derzeit noch experimentell. Prüfen Sie die aktuelle Dokumentation, bevor Sie sich im Produktiveinsatz auf bestimmte Befehle oder Konfigurationsfelder verlassen.