Wie sicher ist Docker Sandbox? KI-Agenten mit Java testen

Kevin Wittek und ich haben ein absichtlich verwundbares Java-Projekt durch Docker Sandbox laufen lassen, um zu prüfen, ob sbx einen KI-Agenten im YOLO-Modus wirklich einsperren kann. Die Isolation hat gehalten, und das verändert die Art, wie ich über sicheres Arbeiten mit Agenten denke.

Die Frage hinter dieser Session war einfach: Wenn man einem KI-Agenten breiten Zugriff und minimale Einschränkungen gibt, was verhindert dann schädliches Verhalten? Docker Sandbox (sbx) ist Dockers Antwort darauf. Kevin Wittek war zu Gast, um sbx mit einem echten, absichtlich verwundbaren Java- und Maven-Projekt zu testen, das bei Gelegenheit Credentials leaken würde.

Co-Speaker

Kevin Wittek

Engineering Leader bei Docker

Kevin ist Teil der Docker- und Testcontainers-Organisationen und bringt tiefes Know-how in Containerisierung, Developer Tooling und Testing-Workflows mit. Er war dabei, um Docker Sandbox in einem echten Sicherheitsszenario auf Herz und Nieren zu prüfen.

GitHub LinkedIn X Bluesky

Was ist Docker Sandbox?

Docker Sandbox erstellt isolierte Container-Umgebungen speziell für die Ausführung von KI-Agenten. Jede Sandbox bekommt ein eigenes Dateisystem, ein eigenes Netzwerk und einen eigenen Credential-Scope. Die wichtigsten Eigenschaften:

Dateien werden nur gemountet, nicht dauerhaft verändert. Das Host-Dateisystem ist nicht zugänglich, außer was explizit eingebunden wird.
Das Netzwerk ist standardmäßig eingeschränkt. Ausgehende Verbindungen zu unbekannten Hosts werden blockiert, außer sie werden explizit erlaubt.
Credentials werden nie in der Sandbox gespeichert. Sie werden über Dockers Credential-Layer proxied, sodass der Agent etwas sieht, das funktioniert, aber den echten Token nicht extrahieren kann.

Docker Sandbox Sicherheitsmodell: isoliertes Dateisystem, eingeschränktes Netzwerk und proxied Credentials

Quelle: Docker Sandbox Security — Docker Docs © Docker, Inc.

Es gibt zwei Möglichkeiten zur Interaktion: ein TUI mit Mausunterstützung, das einfach zu bedienen ist, sowie das sbx CLI für skriptbasierte oder direktere Workflows.

GitHub Copilot einrichten

Das war der nicht offensichtlichste Teil der Session. GitHub Copilot mit einer Sandbox zu verbinden, erforderte zwei bestimmte Befehle, um den Credential-Proxy zu verdrahten:

gh auth refresh -h http://github.com/ -s copilot
gh auth token | sbx secret set -g github

Danach funktionieren sowohl GitHub Copilot als auch Claude Code ohne Probleme. Der wichtige Punkt: Auch die eigenen Credentials des KI-Agenten werden nicht in der Sandbox gespeichert. Sie werden proxied, sodass die Sandbox Anfragen im Namen des Agenten authentifizieren kann, ohne den echten Token preiszugeben.

Der Sicherheitstest: Einen Credential-Leak blockieren

Das Demo-Projekt unter github.com/JohannesRabauer/docker-sandbox-demo ist darauf ausgelegt, beim Ausführen etwas Bestimmtes zu tun: Es versucht, eine Anfrage an eine unbekannte externe URL zu senden, die Credential-Daten mitführen würde. Ein klassisches Szenario für versehentliche Datenexfiltration.

Wir haben den Agenten im YOLO-Modus laufen lassen: minimale Einschränkungen, breite Berechtigungen, mach was du willst. Das Projekt wurde zweimal ausgeführt.

Beim ersten Mal war das README vorhanden. LLMs sind erstaunlich gut darin, schadhaften Code aus der Dokumentation heraus zu erkennen, und genau das ist passiert: Der Agent hat das README gelesen, verstanden, dass der Code auf Credential-Leak ausgelegt ist, und den gefährlichen Teil nicht ausgeführt. Die Sandbox musste nicht eingreifen.

