Docker Sandboxes für KI-Agenten: Was MicroVMs schützen und was Cloud kostet

Was sind Docker Sandboxes?

Coding-Agenten sollen Quellcode ändern, Abhängigkeiten installieren, Tests ausführen und bei Bedarf Container starten. Genau diese Fähigkeiten machen eine direkte Ausführung auf dem Arbeitsrechner riskant. Docker Sandboxes setzen deshalb nicht nur auf einen weiteren Container, sondern auf eine MicroVM als Isolationsgrenze.

Laut Docker-Architektur besitzt jede Sandbox einen eigenen Linux-Kernel, ein eigenes Netzwerk und einen eigenen Docker-Daemon. Ein Agent kann innerhalb der VM also docker build oder docker compose up ausführen, ohne dafür Zugriff auf den Docker-Daemon des Hosts zu erhalten.

Das ist der entscheidende Unterschied zu einem normalen Container mit eingebundenem /var/run/docker.sock. Wer den Host-Socket kontrolliert, kann den Host-Daemon anweisen, privilegierte Container oder beliebige Host-Mounts zu starten. Bei Docker Sandboxes bleiben vom Agenten gestartete Container dagegen innerhalb der MicroVM. Die VM ersetzt aber keine Rechteprüfung: Host-Verzeichnisse, Netzwerkfreigaben und externe Tools bilden weiterhin explizite Übergänge aus der Sandbox.

Wie startest du eine lokale Docker Sandbox?

Die sbx-CLI arbeitet laut Installationsanleitung eigenständig. Docker Desktop oder eine bereits installierte Docker Engine auf dem Host sind nicht erforderlich. Für eine lokale Sandbox brauchst du jedoch unterstützte Virtualisierung: Unter Linux nennt Docker Ubuntu 24.04 oder neuer sowie KVM und die passende Benutzerberechtigung als Voraussetzung. Läuft Linux selbst in einer VM, muss der Anbieter Nested Virtualization durchreichen.

Nach Installation und Docker-Login startest du den offiziell dokumentierten Beispiel-Agenten im aktuellen Projektverzeichnis so:

sbx login
cd ~/mein-projekt
sbx run --name my-sandbox claude

Der letzte Befehl startet nicht automatisch einen kostenlosen Modellzugang. Der jeweilige Agent benötigt weiterhin eine eigene Anmeldung oder API-Zugangsdaten. Die Einstiegsdokumentation beschreibt außerdem eine Auswahl der Netzwerk-Policy beim ersten Lauf. Vorhandene Regeln lassen sich anschließend prüfen:

sbx policy ls

Ich habe sbx für diesen Artikel nicht installiert und keine Sandbox gestartet. Die Befehle sind Beispiele aus der Docker-Dokumentation, kein eigener Praxistest.

Welcher Workspace-Modus passt zu deinem Risiko?

Die wichtigste praktische Entscheidung ist nicht der Agent, sondern dessen Zugriff auf deine Dateien. Docker bietet drei unterschiedliche Workspace-Modelle:

Modus	Beispiel	Zugriff auf den Host	Geeignet für
Direct	sbx run claude .	Aktuelles Verzeichnis lesbar und schreibbar	Bewusst beaufsichtigte Arbeit an einem vertrauenswürdigen Repository
Clone	sbx run --clone claude .	Host-Repository schreibgeschützt sichtbar, Arbeit in privatem Klon	Agent soll den Host-Stand nicht direkt verändern
Mountless	sbx create --name scratch claude	Kein Host-Workspace eingebunden	Unbekannter Code oder Aufgaben mit maximaler Dateitrennung

Im Direct-Modus landen Änderungen sofort im Host-Workspace. Das ist bequem, erlaubt dem Agenten aber auch Änderungen an Git-Hooks, CI-Dateien, IDE-Aufgaben oder Build-Skripten. Ein späterer Befehl auf dem Host kann solchen Code ausführen. Vor der Übernahme reicht deshalb ein normaler git diff nicht immer aus, weil beispielsweise Inhalte unter .git/hooks/ darin nicht erscheinen.

