Docker Sandboxes: Der Deepdive zu sicheren KI-Agenten

Der Raum bei AI READY war gut besetzt, dazu kam eine Reihe von Teilnehmerinnen und Teilnehmern remote dazu – und das Thema hätte kaum aktueller sein können: Docker Sandboxes, die isolierten Laufzeitumgebungen für KI-Agenten. Alle Punkte die angekündigt waren, wurden durchgegangen – vom Aufsetzen einer Sandbox über die Frage der Isolation bis hin zu den Grenzen des Ansatzes.

Dieser Artikel ist der Deepdive dazu. Wir schauen uns an, was Docker Sandboxes laut Hersteller leisten soll, was wir live ausprobiert haben und wo die ehrlichen Fragezeichen bleiben. Eine Vorbemerkung vorweg: Gerade bei einem Produkt, das sich so schnell entwickelt wie dieses, lohnt es sich, zwischen Fakten, Herstellerversprechen und ersten Erfahrungen zu unterscheiden. Viele Behauptungen, die man aktuell hört, sind Werbeaussagen – und ob sie sich halten, wird sich erst mit mehr Praxiserfahrung zeigen.

Docker Sandboxes: Was steckt dahinter?

Die Kurzfassung, wie sie auch auf der offiziellen Docker-Produktseite steht: Docker Sandboxes sind wegwerfbare, isolierte Umgebungen für KI-Agenten wie Claude Code, Copilot CLI, Codex, OpenCode oder Kiro – gedacht für sicheres, unbeaufsichtigtes Arbeiten. Das Besondere ist die Art der Isolation:

Genau das unterscheidet den Ansatz von der klassischen Variante „Agent läuft direkt auf meinem Rechner“. In der offiziellen Doku heißt es: Jede Sandbox bekommt ihren eigenen Docker-Daemon, ihr eigenes Dateisystem und ihr eigenes Netzwerk. Was der Agent darin macht – Container bauen, Pakete installieren, Dateien ändern – bleibt in der Sandbox. Wird sie gelöscht, verschwinden Images, Container und Volumes mit ihr.

Installiert wird das Ganze über das CLI-Tool sbx, das laut Doku kostenlos ist – auch für kommerzielle Nutzung. Nur wer Governance-Funktionen für ganze Organisationen nutzen will (Netzwerk-, Dateisystem- und MCP-Richtlinien, die zentral erzwungen werden), braucht ein separates, kostenpflichtiges Abonnement. Docker Desktop ist für den Betrieb laut FAQ nicht nötig.

Warum Autonomie eigentlich der Punkt ist

Um zu verstehen, warum Docker Sandboxes überhaupt existiert, muss man sich die Arbeitsweise moderner Coding-Agents ansehen. Ein Agent, der wirklich produktiv sein soll, will Dateien ändern, Tests ausführen, Pakete installieren, Dienste starten. Das geht nur mit Rechten. Und mit Rechten kommt die alte Frage zurück: Was, wenn der Agent etwas Falsches tut?

Viele Tools haben dafür einen Modus, der genau das erzwingt, was sich eigentlich keiner wünscht: den sogenannten Permission-Bypass. Bei Claude Code heißt das Flag --dangerously-skip-permissions, bei Gemini CLI --yolo, bei Amazons q --trust-all-tools. Das Problem: Auf dem Host ausgeführt, überlässt man damit einem automatisierten Prozess den Zugriff auf alles, was man selbst lesen und schreiben kann. Docker Sandboxes adressiert genau dieses Dilemma, indem es den Bypass einhegt: Auf der Produktseite wird der Modus offen beworben – „YOLO mode, safely" – mit dem Argument, dass die microVM-Grenze den Schaden begrenzt.

Die Sicherheitsmechanik im Detail

Das Meetup hat genau hier am meisten Zeit verbraucht – zu Recht. Denn die eigentliche Architektur-Frage lautet: Wie viel von meinem Rechner sieht der Agent überhaupt? Drei Mechanismen sind laut Docker-Doku und dem Docker-Engineering-Blog entscheidend:

