KI-Coding-Agents in Docker-Sandboxes isolieren: sicher und reproduzierbar

KI-Coding-Agents (Claude Code, Codex CLI u. a.) haben schreibenden Zugriff auf das Dateisystem, führen beliebige Shell-Befehle aus und können bei uneingeschränktem Netzwerkzugriff Daten nach außen übertragen. Der Hugging-Face-Vorfall vom Juli 2026 macht das anschaulich: Eine Tailscale-Analyse rekonstruierte 17.600 Angreifer-Aktionen, 136 aus einem Kubernetes-Secret gestohlene Credentials – und 181 unberechtigte Nodes im Corporate-Tailnet. Der Angriffsvektor war kein Rootkit, sondern schlicht mangelnde Egress-Kontrolle in einer automatisierten Umgebung.

Dieser Beitrag zeigt, wie Sie einen Coding-Agent in drei Isolationsstufen absichern: von einfachen Docker-Flags für netzwerklose Tasks bis zur microVM, wenn der Agent selbst Docker braucht.

Was Sandboxing für Agents bedeutet

Sandboxing heißt hier: den Agent in einem kurzlebigen, wegwerfbaren Container oder einer microVM laufen zu lassen, der genau das darf, was er braucht – und nichts mehr. Das bringt drei Vorteile: Reproduzierbarkeit (keine „läuft nur bei mir"-Situation), Filesystem-Isolation (der Agent kann nicht außerhalb seines Workspaces schreiben) und Netzwerk-Egress-Kontrolle (keine unbeabsichtigten API-Calls an externe Dienste).

Die Faustregel: Je größer die Autonomie des Agents und je sensibler die Umgebung, desto stärker sollte die Isolation sein.

Drei Isolationsstufen

Stufe 1  Docker-Flags (--cap-drop, --read-only, ...)  einfachste Haertung, netzwerklose Tasks
Stufe 2  gVisor-Runtime (runsc)                       Syscall-Isolation im User-Space
Stufe 3  Docker Sandboxes (sbx)                       eigener Kernel, DinD sicher moeglich

Stufe 1: Docker-Flag-Härtung

Für einen Agent, der ausschließlich lokal arbeitet – keine API-Calls, kein Docker – genügt eine Kombination aus Standard-Flags:

docker run --rm \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 512m \
  --cpus 1.0 \
  -v "$PWD/workspace":/workspace:rw \
  -v "$PWD/tools":/tools:ro \
  myimage

Was diese Flags tun:

• --read-only + --tmpfs /tmp: Das Root-Filesystem ist schreibgeschützt; nur /tmp (im RAM, nicht persistent) ist beschreibbar.
• --cap-drop ALL: Alle Linux Capabilities entfernt – kein CAP_NET_RAW, kein CAP_SYS_PTRACE, kein CAP_DAC_OVERRIDE.
• --security-opt no-new-privileges: Verhindert Privilege Escalation über setuid-Binaries.
• -v ...:ro / :rw: Read-only-Tools und beschreibbarer Workspace sauber getrennt.

Das Netzwerk wird hier absichtlich nicht gesperrt: --network none macht Claude Code sofort nicht mehr startfähig, da die CLI api.anthropic.com für jeden API-Call benötigt. Wenn Sie den Egress einschränken möchten, setzen Sie iptables-Regeln mit einer Allowlist für die benötigten Endpunkte – die fertige Vorlage dazu liefert der offizielle Dev Container (Stufe 3).

Stufe 2: gVisor-Runtime

gVisor ist ein User-Space-Kernel von Google. Statt Syscalls direkt an den Host-Kernel weiterzureichen, verarbeitet ein User-Space-Prozess (runsc) sie vorab. Ein Syscall-Exploit im Container erreicht damit den Host-Kernel nicht.

Installation unter Ubuntu (Docker Engine 29.x):

curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor \
  -o /usr/share/keyrings/gvisor-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) \
  signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] \
  https://storage.googleapis.com/gvisor/releases release main" \
  | sudo tee /etc/apt/sources.list.d/gvisor.list > /dev/null

