Docker Sandboxes sperren jeden KI-Coding-Agenten in eine eigene MicroVM mit eigenem Kernel und eigenem Docker-Daemon. Der Host bleibt damit außer Reichweite. Für Zugangsdaten und Quellcode im freigegebenen Projektordner gilt das nicht, dort verläuft die eigentliche Grenze.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Docker Sandboxes starten seit Ende März eine eigene MicroVM pro Agentensitzung, und das Kommandozeilenwerkzeug sbx gibt Docker kostenlos ab.[2] Wie dringend Entwicklerteams diese Grenze brauchen, zeigte der August 2025: Manipulierte npm-Pakete des Build-Systems Nx riefen auf fremden Rechnern die lokal installierten KI-Assistenten auf.
Das Wichtigste in Kürze
- Jede Agentensitzung bekommt eine eigene MicroVM mit eigenem Kernel und eigenem Docker-Daemon.
- Die MicroVM begrenzt den Schaden am Rechner, nicht den Abfluss von Daten über das Netz.
- Ab dem 11. September 2026 verlangt der Cyber Resilience Act binnen 24 Stunden eine Frühwarnung.
Warum reicht ein Container nicht mehr aus?
Container teilen den Kernel des Hosts. Sobald ein Coding-Agent selbst Images bauen und Container starten soll, braucht er erhöhte Rechte oder den Docker-Socket des Rechners, und damit fällt die Trennung in sich zusammen. Docker Sandboxes geben deshalb jeder Sitzung eine eigene MicroVM samt eigenem Kernel und eigenem Docker-Daemon.[1]
Einen eigenen VMM hat Docker geschrieben, statt Amazons Firecracker zu übernehmen. Srini Sekaran und Craig Gumbley begründen das mit der Plattformfrage: Firecracker setzt auf Linux und KVM, Coding-Agenten laufen aber auf Entwickler-Laptops. Der Docker-VMM spricht deshalb Hypervisor.framework, Windows Hypervisor Platform und KVM aus einer Codebasis an.[1]
Neun Werkzeuge laufen bereits darin, darunter Claude Code, Codex und die Gemini CLI.[2] Neu ist die Idee nicht: Amazon hat MicroVMs für KI-Agenten schon als Dienst in AWS Lambda verpackt, und Clawk stellt dem Agenten eine Wegwerf-VM hin. Neu ist der volle Docker-Daemon darin.[3]
Wo endet der Schutz der MicroVM?
Der Netzzugang bleibt die offene Flanke. Die MicroVM begrenzt, was ein entgleister Agent auf dem Rechner anrichtet, nicht aber, was er nach draußen schickt. Simon Willison hat die drei Bedingungen dafür schon im Juni 2025 zusammengeführt: Zugriff auf private Daten, Kontakt mit fremden Inhalten und ein Kanal nach außen.[4] In einer Coding-Sandbox liegen alle drei nebeneinander. Genau darauf zielt jede Prompt Injection.
Zugangsdaten für die eingebauten Dienste schiebt ein Proxy erst in die ausgehende Anfrage. Zwei Lücken nennt die Dokumentation trotzdem. Eigene Umgebungsvariablen aus /etc/sandbox-persistent.sh liest der Agent im Klartext, und die Zwischenablage des Hosts bleibt nur ohne ausdrückliche Freigabe verschlossen.[3] Ein einziger offener Kanal genügt, wie der Datenabfluss über Atlassian Rovo zeigte.
Docker formuliert den Kern in einem Satz: „Ein Sprachmodell, das seine eigenen Sicherheitsgrenzen festlegt, ist kein Sicherheitsmodell.“[1] Die Grenze gehört in die Infrastruktur, nicht in den Systemprompt, und darüber entscheidet die Geschäftsführung.
Docker Sandboxes verkleinern den Schadensradius auf dem Entwicklerrechner. Den Abfluss von Zugangsdaten verhindert erst eine harte Netzregel, und die setzt die IT-Leitung, nicht der Agent.
— Markus Seyfferth, Chefredakteur Dr. Web
Die offene Flanke bleibt der Netzzugang
Die MicroVM begrenzt den Schaden auf dem Entwicklerrechner. Den Abfluss von Zugangsdaten über eine erlaubte Verbindung hält die MicroVM nicht auf.
Was müssen Teams in Deutschland jetzt regeln?
Der Präzedenzfall liegt vor. Am 26. August 2025 landeten manipulierte Nx-Versionen auf npm; das Postinstall-Skript rief lokale KI-Assistenten mit Schaltern wie --yolo und --trust-all-tools auf. GitGuardian zählte danach 2.349 erbeutete Zugangsdaten von 1.079 Rechnern.[5] Eine MicroVM hätte den Rechner geschützt, den GitHub-Token im eingebundenen Projekt jedoch nicht. Dieselbe Angriffsklasse traf zuletzt das npm-Paket Keyv.
Ab dem 11. September 2026 greift zudem die Meldepflicht des Cyber Resilience Act (Verordnung (EU) 2024/2847, Artikel 14): Wird eine Schwachstelle aktiv ausgenutzt, geht binnen 24 Stunden eine Frühwarnung an das zuständige CSIRT und an die ENISA.[6] Code aus einem unbeaufsichtigten Agenten fällt unter dieselbe Pflicht wie handgeschriebener. Ein Schwachstellen-Scan im Coding-Agenten verkürzt dabei den Weg zum Befund.
Zwei Stellschrauben gehören vor den ersten unbeaufsichtigten Lauf geklärt. Der Agent bekommt eine Positivliste erlaubter Zieldomains statt offenen Netzzugangs, und persönliche Zugangsdaten wandern aus den Umgebungsvariablen in einen Tresor mit kurzlebigen Token. Wie oft die menschliche Kontrolle sonst versagt, zeigt eine Untersuchung zur Freigabe von KI-Agenten.
Ein Pilotlauf klärt die Lage schneller als jede Richtlinie. Installieren Sie sbx gerne auf einem Rechner und lassen Sie einen Agenten in der schärfsten Netzeinstellung an einem unkritischen Repository arbeiten. Das Verbindungsprotokoll zeigt danach, wie viel Autonomie Ihr Team verantworten kann.
Quellen
[1] Docker: „Why MicroVMs: The Architecture Behind Docker Sandboxes“, 16. April 2026
[2] Docker: „Docker Sandboxes: Run Agents in YOLO Mode, Safely“, 31. März 2026
[3] Docker Docs: „Docker Sandboxes FAQ“
[4] Simon Willison: „The lethal trifecta for AI agents“, 16. Juni 2025
[5] GitGuardian: „The Nx s1ngularity Attack: Inside the Credential Leak“
[6] Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 14 (Meldepflichten der Hersteller)
Mehr Newshunger?
- Clawk gibt dem KI-Coding-Agenten eine eigene Wegwerf-VM statt Ihres Rechners
- MicroVMs: AWS Lambda startet Sandboxen für KI-Agenten
- Fünf neue Prompt-Injection-Angriffe: Wie sich KI-Agenten heimlich umprogrammieren lassen
- Atlassian Rovo: Eine versteckte Anweisung genügt für den Datenabfluss aus Jira und Confluence
- Keyv kompromittiert: Der Angriff auf die npm-Lieferkette läuft noch
- Schwachstellen-Scan im Coding-Agenten: AWS verdrahtet Continuum mit Claude Code und Codex
- Alle Nachrichten aus dem KI-Ressort