Gerade der dritte Punkt ist ungewöhnlich und hat im Meetup für die lebhafteste Diskussion gesorgt: Das Geheimnis existiert in der Sandbox physisch nicht. Selbst wenn ein Agent vollständig kompromittiert wäre, gäbe es nichts zu stehlen. Der Docker-Blog beschreibt das mit einem einfachen Test: sbx run starten, Umgebungsvariable auslesen – und statt des echten Schlüssels erscheint der Platzhalter. Wer Credentials lieber gar nicht erst über sbx speichern will, kann sie laut Doku auch direkt aus einem Vault beziehen – die 1Password-Integration (op read bzw. op run) ist dort dokumentiert. Auch SSH-Signing funktioniert, indem der SSH-Agent des Hosts durchgereicht wird, ohne dass der private Key die Sandbox betritt.

Das klingt nach viel – und ist es in der Summe auch. Aber es ist wichtig, hier die Grenze der Aussagekraft zu benennen: Diese Mechanismen sind Stand August 2026 dokumentiert und von uns im Meetup ausprobiert. Wie robust sie unter realem Angriffsdruck sind, zum Beispiel bei einem vollständig kompromittierten Daemon oder bei Seitenkanälen über die microVM-Grenze, werden erst die nächsten Monate zeigen.

Der Fall, der alles verändert hat: Nx & s1ngularity

Warum das Thema überhaupt so dringlich ist, zeigt ein Vorfall, der im Meetup ausführlich besprochen wurde – weil er in die gleiche Kerbe schlägt wie Docker Sandboxes. Am 26. August 2025 wurden bösartige Versionen des beliebten Build-Tools Nx auf npm veröffentlicht. Laut der Analyse von GitGuardian betraf das die Versionen 20.9.0 bis 21.8.0. Snyk berichtet, dass acht bösartige Releases insgesamt nur rund 5 Stunden und 20 Minuten online waren, bevor sie entfernt wurden – eine Zeitspanne, die trotzdem ausreichte.

Das Neue an diesem Angriff war die Methode. Der postinstall-Haken des Pakets (namens telemetry.js) hat nicht einfach selbst nach Passwörtern gesucht. Er hat auf dem betroffenen Rechner nach installierten KI-CLI-Tools gesucht – claude, gemini, q – und diese mit den oben genannten Permission-Bypass-Flags gestartet, mit einem Prompt, der wie eine harmlose Aufgabe klang: Dateien finden, Pfade auflisten, in /tmp/inventory.txt schreiben. Das Ergebnis war ein automatisiertes Durchsuchen des Systems nach Wallets, SSH-Keys, .env-Dateien und API-Keys.

Der entscheidende Punkt für uns: Der Angriff funktionierte, weil der Agent alles lesen konnte, was der Entwickler lesen konnte. --dangerously-skip-permissions ist dabei nicht das eigentliche Problem – es ist die Tatsache, dass die Dateien überhaupt in Reichweite lagen. Genau hier setzt die Logik von Docker Sandboxes an: Der Dateisystem-Blick des Agenten endet am Workspace-Rand. Wird ein solcher Angriff gegen eine Sandbox ausgeführt, findet die Rekonstruktion schlicht nichts – die Zieldateien existieren in dem Blickfeld, das der Agent hat, nicht.

In eine ähnliche Richtung gehen Zahlen aus GitGuardians State of Secrets Sprawl 2026: 28.649.024 neue hartkodierte Secrets wurden 2025 in öffentlichen GitHub-Commits erkannt – ein Plus von 34 Prozent gegenüber dem Vorjahr. Und Commits, die mit KI-Unterstützung entstehen, leaken laut dem Report ungefähr doppelt so häufig Zugangsdaten wie der öffentliche Durchschnitt. Das ist ein statistischer Zusammenhang, kein Kausalitätsbeweis – aber er unterstreicht, warum die Frage „Wo genau darf mein Agent arbeiten?" zur Kernfrage wird.

Docker Sandboxes in der Praxis: Was wir im Meetup ausprobiert haben

Genug Theorie – im Meetup ging es dann ans Eingemachte. Wir haben die zentralen Schritte live durchgespielt, die auch in der offiziellen Doku stehen:

# Installation (Auswahl aus der Doku, Stand August 2026)
# macOS:
brew trust docker/tap
brew install docker/tap/sbx
# Windows:
winget install Docker.sbx
# Ubuntu:
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx

