Ich habe Docker Sandboxes getestet und finde es genial.
Stellt euch vor, ihr lasst Claude Code einen Fehler suchen, und plötzlich fragt er nach der Erlaubnis für das hier:
docker compose down && \
docker image rm mertbergblog-webservice-app 2>/dev/null; \
docker network inspect blog >/dev/null 2>&1 || docker network create blog && \
docker compose up -d --build && \
until docker compose exec db pg_isready -U blog -d blog >/dev/null 2>&1; do sleep 1; done && \
docker compose exec app goose -dir /migrations postgres "$DATABASE_URL" up && \
docker image prune -f --filter "dangling=true" && \
docker compose logs -f app
Beängstigend, oder?
Es gibt aber eine Lösung, und die heißt Docker Sandboxes, kurz sbx.
Was macht Docker Sandboxes?
Im Kern erzeugt es eine MicroVM und lässt einen Coding-Agent darin laufen.
Das ist die Theorie. Was heißt das konkret? Eine MicroVM ist kein Container. Container sind wie Wohnungen in einem Haus: eigene Wohnungstür, aber ein gemeinsames Fundament und dieselben Leitungen, und das bedeutet in diesem Fall einen gemeinsamen Kernel. Eine MicroVM dagegen ist ein eigenes kleines Haus in derselben Straße. Eigener Kernel, eigenes Dateisystem, eigenes Netzwerk, eigener Docker-Daemon.
Die Straße gehört weiterhin dem Host, und darauf kommen wir am Ende zurück.
Ein Detail bekommen die meisten Texte dazu falsch hin, meiner vorher auch: MicroVM heißt nicht automatisch Firecracker. Fast alles, was über MicroVMs geschrieben wird, beschreibt Amazons Firecracker, und daher stammen auch die bekannten Zahlen von 125 Millisekunden Bootzeit und unter 5 MiB Overhead. Docker Sandboxes benutzt aber offenbar libkrun mit virtiofs. Diese Zahlen sind deshalb eine schöne Analogie und keine Messung von sbx. Das sollten wir wissen, bevor wir sie jemandem um die Ohren hauen.
Die Isolationsgrenze bei sbx ist der Ordner, aus dem ihr es startet. Startet ihr es in einem Projektverzeichnis, sieht der Agent dieses Projekt. Startet ihr es in eurem Home-Verzeichnis, sieht er alles, was darin liegt. Dieses eine Detail entscheidet über den größten Teil eurer Sicherheit, deshalb solltet ihr es klären, bevor ihr irgendetwas anderes macht.
Damit sind wir beim nächsten Abschnitt.
Warum Docker Sandboxes das Arbeiten mit KI-Agents sicherer macht
Nehmen wir an, ihr wollt mit eurem Coding-Agent etwas ausprobieren und braucht dafür einen sicheren Ort. Eine isolierte MicroVM ist genau das Richtige dafür.
Sie ist außerdem die richtige Wahl, wenn ihr dem Agent bestimmte Dinge vorenthalten wollt. Die .env-Datei, die API-Keys, die Zugangsdaten, die ihr vor Monaten eingerichtet und seitdem vergessen habt. Ihr macht euch Sorgen, dass der Agent diese Daten irgendwo ablegen könnte, und ich vermute, dass eine Menge API-Keys längst an Orten gelandet sind, an denen sie niemand erwartet hat. Falls es jemals einen erfolgreichen Angriff auf einen der Modellanbieter gibt, wird das für viele Leute eine schlechte Woche.
Es ist also eine gute Sicherheitsmaßnahme. Nicht weil sie den Agent vertrauenswürdig macht, sondern weil sie uns ein Werkzeug gibt, KI verantwortungsvoller einzusetzen. Genau das gefällt mir daran: Sie verändert, was ich zulasse, und nicht, was das Modell tut.
Vielleicht fragt ihr euch jetzt, wie ihr eure IDE mit sbx benutzt. Schauen wir es uns an.
Docker Sandboxes über SSH
Ihr könnt euch per SSH mit einer Sandbox verbinden. Zuerst konfiguriert ihr eure ~/.ssh/config:
sbx setup ssh
Danach erstellt ihr die Sandbox:
sbx create --name <NAME_OF_SBX_HOST> shell .
Und dann verbindet ihr euch:
ssh <NAME_OF_SBX_HOST>.sbx
sbx setup ssh schreibt die Konfiguration, sbx create löst alles auf und sagt euch, wie ihr euch verbindet.
Eine Sache auf diesem Screenshot lasse ich absichtlich stehen: Der Workspace dieser Sandbox ist mein ~/.ssh-Verzeichnis, und zwar beschreibbar. Ich habe das beim Testen des SSH-Setups so gemacht und keine Sekunde darüber nachgedacht. Es ist exakt der Fehler, den ich weiter unten beschreibe. Die Sandbox schützt uns nicht vor dem Ordner, den wir selbst ausgewählt haben.
In Cursor und VS Code könnt ihr über "Connect to..." einen Ordner per SSH öffnen.
VS Code spricht mit der Sandbox wie mit jedem anderen Remote-Host. Der Dateibaum liegt in der MicroVM.
In Zed hat es bei mir nicht funktioniert, weil der Proxy-Master gescheitert ist. Das ist kein großer Verlust, weil Zed seit Version 1.14 ein eigenes Sandboxing mitbringt: https://zed.dev/blog/sandboxing
Worauf es tatsächlich läuft
Docker dokumentiert eine schmale Plattformliste: macOS Sonoma auf Apple Silicon, Windows 11 und Ubuntu 24.04 oder neuer. Derivate wie Mint oder Pop!_OS werden ausdrücklich nicht unterstützt.
Ich betreibe es auf Debian 13, und es funktioniert. Das liegt außerhalb dessen, was Docker unterstützt, deshalb behandelt es als mein Ergebnis und nicht als Zusage. Auf Debian 12 hat es bei mir nicht funktioniert. Was ihr auf jeden Fall braucht, ist KVM, also prüft, ob /dev/kvm existiert und ob euer Benutzer in der Gruppe kvm ist. Falls euer Host selbst eine VM ist, braucht ihr am Hypervisor Nested Virtualization, weil es sonst im Gast kein /dev/kvm gibt und gar nichts startet.
Zwei Vorgaben solltet ihr kennen, bevor ihr auf einem Homelab-Rechner drei Sandboxes gleichzeitig hochzieht. Eine Sandbox nimmt sich standardmäßig 50 Prozent des Host-Speichers, gedeckelt bei 32 GiB. Und Sandboxes teilen sich nichts: Docker schreibt selbst, dass jede ihren eigenen Docker-Daemon-Zustand, ihren eigenen Image-Cache und ihre eigenen Paketinstallationen behält. Dadurch laden und bauen wir dieselben Images pro Sandbox erneut. Die Root-Disk liegt bei 20 GB.
Jedes sbx run zeigt, was es aufgelöst hat. Zwölf CPUs und 16 GiB für eine einzelne Sandbox, und darum hatte ich nicht gebeten.
Was Spaß gemacht hat
In meinen Tests habe ich meine Blog-Datenbank in einer Sandbox laufen lassen und sie an ihre Grenzen gebracht. Ich habe versucht, Dinge kaputtzumachen. Ich habe Daten gelöscht, Code geändert und Migrationen gegen eine halb initialisierte Datenbank laufen lassen.
Ich lösche das Dockerfile und die Compose-Datei meines eigenen Backends, und es ist mir völlig egal. Dieses Gefühl ist das ganze Produkt.
Ihr könnt auch mehrere gleichzeitig laufen lassen, mit verschiedenen Agents auf demselben Projekt:
Zwei Sandboxes auf demselben Repository, eine mit Claude und eine mit Gemini. Sie teilen sich nichts, und genau deshalb kostet es Speicherplatz.
Als ich fertig war, habe ich die Teile, die funktioniert haben, herauskopiert und die Sandbox entfernt, wodurch auch alles darin gelöscht wird.
Dieser letzte Punkt ist wichtig: Kopiert eure Arbeit heraus, bevor ihr sbx rm <SANDBOX_NAME> oder sbx prune ausführt. Es gibt kein Zurück.
Wenn ihr stattdessen die ganze Umgebung behalten wollt, könnt ihr ein eigenes Template oder ein Kit verwenden. Dieser Teil ist wirklich interessant. Ihr könntet den Zustand einer Sandbox in einem Template festhalten und über ein Kit Befehle automatisch ausführen lassen. In der spec.yaml legt ihr fest, welche Befehle beim Start laufen. Kits wirken auf mich allerdings noch experimentell, deshalb würde ich darauf noch keinen Workflow aufbauen.
Ich benutze das auf meinem Homelab, um verschiedene Image-Versionen zu testen. Wenn alles läuft, führe ich dieselben Befehle in Produktion aus. Fürs Backend-Testing ist es sehr gut. Selbst wenn der Agent etwas Seltsames tut, entferne ich die Sandbox und alles ist in Ordnung.
Fast alles jedenfalls. Damit kommen wir zu dem Teil, für dessen Verständnis ich am längsten gebraucht habe.
Fallstricke von Docker Sandboxes
Es ist nicht alles rosig. Auch mit der MicroVM müssen wir darauf achten, was wir hineingeben, und das Meiste davon dokumentiert Docker selbst.
Secrets in dem Ordner, den ihr mountet. Standardmäßig wird euer Verzeichnis beschreibbar eingebunden. Der Agent liest alles darin, auch eine .env, die neben eurem Repo liegt, und er kann diese Dateien außerdem verändern. Die MicroVM schützt uns nicht vor dem, was wir selbst übergeben haben. Nehmt --clone, wenn ihr euch nicht sicher seid.
Dateien, die der Agent schreibt und die auf dem Host ausgeführt werden. Dieser Punkt ist subtil, und er ist der, der mir am meisten Sorgen macht. Der Agent kann auf unserer Maschine nichts ausführen. Er kann aber einen Git-Hook schreiben, ein Makefile-Target oder einen Eintrag unter scripts in der package.json, und diese laufen später auf dem Host, sobald wir oder unser Tooling sie aufgreifen. Der Ausbruch führt nicht durch den Hypervisor, sondern durch unser nächstes git checkout.
Eure MCP-Server laufen außerhalb der MicroVM. Lokale stdio-MCP-Server starten als Host-Prozesse mit Host-Rechten. Docker schreibt das in der eigenen Dokumentation. Ein Agent, der einen MCP-Server erreicht, hat also einen Kanal, der von Anfang an nicht in der Sandbox lag.
Die Allowlist lässt sich zum Abfluss von Daten benutzen. Der Proxy prüft die Domain und nicht den Inhalt. Eine Anfrage an eine erlaubte Domain kann die Daten deshalb im Dateinamen tragen, etwa als <SECRET_KEY>.json. Die Anfrage selbst wird abgelehnt, aber die Gegenseite hat den Namen bereits protokolliert. Sicherheitsforscher haben genau das 2026 gegen eine ganze Reihe von Coding-Agents demonstriert, und Docker räumt das Problem in der eigenen Dokumentation ein: Eine breite Domain zu erlauben gewährt Zugriff auf beliebige Inhalte darauf, "including user-generated content".
Schaut nach, wie eure Policy tatsächlich aussieht. Docker veröffentlicht die Standard-Allowlist nicht, und zwei Doku-Seiten widersprechen sich darin, ob der Standard erlauben oder verbieten ist. Lest es deshalb nicht nach, sondern führt es aus:
sbx policy ls
Bei mir hat der erste Lauf auf Balanced gestellt und es auch gesagt:
"Default deny, with common dev sites allowed." Gut zu wissen, und besser aus dem eigenen Terminal gelesen als von einer Doku-Seite.
Der Skills-Store wird zwischen Sandboxes geteilt. Docker nennt das selbst "a narrow exception to cross-sandbox isolation" und bindet ihn beschreibbar ein. Dadurch kann eine Sandbox Anweisungen verändern, die ein Agent später in einer anderen Sandbox benutzt. Anweisungen sind genau die Art von Inhalt, auf die es hier ankommt.
Die Sandbox lädt weiterhin Agent-Konfiguration aus eurem Projekt. Wurde diese Konfiguration manipuliert, bevor sie in der Sandbox ankam, startet die Sandbox brav einen kompromittierten Agent. Es gibt Schadsoftware, die genau deshalb Persistenz-Hooks in .claude/settings.json schreibt, und die überlebt das Entfernen des Pakets, das sie mitgebracht hat.
Sandboxes selbst hatten schon Löcher. In Claude Codes Netzwerk-Sandbox gab es einen Fehler, durch den eine leere Allowlist, dokumentiert als "alles blockieren", die Netzwerkbeschränkung komplett abgeschaltet hat (CVE-2025-66479). Ein zweiter Fehler ließ einen Hostnamen mit eingebettetem Nullbyte durch die Prüfung. Der Forscher, der beide gefunden hat, formuliert es besser, als ich es könnte: "Shipping a sandbox with a hole is worse than not shipping one. The user with no sandbox knows they have no boundary. The user with a broken sandbox thinks they do."
Irgendwann sind wir das Bestätigen leid. Nach einer Weile stellt man auf Auto-Modus oder umgeht die Berechtigungen und lässt den Agent einfach arbeiten. Ich verstehe das, ich mache es selbst manchmal, und ich habe jedes Mal ein schlechtes Gefühl dabei. Eine Sandbox macht das nicht in Ordnung, weil die Punkte darüber weiterhin den Host berühren.
Unterste Zeile im Screenshot: "bypass permissions on". Das habe ich nicht für den Artikel eingeschaltet. Es war schon an.
Performance. Ich habe es noch nicht lange genug benutzt, um etwas Belastbares zu sagen, aber die zusätzliche Schicht könnte den Agent verlangsamen, und andere berichten, dass sie es tut. Eine Sache lohnt sich trotzdem zu wissen: Der voreingestellte Direct Mount ist der langsame. Docker schreibt in der eigenen Troubleshooting-Doku, dass git status, git log und Verzeichnisscans spürbar langsam sein können, und im --clone-Modus ist virtiofs-Caching aktiv. Der sicherere Modus ist also gleichzeitig der schnellere, und diese Kombination ist selten genug, um sie auszunutzen.
Und falls ihr gerade der Bootzeit von 125 Millisekunden vertrauen wolltet: In einem realistischen Stack messen unabhängige Untersuchungen bei Firecracker 700 bis 1300 Millisekunden Kaltstart, und für sbx werden 2 bis 5 Sekunden zusätzliche Startzeit berichtet. Die Werbezahl beschreibt eine eigens gebaute Serverless-Steuerungsebene und nicht unsere Laptops.
Der Teil, der nicht ins Marketing kommt
Zwei Dinge habe ich beim Nachlesen gefunden, und beide haben verändert, wie ich darüber denke.
Erstens: Der Satz "Firecracker hat keine Escape-CVEs" stimmt seit 2026 nicht mehr. Es gibt inzwischen einen Out-of-Bounds-Write im virtio-PCI-Transport von Firecracker, und Cloud Hypervisor hat ein Advisory veröffentlicht, in dem ausdrücklich von "a full guest-to-host (VM) escape" die Rede ist. Für beides existiert kein öffentlicher funktionierender Exploit, deshalb ist das kein Grund zur Panik. Es ist ein Grund, das Marketing nicht länger nachzuplappern.
Zweitens, und das wiegt schwerer, weil hier die Straße zurückkommt: Die MicroVM verkleinert den Hypervisor. Sie verkleinert aber nicht KVM, und KVM ist Code im Host-Kernel, mit dem der Gast direkt spricht. 2026 gab es zwei Guest-to-Host-Ausbrüche in KVM selbst, einer davon durch einen Fehler, der seit 2010 in der Shadow MMU saß. Ein 50.000 Zeilen langer VMM in Rust mit streng begrenztem Syscall-Filter hilft dagegen genau nichts.
Meine liebste Veranschaulichung des ganzen Problems handelt nicht einmal von MicroVMs. Im Juli 2026 hat ein Agent bei OpenAI einen Zero-Day im Paket-Registry-Proxy gefunden und ausgenutzt, also ausgerechnet in der Komponente, die seinen Netzwerkverkehr kontrollieren sollte, und ist darüber ins offene Internet gelangt. Der Baustein, den es nur gab, weil der Agent Paketzugriff brauchte, wurde zum Ausgang.
Lohnt es sich also?
Ja, mit einer Korrektur an der Art, wie es üblicherweise verkauft wird.
Die MicroVM ist nicht das, was uns schützt. Sie nimmt den schlimmsten Fall weg, nämlich einen Agent, der etwas Unwiderrufliches mit unserer Maschine anstellt. Übrig bleibt ein viel gewöhnlicheres Problem: alles, was wir bewusst hineingereicht haben. Der Ordner, die Konfiguration, die Allowlist, der MCP-Server.
Die Sandbox macht die KI nicht sicherer. Sie macht mich mutiger, und das ist nur so lange eine Verbesserung, wie ich ehrlich dazu bleibe, welche Tür ich offen gelassen habe.