sudo apt-get update && sudo apt-get install -y runsc
# Das Paket registriert runsc beim Docker-Daemon automatisch (post-install Script).
# Falls nicht (z. B. Docker war beim Install gestoppt):
#   sudo runsc install && sudo systemctl restart docker
sudo systemctl restart docker

Anschließend genügt --runtime=runsc beim docker run:

docker run --runtime=runsc --rm \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 512m \
  -v "$PWD/workspace":/workspace:rw \
  myimage

Der Overhead: leicht erhöhte CPU-Last und Netzwerklatenz, da der Netzwerk-Stack im User-Space läuft. Für typische Coding-Agent-Tasks fällt das kaum ins Gewicht.

Stufe 3: Docker Sandboxes (sbx)

Sobald der Agent selbst docker build oder docker run aufruft – Claude Code tut das regelmäßig –, versagt die Flag-Härtung. Docker-in-Docker erfordert privilegierten Modus, was die Isolation aufhebt. Die Lösung: ein eigener Kernel pro Session in einer microVM.

Docker Sandboxes (sbx) ist ein kostenloses, standalone Tool (kein Docker Desktop nötig). Jeder Aufruf startet eine microVM mit eigenem Docker-Daemon; der aktuelle Projektordner wird hinein synchronisiert.

# Installation (Ubuntu, Docker Engine 29.x)
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx

# Agent starten
cd ~/mein-projekt
sbx run claude

Die Isolation in der Übersicht:

+---------------------------------+
|  Host (Linux / macOS / Win)     |
|                                 |
|  +---------------------------+  |
|  |  microVM (KVM / HVF)      |  |
|  |                           |  |
|  |  +---------------------+  |  |
|  |  |  Docker-Daemon      |  |  |
|  |  +---------------------+  |  |
|  |  |  Agent-Container    |  |  |
|  |  |  /workspace (sync)  |  |  |
|  |  +---------------------+  |  |
|  +---------------------------+  |
|                                 |
|  kein gemeinsamer Host-Kernel   |
+---------------------------------+

Der Agent kann Container starten, Packages installieren und das Dateisystem beliebig nutzen – alles innerhalb der microVM. Zum Host-Kernel gibt es keinen Pfad.

Drei typische Stolperfallen

1. Docker-Socket-Mount bricht die Isolation. -v /var/run/docker.sock:/var/run/docker.sock erlaubt dem Agent, privilegierte Container auf dem Host zu starten – vollständiger Sandbox-Break. Den Socket niemals mounten; wenn Docker-in-Docker nötig ist, sbx oder Sysbox verwenden.

2. --network none macht Agent-CLIs nicht startfähig. Coding-Agent-CLIs brauchen mindestens Zugriff auf ihre API-Endpunkte. Kein Pauschalverbot, sondern eine Egress-Allowlist: Der offizielle Claude Code Dev Container liefert eine default-deny iptables-Firewall mit Allowlist als fertige Vorlage.

3. Langlebige Credentials im Container. Selbst bei intakter Netzwerk-Isolation können API-Keys, die als Environment-Variablen injiziert wurden, exfiltriert werden – der HF-Vorfall zeigt es. Nur kurzlebige, session-spezifische Tokens injizieren und Cloud-Metadata-Endpoints (AWS IMDS, GCP Metadata API) in der Firewall sperren.

Wie es weitergeht

Als nächster Schritt empfiehlt sich der offizielle Claude Code Sandbox-Environments-Artikel mit der fertigen Dev-Container-Vorlage inklusive Egress-Firewall. Für parallele Agent-Sessions oder den Einsatz auf Kubernetes: Anthropic Self-Hosted Sandboxes. Zur Vertiefung der Syscall-Ebene: gVisor User Guide und Docker Sandboxes Dokumentation.