Der Clone-Modus verhindert Schreibzugriffe auf das Host-Repository. Er verhindert laut Dokumentation zur Workspace-Isolation jedoch nicht das Lesen: Nicht versionierte und per .gitignore ausgeschlossene Dateien im Repository, darunter eine .env, bleiben im schreibgeschützten Quell-Mount sichtbar. Mountless vermeidet diesen Übergang. Benötigte Dateien musst du dann gezielt per sbx cp oder Git übertragen.

Was kann ein Agent trotz MicroVM erreichen?

„Läuft in einer VM“ bedeutet nicht „kann dem Host oder externen Diensten nichts anhaben“. Die Sicherheitsdokumentation von Docker nennt mehrere Vertrauensgrenzen, die du getrennt prüfen solltest.

Grenze	Was die MicroVM schützt	Verbleibendes Risiko
Workspace	Andere Host-Pfade sind nicht regulär eingebunden	Direct-Mount erlaubt Änderungen im freigegebenen Verzeichnis; Clone lässt sensible Dateien lesen
Netzwerk	Ausgehender TCP-Verkehr läuft über eine Policy	Erlaubte Domains bleiben erreichbar; breite Wildcards können mehr Dienste freigeben als beabsichtigt
Credentials	Verwaltete Secrets können hostseitig injiziert werden	Interaktiv in der VM gespeicherte Tokens liegen im Sandbox-Dateisystem
MCP	Der Agent läuft in der MicroVM; lokale MCP-Server sind kein Teil ihrer Isolation	Lokale stdio-MCP-Server laufen auf dem Host; vom Agenten ausgelöste Aktionen nutzen deren Host-Rechte
SSH-Agent	Private Schlüssel bleiben auf dem Host	Weitergeleitete Sockets können Authentifizierungs- und Signaturvorgänge auslösen
Shared Skills	Standardmäßig schreibgeschützte Wiederverwendung	Bei explizitem readwrite kann eine Sandbox gemeinsam genutzte Anweisungen manipulieren

Besonders relevant sind lokale MCP-Server. Ruft ein Agent über das Gateway ein Tool auf, das auf dem Host Prozesse oder Container startet, greift die MicroVM-Isolation für diesen Vorgang nicht. MCP-Tools sind daher keine harmlose Komfortfunktion, sondern privilegierte Integrationen.

Auch ein Credential-Proxy löst nicht jedes Secret-Problem. Er kann verhindern, dass unterstützte API-Schlüssel als Klartext in der VM liegen. Ein Agent kann aber weiterhin erlaubte API-Aufrufe auslösen. Meldest du dich interaktiv innerhalb der Sandbox an und speichert das Werkzeug dort Tokens, gehören diese Dateien zum VM-Dateisystem.

Die VM-Grenze selbst kann außerdem Fehler enthalten. Accomplish dokumentierte CVE-2026-77179, eine macOS-spezifische Schwachstelle im Zusammenspiel aus Dockers VMM und virtio-fs. Nach Angaben der Sicherheitsforscher wurde sie in Docker Sandboxes 0.42.0 und Docker Desktop 4.88.0 behoben. Das ist kein Beleg für eine aktuell ungepatchte, plattformübergreifende Umgehung. Es zeigt aber, warum Versionen und Sicherheitsupdates auch bei MicroVMs relevant bleiben.

Was bieten Docker Cloud Sandboxes?

Docker stellte Cloud Sandboxes am 24. September 2026 vor. Der CLI-Support ist experimentell und setzt eine aktivierte Pay-as-you-go-Nutzung der Docker Agentic Platform voraus. Der Launch-Beitrag verlangt mindestens sbx 0.45.1, während die damalige Installationsdokumentation 0.45.0 nennt. Für den Einstieg ist deshalb 0.45.1 oder neuer die vorsichtigere Untergrenze.

Nach Login, Cloud-Aktivierung und Konfiguration der benötigten Cloud-Secrets sieht der offizielle Start so aus:

sbx --cloud run claude --name cloud-project

Eine Cloud-Sandbox kann keine lokalen Host-Pfade mounten und unterstützt keinen lokalen --clone-Workflow. Projektdateien gelangen stattdessen per Git oder sbx --cloud cp in die VM. Das reduziert den direkten Zugriff auf den aufrufenden VPS, macht den Dateitransfer aber zu einem eigenen Arbeitsschritt.

Was kostet die Cloud-Variante?