# Anmelden und erste Sandbox starten:
sbx login
sbx run claude

• Setup in wenigen Minuten: Installation und Login liefen unkompliziert durch. Wer bereits Docker-Kenntnisse mitbringt, fühlt sich sofort zuhause.
• Eigener Docker-Daemon: Innerhalb der Sandbox konnten wir eigene Container bauen und starten – sie tauchten erwartungsgemäß nie im docker ps des Hosts auf und wurden mit der Sandbox entsorgt.
• Port-Weitergabe gezielt: Dienste, die der Agent startet, sind standardmäßig nicht von außen erreichbar. Per sbx ports lässt sich ein Port gezielt freigeben – netzwerkseitig bleibt es dadurch kontrollierbar.
• Secrets-Test: Die Umgebungsvariable in der Sandbox zeigte den Platzhalter statt des echten Werts. Der „Beweis durch Ausprobieren" aus dem Docker-Blog funktionierte in unserem Test genauso.
• Git-Workflows: Direktmodus (Agent arbeitet im gemounteten Workspace), Clone-Modus (Agent arbeitet in einem eigenen Klon) und Worktree-Variante – alle drei sind dokumentiert und wir haben zumindest die ersten beiden durchgespielt.

Was im Meetup ebenfalls klar wurde: Wer einmal mit Sandboxes gearbeitet hat, will in vielen Situationen nicht zurück. Der Komfort, einen Agenten unbeaufsichtigt an einer Aufgabe arbeiten zu lassen, ohne ständig „ist das jetzt okay?" abzufragen, ist real. Die entscheidende Einschränkung bleibt aber die Dateisystem-Grenze: Alles, was der Agent braucht – Zugänge zu Testumgebungen, spezielle Konfigurationen –, muss aktiv in die Sandbox geholt werden. Das ist anfangs etwas mehr Setup-Aufwand als „Agent einfach auf dem Laptop starten".

Drei Wege, Git in der Sandbox zu nutzen

Ein Detail, das im Meetup besonders gut ankam, ist die durchdachte Git-Anbindung. Die Doku beschreibt drei Modi, die sich fundamental unterscheiden – und je nach Arbeitsweise ihre Berechtigung haben:

Im Direktmodus mountet die Sandbox den Working Tree direkt – der Agent arbeitet in deinen Dateien, Änderungen erscheinen sofort, du managst Branches selbst. Im Clone-Modus legt sbx einen eigenen Git-Klon in der Sandbox an; der Agent kann darin Branches und Worktrees für parallele Tasks anlegen, und du holst die Ergebnisse per git fetch sandbox-<name> auf den Host. Der Host-Repo bleibt dabei schreibgeschützt unter /run/sandbox/source erreichbar. Der Host-Worktree schließlich ist ein Mittelweg: Der Agent bearbeitet ein Worktree-Verzeichnis, hat aber selbst keinen Git-Zugriff – du committest nach Review vom Host aus.

Für uns war der Clone-Modus der spannendste: Mehrere Agents parallel an getrennten Tasks, sauber isoliert, ohne dass sich die Arbeitsstände in die Quere kommen – das ist genau die Art von Workflow, für die man Sandboxes wirklich braucht, statt sie nur als „sichere Kiste" zu nutzen.

Bauen, Testen, Dienste starten – in der Box

Was kann ein Agent in der Sandbox tatsächlich tun? Laut Doku ziemlich viel: Agents haben darin sudo-Rechte, können Pakete installieren, Datenbanken starten, Testabhängigkeiten ziehen und ihre Umgebung selbst aufbauen. Und sie können Docker in Docker betreiben – die Sandbox bringt einen privaten Docker-Daemon mit, in dem Images gebaut und Container samt Docker-Compose-Projekten gestartet werden können. Das Bemerkenswerte: Diese Container tauchen nie im docker ps des Hosts auf, und beim Löschen der Sandbox verschwinden Images, Container und Volumes mit ihr. Für Testläufe und Reproduzierbarkeit ist das ein klarer Vorteil – die Umgebung ist per Definition wegwerfbar.