Beim zweiten Mal haben wir das README entfernt. Ohne diesen Kontext hatte der Agent keine Möglichkeit zu wissen, dass der Code schädlich war, und hat ihn ausgeführt. Genau hier hat die Sandbox eingegriffen: Die ausgehende Anfrage an die unbekannte URL wurde blockiert. Bei 43:00 haben wir uns den blockierten Request direkt angeschaut. Die Netzwerkisolierung hat aufgefangen, was das fehlende README nicht mehr verhindern konnte.

Docker in Docker: Testcontainers funktioniert

Eine der praktischeren Fragen für Java-Entwickler: Kann man Testcontainers innerhalb einer Docker Sandbox betreiben? Die Antwort ist ja. Wir haben ein Testcontainers-Projekt innerhalb von sbx ausgeführt, und es hat wie erwartet funktioniert. Das Starten von Containern innerhalb der Sandbox wird unterstützt.

Wir haben bei 01:22:40 auch kurz diskutiert, k3s oder Kubernetes in einer Sandbox zu betreiben, haben es aber nicht ausprobiert.

Fun-Projekt: Echtzeit-Renn-Dashboard

Für die zweite Hälfte der Session haben wir ein kleines Projekt innerhalb der Sandbox gebaut: ein Live-Racing-Daten-Dashboard mit Vaadin, Spring Boot und dem xdev chartjs-java-model-Komponenten für die Chart-Darstellung. Sowohl Claude (über das sbx CLI) als auch GitHub Copilot haben daran mitgewirkt.

Eine Funktion, die wir gezielt getestet haben, war Port Forwarding, mit dem ein Port aus der laufenden Sandbox auf den Host gemappt werden kann. Damit war es möglich, die laufende Vaadin-App im Browser auf dem Host zu öffnen, während der gesamte Spring-Boot-Prozess in der Sandbox blieb.

Was noch zur Sprache kam

Ein paar Themen kamen als produktive Abstecher auf:

Human in the loop (45:45) wir haben diskutiert, wo menschliche Kontrolle noch wichtig ist, wenn KI den Code schreibt. Meine Position: KI-generierter Code muss irgendwann von einem Menschen geprüft werden, und Pull Requests sind dafür ein naheliegender Zeitpunkt. Kevin hat das etwas hinterfragt: Vielleicht ist der PR nicht die richtige Ebene, sondern es kommt darauf an, dass ganze Releases gründlich validiert werden, ob durch automatisierte Tests oder durch Menschen. Kein abschließendes Fazit, aber eine nützliche Unterscheidung.

Prompt-Scrubbing (53:40) filtert oder bereinigt sbx Prompts, bevor sie das Modell erreichen? Kurz diskutiert; das ist kein aktuelles sbx-Feature.

Eigene Agenten-Templates mit sbx-kits — sbx-kits ermöglichen es, eigene Sandbox-Umgebungen als Templates zu definieren. Wir hatten keine Zeit, das auszuprobieren, aber es ist ein nützlicher Erweiterungspunkt für Teams, die eine einheitliche Sandbox-Konfiguration über Projekte hinweg brauchen.

Lokale LLMs (01:33:30) der Weg ist: OpenCode innerhalb der Sandbox starten und mit einem lokalen Docker Model verbinden. Die beiden Gists beschreiben zwei verschiedene Wege, diese Verbindung einzurichten: kiview's Gist und doringeman's Gist. Für ein Demo reichte die Zeit nicht mehr.

Tastaturlayout (01:02:55) kurzer Abstecher zum Thema europäische Sonderzeichen auf amerikanischen Tastaturen. EurKey war die Empfehlung.

Fazit

Docker Sandbox ist jetzt mein bevorzugter Weg, KI-Agenten zu betreiben. Der Grund ist einfach: Die Isolation ist real. Dateien werden gemountet, nicht besessen. Netzwerkverbindungen zu unbekannten Hosts werden blockiert. Credentials werden proxied, nicht preisgegeben.

Das verändert die Dynamik erheblich. Statt jeden Schritt eines Agenten zu beobachten, kann man ihm den Raum geben zu arbeiten und danach die Ergebnisse reviewen. Die Sandbox übernimmt die Eindämmung. Das ist eine deutlich nachhaltigere Arbeitsweise mit Agenten, die breiten Tool-Zugriff brauchen.

Wie sicher ist Docker Sandbox? KI-Agenten mit Java testen