Die folgende Preistabelle stammt aus Dockers Launch-Beitrag vom 24. September 2026 und ist eine zeitabhängige Momentaufnahme:

Größe	vCPU	RAM	Preis pro Stunde
Micro	1	2 GiB	0,07 US-Dollar
Small (Standardgröße)	2	4 GiB	0,14 US-Dollar
Medium	4	8 GiB	0,28 US-Dollar
Large	8	16 GiB	0,56 US-Dollar
XL	16	32 GiB	1,12 US-Dollar

Docker rechnet Compute laut Agentic-Platform-Abrechnung sekundengenau ab. Gestoppte Sandboxes verursachen keine Compute-Gebühr. Modellinferenz ist nicht im VM-Preis enthalten und wird separat über den jeweiligen Anbieter abgerechnet.

Cloud-Sandboxes haben standardmäßig eine Ablauffrist (TTL) von einer Stunde. Du kannst TTL und Timeout-Aktion beim Erstellen festlegen und die Frist später verlängern, jedoch nicht über 24 Stunden ab Erstellung hinaus. Ohne ausdrücklich gesetzte Aktion stoppt Docker am Ablauf nur Sandboxes, die wiederaufgenommen werden können; andere werden gelöscht. Prüfe vor langen Aufgaben mit sbx --cloud ttl <name> die Frist und exportiere Ergebnisse rechtzeitig. Ein gestoppter Zustand ist nicht gleichbedeutend mit einer unbegrenzten TTL.

Was überträgt sbx move wirklich?

Der Befehl

sbx move local-project --to cloud

ist keine Live-Migration. Docker erstellt laut sbx move-Dokumentation einen Snapshot des In-Sandbox-Dateisystems, überträgt ihn als Image und legt am Ziel eine neue Sandbox mit neuer ID an. Die Quell-Sandbox bleibt bestehen, wird bei diesem lokalen-zu-Cloud-Move aber zum Erstellen des Snapshots gestoppt; spätere Änderungen werden nicht synchronisiert.

Nicht übertragen werden laufende Prozesse, RAM-Inhalte, offene Sockets, Host-Mounts, verwaltete Secrets und Netzwerkregeln. Lokale HTTP-Methoden- oder Pfadregeln gelten in der Cloud nicht, weil die Cloud-Policy kein entsprechendes L7-Filtering unterstützt. Zugangsdaten, die als normale Dateien innerhalb der Sandbox liegen, können dagegen Teil des Snapshots sein. Prüfe das Dateisystem deshalb vor dem Move.

Welche Einschränkungen sind für die Praxis wichtig?

Cloud-Ports werden über öffentliche HTTPS-URLs erreichbar. Das vereinfacht Vorschauen, ersetzt aber keine Authentifizierung des veröffentlichten Dienstes. Außerdem nennt Docker eine relevante Einschränkung für Container-Workloads: docker exec, docker compose exec und Healthchecks können in Cloud Sandboxes fälschlich auf das VM-Dateisystem statt auf das Dateisystem des Zielcontainers zugreifen. Ein erfolgreicher Exit-Code beweist dann nicht, dass die erwartete Datei im Container bearbeitet oder geprüft wurde.

Für sicherheitskritische oder automatisierte Abläufe sind deshalb drei Kontrollen sinnvoll:

1. Nutze Clone oder Mountless statt Direct, wenn ein Agent nicht unmittelbar auf dem Host schreiben muss.
2. Reduziere Netzwerkregeln, MCP-Tools, SSH-Agent-Weiterleitung und schreibbare Shared Skills auf das Notwendige.
3. Prüfe Änderungen und Artefakte außerhalb der Sandbox, bevor du sie ausführst, veröffentlichst oder in CI übernimmst.

Was bedeutet das für einen VPS ohne KVM?

Auf dem für diesen Artikel betrachteten VPS fehlte am 28. September 2026 /dev/kvm; der Virtualisierungsstatus meldete microsoft. Damit sind die von Docker genannten Voraussetzungen für lokale Linux-MicroVMs dort nicht erfüllt. Das ist eine Beobachtung dieses konkreten virtuellen Hosts, keine Aussage über alle VPS oder Microsoft-basierte Virtualisierung.