Wer von außen auf einen Dienst zugreifen will, den der Agent gestartet hat, gibt gezielt Ports frei – entweder schon bei der Erstellung (sbx run --publish 8080:3000 …) oder später per sbx ports. Netzwerkseitig bleibt das konservativ: Ohne Freigabe ist nichts von außen erreichbar. Dienste auf dem Host erreicht der Agent über den Hostnamen host.docker.internal – wobei auch das nur funktioniert, wenn der entsprechende Host-Port in der Netzwerk-Policy erlaubt ist. Man spürt an diesen Details, dass die Sicherheitsphilosophie durchgängig ist: Freigeben statt stillschweigend erlauben.

Die Sandbox als Baukasten: Kits, Templates & Skills

Eine weitere Beobachtung aus dem Meetup: Docker Sandboxes ist als Produkt-Ökosystem angelegt, nicht nur als einzelnes Tool. Neben der Basis-Installation gibt es laut Doku und Docker-Blog mehrere Bausteine, die das Arbeiten erleichtern sollen:

Gerade der CI-Betrieb ist erwähnenswert: Wer Agent-Tasks in Pipelines ausführen will, bekommt damit einen dokumentierten, reproduzierbaren Weg. Und weil Secrets global gespeichert und per Proxy injiziert werden, müssen auch in der Pipeline keine Klartext-Keys in der Sandbox liegen.

Wo die Grenzen liegen – und was die Zeit erst zeigen muss

Im Meetup haben wir uns bewusst Zeit für die unbequemen Fragen genommen. Einige Punkte verdienen eine ehrliche Einordnung – und bei manchen gilt schlicht: abwarten.

Die ehrlichste Formel des Abends: Docker Sandboxes ist ein Architektur-Statement – „gib dem Agenten Autonomie, aber begrenze seinen Radius". Ob die microVM-Grenze unter Dauerbelastung hält, was sie verspricht, wird die Praxis in den nächsten Monaten zeigen. Wir bleiben da neugierig und dran – und berichten, sobald sich das Bild schärft.

Vom Deepdive zur Praxis: Wo lernt man sowas richtig?

Ein Thema, das im Meetup immer wieder hochkam, ist der Weg dahin: Docker Sandboxes zu verstehen setzt voraus, dass man versteht, wie Container, Netzwerke und Agenten eigentlich funktionieren. Genau für diesen Übergang – vom Interesse zum anwendbaren Know-how – gibt es einen ehrlich gemeinten Hinweis, der am Ende dieses Abends auch für sich selbst stand: Wer in die Tiefe gehen will, profitiert von einer strukturierten KI Weiterbildung gefördert durch den Staat – etwa über die AZAV-zertifizierten Angebote von AI READY, die per Bildungsgutschein von Jobcenter oder Agentur für Arbeit finanziert werden können.

Der Zusammenhang ist ein praktischer: Themen wie Agent-Architektur, Sicherheit und Container gehören in einer geförderten KI-Weiterbildung zum Curriculum – und die Mischung aus Theorie und Hands-on ist genau das, was beim Thema Docker Sandboxes den Unterschied macht. Wer sich dafür interessiert, kann sich unverbindlich beraten lassen.

Fazit: Nutzen oder Hype?

Unser Eindruck nach dem Meetup – und das ist eine Einordnung, keine Prophezeiung: Docker Sandboxes löst ein reales Problem (Agent-Autonomie ohne unkontrollierten Host-Zugriff) mit einer nachvollziehbaren Architektur (microVM + Workspace-Mount + Proxy). Die Demo-Workflows funktionieren, die Secrets-Logik ist durchdacht, und der Bezug zu realen Angriffsszenarien wie Nx/s1ngularity ist unmittelbar spürbar.

Was bleibt, ist die Ehrlichkeit: Vieles an diesem Produkt ist noch jung, manches davon Marketing-Ton, und die Beweislast liegt in der Praxis, nicht in der Doku. Genau deshalb lohnt es sich, das Thema im Auge zu behalten – und sich das Wissen anzueignen, um solche Entwicklungen selbst einordnen zu können. Wer beim nächsten Meetup dabei sein will oder den Einstieg in die geförderte Weiterbildung sucht: Wir freuen uns auf dich.