- Coding-Agents dürfen lokal fast alles, was auch du darfst, und ihr Verhalten ist kaum vorhersehbar. Deshalb lohnt sich echte Isolation statt ständiger Rückfragen.
- Docker Sandboxes (
sbx) liefern genau das out of the box: MicroVM-Isolation vom Host, Dateizugriff nur aufs Projektverzeichnis, granulare Netzwerk-Policies und einen Proxy, der Credentials vor dem Agenten verbirgt. - Diese Kombination macht den YOLO-Modus (
--dangerously-skip-permissions) weitgehend gefahrlos und unterstützt neun Agenten, darunter Claude Code, Codex und Copilot. -
sbxist noch jung (Moving Target, Lizenz nicht final) und stellenweise unbequem, bietet aber deutlich mehr Sicherheit bei weniger Aufwand als Container oder agentenseitige Sandbox-Features.
Meine Kollegin Joy Heron hat vor Kurzem in „Ich habe meine KI-Agenten in eine Sandbox gesteckt" beschrieben, wie sie sich eine eigene, isolierte Umgebung für ihre Coding-Agents gebaut hat. Ihr Fazit: Es funktioniert, kostet aber Zeit beim Setup.
Inzwischen gibt es ein fertiges Werkzeug: Docker Sandboxes, kurz sbx. Es funktioniert out of the box und ist super einfach zu benutzen. Bevor ich zeige, was sbx konkret leistet, lohnt sich nochmal ein Blick auf das Problem im Detail.
Agents können (fast) alles
Ein lokaler Agent kann fast alles ausführen und auf fast alles zugreifen, was auch der User kann, der ihn gestartet hat. Man kann argumentieren, dass das prinzipiell für alle Binaries gilt, die man startet. Aber das Verhalten des Agents wird grösstenteils vom zugrundeliegenden Modell bestimmt und ist damit kaum vorhersehbar oder prüfbar.
Erschwerend kommt hinzu: Agents sind kreativ. Die Rückfragen vor kritischen Aktionen (etwa „Soll ich diesen Befehl ausführen?") sind immerhin im Client-Code fest verankert. Aber Rückfragen passen nicht zu Autonomie und werden nach einer Weile nicht mehr aufmerksam gelesen. Ausserdem schützen sie nicht davor, dass Agents mitunter sehr kreativ werden, wenn es ihrer Vorstellung vom Ziel dient. Mir ging es selbst so, als ich zusah, wie mein Agent gerade eine Office-Software auf meinem Mac installierte und ich das zuvor sogar erlaubt hatte, obwohl ich es eigentlich gar nicht wollte. Besser wäre es, vorab klare Regeln festzulegen und den Agenten dann arbeiten zu lassen. Neben den Dateizugriffen gilt das auch für die Nutzung des Netzwerks.
Docker Sandboxes (sbx) als fertige Lösung
sbx ist ein Tool von Docker Inc. Es basiert nicht auf Containern, wie man aus dem Namen vermuten könnte, sondern auf MicroVMs. Das bedeutet kein gemeinsamer Kernel mit dem Host, aber trotzdem wenig Overhead - deutlich leichtgewichtiger als eine klassische VM. Dazu kommen viele durchdachte Konventionen, die die Nutzung im Alltag einfach machen. Das Tool ist noch relativ jung und hat gerade erst die Early-Access-Phase verlassen. Es ist nicht Open Source, aber laut Docker wird das Tool dauerhaft auch kommerziell frei verwendbar bleiben.
Wo hilft sbx konkret?
| Bereich | Schutz |
|---|---|
| Dateisystem | Nur das gemountete Projektverzeichnis ist zugänglich |
| Netzwerk | Konfigurierbare Policies (Open / Balanced / Locked Down) |
| Credentials | Ein Proxy auf dem Host injiziert Tokens — sie sind in der VM selbst nie sichtbar |
| Host-System | Vollständig isoliert von der VM |
sbx schützt die Hostmaschine, begrenzt den Zugriff auf ein Verzeichnis und erlaubt es, Netzwerkzugriffe granular per Policy zu steuern, statt sie dem Agenten komplett zu überlassen. Damit hat man Werkzeuge, um zumindest Teile des von Simon Willison beschriebenen Risiko-Dreiecks („Lethal Trifecta") kontrollieren zu können.
Diese Kombination aus Isolation, Credential-Proxy und Netzwerk-Policies bietet aus meiner Sicht genug Kontrolle, um den sogenannten YOLO-Modus weitgehend gefahrlos zu aktivieren - --dangerously-skip-permissions, wie es bei Claude heisst, ist in sbx sogar der Standard. sbx unterstützt aktuell neun Agenten (Stand: Juli 2026), inklusive Claude Code, Codex und Copilot. Andere Agenten wie pi können über eigene Images ebenso genutzt werden.
Besondere Merkmale
Ein einfaches, aber sehr nützliches Feature ist, dass die Pfade innerhalb der Sandbox den Pfaden ausserhalb gleichen, obwohl innerhalb der Sandbox nur das Projektverzeichnis sichtbar ist. So kann man absolute Pfade z. B. in lokalen Config-Files nutzen.
VMs werden ad hoc angelegt, wenn man per sbx einen Agenten startet. Es gibt eine schicke Übersicht in einem ASCII-Dashboard. Darin kann man alle VMs auflisten, starten, stoppen und löschen sowie die Nutzung des Proxys anschauen und Netzwerkregeln bearbeiten.
Um die Credentials für den Zugang zu APIs - etwa zum Modell oder zu MCP-Servern - vor dem Agenten zu verstecken, injiziert der Proxy die Authentication-Tokens in die Aufrufe. Das führt dazu, dass man sich nur einmalig bei einem Provider einloggen muss und dann in allen VMs angemeldet ist.
Vor- und Nachteile
Vorteile:
- Gute Isolation bei trotzdem wenig Overhead (MicroVM, kein Container)
- Der Verzeichnispfad ist in VM und Host identisch - sehr praktisch im Alltag
- Fertige Templates für Claude, Codex und weitere Agents
- Ein Proxy für den Netzwerkzugriff verbirgt Credentials und Tokens vor dem Agenten
- Network Policies lassen sich feingranular konfigurieren
- VMs werden on the fly angelegt
- Ein eigener Docker-Host läuft innerhalb der VM, sodass kein Docker-in-Docker nötig ist, wenn der Agent selbst Tests oder Builds ausführen soll
- Ein ASCII-Dashboard zeigt jederzeit den Überblick, inklusive Proxy- und Netzwerk-Policies
- Der Agent selbst lässt sich anpassen (z. B. bei Claude)
Nachteile:
- Noch sehr neu; es gibt regelmässig neue Builds; stabil, aber ein Moving Target
- Die Lizenz ist noch nicht final, vermutlich bleibt die CLI aber frei nutzbar
- Wer viele Projekte hat, bekommt auch viele VMs
- VMs müssen einzeln aktualisiert werden (was sich davon automatisieren lässt, ist noch offen)
- Es gibt noch keine Lösung, um einzelne Dateien im Projektordner vor dem Agenten auszublenden oder zu maskieren - als Workaround bleiben Symlinks
- Die Isolation ist stellenweise unbequem: IDE auf dem Host, Agent in der VM — das Verzeichnis ist zwar geteilt, das Netzwerk aber getrennt, was gelegentlich stört
- Copy & Paste ist je nach Host-Betriebssystem umständlich
Alternativen im Vergleich
Docker-Container. Container teilen sich den Kernel mit dem Host, die Isolation ist damit schwächer als bei einer MicroVM. Ausserdem gibt es keinen eigenen Docker-Daemon, sodass für Container-Builds wieder Docker-in-Docker nötig würde. Ein fertiges Agent-Template oder einen Credential-Proxy muss man sich selbst bauen. Machbar, aber deutlich mehr Aufwand für weniger Sicherheit.
Claude --sandbox. Ein agentenseitiges Feature, kein systemweiter Schutz - bei mir hat es in der Praxis ohnehin nicht so funktioniert wie beschrieben. Es schränkt die Tool-Nutzung innerhalb des Agenten ein, bietet aber keine echte Isolation und keinen Schutz vor Prompt Injection aus externen Quellen. Dazu kommt der Vendor-Lock-in auf Claude.
Cloud-Sandboxes wie GitHub Codespaces oder E2B.dev. Diese bieten echte Isolation in der Cloud und damit kein lokales Risiko, dafür aber auch keinen Zugriff auf lokale Ressourcen wie das eigene Dateisystem oder lokale Dienste. Latenz und Kosten hängen von der Nutzung ab.
Konfiguration & Anpassung
sbx lässt sich pro Projekt anpassen: Agent-Settings - etwa ein .claude- oder .agent-Ordner samt Skills - landen einfach im Projektverzeichnis und geben dem Agenten Kontext und Grenzen mit. Die Netzwerk-Policy lässt sich pro Projekt überschreiben, und auch Statusbar oder das Verhalten des Agenten selbst sind anpassbar. Wer mag, kann sich eigene Sandboxes auf Basis anderer Images oder anderer Agents bauen, etwa für pi. Darauf möchte ich hier aber nur kurz hinweisen, das würde den Rahmen sprengen.
Weitere Themen
sbx entwickelt sich ständig weiter und bietet schon jetzt mehr nützliche Features, als dieser Artikel behandeln kann. Zwei davon sind einen eigenen Blick wert:
- Kits: eigene Anpassungen der Sandbox-Umgebungen
- der Git-Clone-Modus: Die Sandbox arbeitet auf einem eigenen Klon statt direkt auf dem Projektverzeichnis
Andere Feature sind dagegen erst angekündigt oder fehlen noch. Das Einfügen von Bildern per Copy & Paste ist in der Dokumentation bereits beschrieben, implementiert aber aktuell noch nicht. Dateien per Blacklist ausblenden zu können, z.B. ein .env File, wäre sicher noch nützlich.
Wer sich generell für das Thema Sandboxing von Coding-Agents interessiert, findet unter github.com/restyler/awesome-sandbox eine gute Übersicht über weitere Ansätze.