Eine Cloud-Sandbox benötigt laut Cloud-Dokumentation kein lokales KVM, weil die MicroVM bei Docker läuft. Für einen VPS ohne durchgereichte Hardwarevirtualisierung ist sie daher die technisch passende Variante. Ob sie wirtschaftlich passt, hängt von Laufzeit, Instanzgröße und zusätzlichen Modellkosten ab. Für diesen Artikel wurde auch keine Cloud-Sandbox gestartet; es liegen weder eigene Laufzeitmessungen noch reale Abrechnungsdaten vor.

FAQ: Häufig gestellte Fragen zu Docker Sandboxes

Brauche ich Docker Desktop für Docker Sandboxes?

Nein. Die sbx-CLI benötigt weder Docker Desktop noch eine lokale Docker Engine. Für lokale Sandboxes brauchst du aber die von Docker unterstützte Virtualisierung, unter Linux insbesondere KVM.

Ist eine Docker Sandbox nur ein normaler Container?

Nein. Die primäre Grenze ist eine MicroVM mit eigenem Linux-Kernel und eigenem Docker-Daemon. Container, die der Agent startet, laufen innerhalb dieser VM und nicht direkt über den Host-Daemon.

Kann eine Sandbox mein lokales Repository verändern?

Im Direct-Modus ja. Clone verhindert Änderungen am Host-Repository, lässt dessen Inhalte einschließlich ignorierter Dateien aber lesen. Mountless bindet kein lokales Projektverzeichnis ein.

Schützt Clone meine .env vor dem Agenten?

Nein, wenn die .env im eingebundenen Host-Repository liegt. Clone macht die Quelle schreibgeschützt, aber nicht unsichtbar.

Kann ich eine laufende Sandbox ohne Unterbrechung in die Cloud verschieben?

Nein. sbx move überträgt einen Dateisystem-Snapshot, keine Prozesse, RAM-Inhalte oder offenen Verbindungen. Der Agent muss am Ziel neu starten.

Laufen Docker Sandboxes auf einem VPS ohne /dev/kvm?

Lokal nicht, sofern der VPS keine nutzbare KVM- beziehungsweise Nested-Virtualization-Unterstützung bereitstellt. Die Cloud-Variante kann dagegen über die CLI genutzt werden, weil die MicroVM nicht auf dem VPS läuft.

Fazit

Docker Sandboxes setzen für Coding-Agenten eine sinnvollere Grenze als ein Container mit Host-Docker-Socket. Die MicroVM schützt aber nur das, was du nicht über Workspace, Netzwerk, MCP oder Credentials wieder freigibst. Auf einem Rechner mit KVM würde ich für unbekannte Aufgaben mit Mountless oder mindestens Clone beginnen; auf einem VPS ohne KVM ist die Cloud-Variante die realistische Option, allerdings mit experimentellem Status, separaten Modellkosten und dokumentierten Container-Limitierungen. Weiterführend passen die Artikel zu Hermes als lokalem Agenten, autonomen Coding-Loops und isoliertem KI-Pentesting.

Quellen

Docker-Primärquellen

• Docker Sandboxes: Architektur, abgerufen am 28. September 2026
• Docker Sandboxes: Installation und Voraussetzungen, abgerufen am 28. September 2026
• Docker Sandboxes: Lokaler Einstieg, abgerufen am 28. September 2026
• Docker Sandboxes: Nutzung und Workspace-Modi, abgerufen am 28. September 2026
• Docker Sandboxes: Sicherheitsmodell, abgerufen am 28. September 2026
• Docker Sandboxes: Isolationsgrenzen, abgerufen am 28. September 2026
• Docker Cloud Sandboxes, abgerufen am 28. September 2026
• Docker Cloud Sandboxes: Nutzung und Limitierungen, abgerufen am 28. September 2026
• Docker: Lokale und Cloud-Sandboxes im Vergleich, abgerufen am 28. September 2026
• Docker: Sandbox zwischen lokal und Cloud verschieben, abgerufen am 28. September 2026
• Docker Agentic Platform: Aktivierung und Abrechnung, abgerufen am 28. September 2026
• Docker: Ankündigung der Cloud Sandboxes vom 24. September 2026

Externe Sicherheitsanalyse

• Accomplish: Guest to host – escaping Docker’s hypervisor, abgerufen am 28. September 2026