Jeder KI-Agent, der Code generiert und ausführt, führt Anweisungen aus, die kein Mensch geprüft hat. Eine einzige Prompt Injection reicht, um einen hilfreichen Coding-Assistenten in einen Angreifer zu verwandeln, der Shell-Befehle mit Ihren Zugangsdaten ausführt. Sandboxing ist die Kontrolle, die das verhindert: Die Ausführungsumgebung wird isoliert, sodass selbst vollständig kompromittierter Code weder das Host-System noch das Netzwerk noch Ihre Daten erreichen kann.
Drei Technologien dominieren das KI-Agent-Sandboxing 2026: MicroVMs (Firecracker, Kata Containers), gVisor (Googles User-Space-Kernel) und WebAssembly. Jede bietet ein unterschiedliches Gleichgewicht aus Isolationsstärke, Startgeschwindigkeit und Kompatibilität. Docker-Container, der Standard für die meisten Entwickler, sind laut Docker-eigener Dokumentation ausdrücklich keine Sicherheitsgrenze für nicht vertrauenswürdigen Code.
Dieser Leitfaden vergleicht alle vier Ansätze mit konkreten Zahlen, nennt die Plattformen, die auf jeder Technologie aufbauen, und fasst zusammen, was OWASP und NVIDIAs AI Red Team für produktive Agent-Deployments empfehlen.
Warum Container nicht ausreichen
Die meisten KI-Agenten führen generierten Code heute in Docker-Containern aus. Das fühlt sich sicher an: Der Prozess ist vom Host-Dateisystem isoliert, hat seinen eigenen Netzwerk-Namespace, und Cgroups begrenzen die Ressourcennutzung. Aber Container teilen sich den Host-Kernel. Ein Kernel-Exploit im Container-Code gibt dem Angreifer Root-Zugriff auf die Host-Maschine.
Das ist keine Theorie. Trend-Micro-Forscher demonstrierten mehrere Schwachstellen in ChatGPTs Docker-basierter Code-Interpreter-Sandbox. Durch das Hochladen einer manipulierten Excel-Datei injizierten sie persistente Hintergrundprozesse, die das /mnt/data-Verzeichnis auf hochgeladene Dokumente überwachten und Hyperlinks durch Phishing-URLs ersetzten. Dynamische Code-Verschleierung via Base64-Kodierung umging die Erkennung. OpenAI hat die spezifische Lücke im Dezember 2024 gepatcht, aber die architektonische Schwäche bleibt: Container vertrauen dem Host-Kernel.
Wie Rivets Reverse-Engineering-Analyse es formuliert: „Most of the industry agrees that containers are a bad practice for untrusted code execution."
Die OWASP Top 10 for Agentic Applications, veröffentlicht im Dezember 2025, haben dies in ASI05 (Unexpected Code Execution) formalisiert: „Software-only sandboxing is insufficient; all code generated by an LLM must be executed in a secure, isolated sandbox environment with no access to the underlying host system." Das bedeutet: hardwaregestützte Isolation oder zumindest ein User-Space-Kernel, der Syscalls abfängt, bevor sie den Host erreichen.
MicroVMs: Die hardwaregestützte Option
MicroVMs geben jedem Workload eine eigene leichtgewichtige virtuelle Maschine mit dediziertem Kernel. Der Host-Kernel wird dem Gast-Code nie exponiert. AWS hat Firecracker genau dafür entwickelt: Es betreibt Lambda und Fargate und führt Millionen nicht vertrauenswürdiger Workloads pro Sekunde aus.
Die Zahlen überzeugen. Firecracker startet in rund 125ms zum User-Space-Code bei weniger als 5 MiB Speicher-Overhead pro VM. Ein einzelner Host kann bis zu 150 VMs pro Sekunde starten. Kata Containers bietet vergleichbare hardwaregestützte Isolation mit Kubernetes-nativer Orchestrierung bei rund 200ms Startzeit.
Wer MicroVMs für KI-Agenten einsetzt
E2B hat seine gesamte Plattform auf Firecracker aufgebaut. Jede Sandbox ist eine MicroVM mit rund 150ms Kaltstart und konfigurierbaren Sitzungen bis zu 24 Stunden. E2B nutzt ein Snapshot/Restore-Modell: Dockerfiles erstellen ein vorkonfiguriertes VM-Image, neue Sandboxen werden davon wiederhergestellt. Das Projekt hat über 8.900 GitHub-Stars und native SDKs für Python und TypeScript.
Docker Sandboxes (Docker Desktop 4.58, Januar 2026) sind von Containern auf MicroVMs für KI-Agent-Isolation umgestiegen. Rivets Reverse Engineering enthüllte die Architektur: Ein sandboxd-Daemon stellt eine /vm-API über einen Unix-Socket unter ~/.docker/sandboxes/sandboxd.sock bereit. Jede Sandbox bekommt ihren eigenen isolierten Docker-Daemon (teilt nicht /var/run/docker.sock), mit Netzwerkverkehr über einen filterenden Proxy, der MITM-TLS-Inspektion durchführt. Docker Sandboxes unterstützen Claude Code, Codex CLI, Copilot CLI, Gemini CLI und Kiro.
Fly.io Machines verpackt Firecracker in eine REST-API für kurzlebige Maschinen mit Start unter einer Sekunde. Sie erstellen eine Maschine, führen den Code Ihres Agenten aus und zerstören sie in einem einzigen API-Aufruf.
Der Kompromiss bei MicroVMs ist Kompatibilität. Sie erfordern KVM-Unterstützung (nur Linux für Self-Hosting; Docker Desktop nutzt Apples Virtualization.framework auf macOS und Hyper-V auf Windows). Image-Management fehlen Dockers Shared Layers, sodass die Festplattennutzung linear mit der VM-Anzahl wächst. Für nicht vertrauenswürdigen Code von KI-Agenten ist das Sicherheitsmodell aber unübertroffen.
gVisor: Die Syscall-Firewall
Googles gVisor geht einen anderen Weg. Statt Hardware zu virtualisieren, schaltet es einen User-Space-Kernel (genannt „Sentry") zwischen den Gast-Prozess und den Host-Kernel. Jeder Systemaufruf des isolierten Prozesses wird abgefangen, validiert und entweder im User Space behandelt oder über eine minimale, geprüfte Schnittstelle an den Host weitergeleitet.
Die Startzeit liegt bei 50-100ms. Bei CPU-gebundenen Workloads ist der Overhead nahezu null. I/O-intensive Workloads sehen 10-30% Overhead, wobei aktuelle Optimierungen diese Lücke verkleinert haben: Ein Rootfs-Overlay halbierte den Sandboxing-Overhead für Builds, und Directfs reduzierte die Workload-Zeit um 12%.
gVisor bietet keine hardwaregestützte Isolation. Ein hinreichend ausgefeilter Kernel-Exploit könnte theoretisch aus Sentry ausbrechen. Aber es reduziert die Kernel-Angriffsfläche drastisch: Statt Hunderte von Syscalls offenzulegen, implementiert gVisor nur die Teilmenge, die es verifizieren kann. Google vertraut darauf genug, um Cloud Run und App Engine auf gVisor für Multi-Tenant-Isolation zu betreiben.
Wer gVisor für KI-Agenten einsetzt
Modal führt KI-Agent-Workloads in gVisor-Containern mit Kaltstarts unter einer Sekunde und Autoscaling auf über 20.000 gleichzeitige Container aus. Lovable nutzt Modal im großen Maßstab für die Ausführung von LLM-generiertem Code. Modals Preise beginnen bei 0,047 $/vCPU-Stunde und 0,008 $/GB-Stunde.
Northflank bietet sowohl gVisor- als auch MicroVM-Isolation (Kata Containers) und verarbeitet monatlich über 2 Millionen isolierte Workloads. Die Plattform lässt Sie das Isolationsniveau pro Workload wählen, mit gVisor-Preisen ab 0,01667 $/vCPU-Stunde.
Für Teams, die bessere Performance als MicroVMs und stärkere Isolation als Container brauchen, bietet gVisor einen praktischen Mittelweg. Die Kompatibilität ist für die meisten Workloads gut: Wenn Ihr Code in einem Standard-Linux-Container läuft, wird er wahrscheinlich auch unter gVisor ohne Änderung laufen.
WebAssembly: Die schnellste, am stärksten eingeschränkte Option
WebAssembly (WASM) isoliert Code auf Befehlsebene. Programme werden in ein Binärformat kompiliert, das in einer speichersicheren virtuellen Maschine mit automatischer Boundschecking bei jedem Speicherzugriff läuft. Es gibt kein Syscall-Interface: Die Sandbox stellt nur die Fähigkeiten bereit, die Sie explizit gewähren.
Der Start dauert rund 10ms. Der Speicher-Overhead ist minimal. Die Ausführungsgeschwindigkeit nähert sich nativer Performance für kompilierte Sprachen wie Rust, Go und C.
Der Haken: Die meisten KI-generierten Programme sind Python. Python in WASM auszuführen erfordert Pyodide (CPython zu WebAssembly kompiliert), was für viele Anwendungsfälle funktioniert, aber Einschränkungen bei C-Erweiterungen, Netzwerk und Dateisystemzugriff hat. NVIDIAs AI Red Team empfiehlt WASM/Pyodide für browserbasierte Ausführung von LLM-generiertem Code, wo es die Berechnung auf die Client-Seite verlagert und Server-Kompromittierung vollständig verhindert.
Wer WASM für KI-Agenten einsetzt
Cloudflare Workers nutzt V8-Isolates kombiniert mit WASM für Edge-Ausführung. Ihr Sandbox SDK bietet eine zweckgebundene Umgebung für nicht vertrauenswürdigen Code mit rund 1ms Startzeit für V8-Isolates.
LangChain Sandbox verwendet Pyodide und Deno für isolierte Python-Ausführung. Das Projekt gibt ausdrücklich an, dass es „not recommended for production use cases" ist, was zeigt, wo die WASM-Reife für allgemeine Agent-Workloads steht.
Hugging Face smolagents liefert einen WasmExecutor, der agentengeneriertes Python in Pyodide innerhalb einer Deno-Runtime ausführt. Das ist die zugänglichste Option zum Experimentieren.
WASM ist die richtige Wahl, wenn Sie das Code-Format kontrollieren (kompilierte Sprachen, definierte Python-Teilmengen) und maximale Startgeschwindigkeit brauchen. Es ist die falsche Wahl, wenn Agenten beliebiges Python generieren, das auf C-Erweiterungen, Netzwerkzugriff oder Dateisystemoperationen angewiesen ist.
Der Vergleich: Welche Sandbox für welchen Agenten
| Technologie | Isolationsniveau | Startzeit | Speicher-Overhead | Python-Support | Ideal für |
|---|---|---|---|---|---|
| Firecracker MicroVM | Hardwaregestützt (eigener Kernel) | ~125ms | <5 MiB | Volles Linux | Nicht vertrauenswürdiger Code |
| Kata Containers | Hardwaregestützt | ~200ms | Höher | Volles Linux | Kubernetes in Produktion |
| gVisor | Syscall-Interception | 50-100ms | Mittel | Volles Linux | Rechenintensive SaaS |
| WASM/Pyodide | Runtime-Speichersicherheit | ~10ms | Sehr niedrig | Eingeschränkt | Browser, definierte Aufgaben |
| V8 Isolates | Runtime-Isolation | ~1ms | Sehr niedrig | Nein (nur JS/TS) | Edge Functions |
| Docker-Container | Namespace-basiert (geteilter Kernel) | 10-50ms | Sehr niedrig | Volles Linux | Nur vertrauenswürdiger Code |
Die Entscheidung hängt von Ihrem Bedrohungsmodell ab. Wenn Agenten benutzerübermittelten oder durch Prompt Injection kompromittierten Code ausführen (was auf jeden Agenten mit Code-Generierung zutrifft), sind MicroVMs oder gVisor Ihre Optionen. Wenn Agenten nur vorab geprüften Code aus Ihrem eigenen Repository ausführen, können Container ausreichen. Wenn Sie unter 10ms Startzeit für einfache Berechnungen brauchen, funktioniert WASM innerhalb seiner Grenzen.
NVIDIAs AI Red Team macht einen entscheidenden Punkt, der die Entscheidung vereinfacht: „Performance overhead from virtualization is typically modest compared to LLM latency." Ihr Agent wartet 500ms bis 5s auf die Modellantwort. 125ms für einen Firecracker-Start sind Hintergrundrauschen.
Über Isolation hinaus: Netzwerk- und Dateisystemkontrollen
Eine Sandbox, die Code-Ausführung isoliert, aber uneingeschränkten Netzwerkzugriff erlaubt, ist nur eine halbe Sandbox. Ein kompromittierter Agent kann weiterhin Daten exfiltrieren, Reverse Shells aufbauen oder mit Command-and-Control-Servern kommunizieren.
NVIDIAs praktische Sicherheitsanleitung empfiehlt drei zusätzliche Kontrollen:
Netzwerk-Egress-Beschränkungen. Leiten Sie allen Traffic über einen HTTP-Proxy mit Domain-Allowlists. Blockieren Sie beliebige ausgehende Verbindungen, schränken Sie DNS-Auflösung ein und verweigern Sie Nicht-HTTP-Protokolle. Docker Sandboxes implementieren dies mit einem filterenden Proxy unter host.docker.internal:3128. Anthropics Claude Code leitet allen Netzwerkverkehr über einen Unix-Domain-Socket-Proxy, der Domain-Allowlists durchsetzt.
Dateisystem-Schreibschutz. Verhindern Sie Schreibzugriffe außerhalb des aktiven Arbeitsbereichs. NVIDIA nennt ausdrücklich Shell-Initialisierungsdateien (~/.zshrc, ~/.bashrc), Git-Konfiguration (~/.gitconfig) und Binärverzeichnisse (~/.local/bin) als Ziele, die auf OS-Ebene geschützt werden müssen, nicht auf Anwendungsebene.
Konfigurationsdatei-Sperrung. Agent-Konfigurationsdateien (.cursorrules, CLAUDE.md, copilot-instructions.md, MCP-Server-Startskripte) müssen für den isolierten Prozess schreibgeschützt sein. Die IDEsaster-Enthüllung im Dezember 2025 fand über 30 Schwachstellen in KI-Coding-Tools (Cursor, Windsurf, Kiro, GitHub Copilot, Zed, Roo Code, Junie, Cline), bei denen Prompt Injection über diese Dateien zur Code-Ausführung führte. 24 CVEs wurden vergeben.
Anthropics Ansatz für Claude-Code-Sandboxing kombiniert diese Schichten: bubblewrap unter Linux und Apples Seatbelt-Framework unter macOS bieten Dateisystem-Isolation, während ein Netzwerk-Proxy Domain-Beschränkungen durchsetzt. Das Ergebnis: 84% weniger Permission-Prompts im internen Einsatz, weil die Sandbox Sicherheitsdurchsetzung übernimmt, die Benutzer zuvor manuell genehmigen mussten.
Sandbox-Architektur richtig gestalten
Die OWASP Agentic Top 10 führen ein Prinzip ein, das Ihr Sandbox-Design leiten sollte: „Least-Agency." Agenten sollten die minimale Autonomie erhalten, die erforderlich ist. Autonomie ist „a feature to be earned, not a default setting."
Auf Sandboxing angewandt bedeutet das:
1. Kurzlebige Sandboxen. Erstellen Sie für jede Aufgabe eine frische Umgebung. Zerstören Sie sie nach Abschluss. Das verhindert die Ansammlung von Zugangsdaten, persistente Backdoors und Zustandsverschmutzung zwischen Durchläufen. NVIDIA empfiehlt, dass „approvals should never be cached or persisted" über Sandbox-Instanzen hinweg.
2. Gestaffelte Autorisierung. Nicht jede Agent-Aktion braucht das gleiche Isolationsniveau. NVIDIA schlägt vier Stufen vor: Unternehmensweite Sperren (nicht verhandelbar), Workspace-interne Operationen (automatisch genehmigt), Allowlisted-externe Operationen (vorab genehmigte Domains und APIs) und Default-Deny für alles andere.
3. Sandboxing auf alle gestarteten Prozesse ausweiten. Hooks, MCP-Server-Initialisierung, Plugin-Laden und Skill-Ausführung führen alle Code aus. Wenn Sie nur den Hauptagenten-Prozess sandboxen, aber Hooks ungeschützt lassen, haben Sie einen Bypass. CVE-2025-61260 in OpenAIs Codex CLI nutzte genau das aus: MCP-Server-Einträge wurden beim Start ohne Benutzerberechtigung ausgeführt.
4. Überwachen, protokollieren, alarmieren. Sandbox-Verstöße (blockierte Netzwerkanfragen, verweigerte Dateischreibzugriffe, beendete Prozesse) sind Erkennungssignale. Protokollieren Sie sie. Alarmieren Sie bei Mustern. Ein isolierter Agent, der wiederholt versucht, auf /etc/shadow zuzugreifen, sagt Ihnen etwas.
Für DACH-Unternehmen ist dabei besonders relevant: Der EU AI Act klassifiziert KI-Systeme mit autonomer Code-Ausführung potenziell als Hochrisiko. Die Compliance-Frist für die meisten Bestimmungen ist der 2. August 2026. Wer Sandboxing-Infrastruktur nicht selbst aufbauen will, kann auf verwaltete Dienste wie Amazon Bedrock AgentCore zurückgreifen, der native Unterstützung für LangChain, LangGraph, CrewAI und Strands bietet.
Häufig gestellte Fragen
Warum brauchen KI-Agenten Sandboxing?
KI-Agenten generieren und führen Code aus, den kein Mensch geprüft hat. Ein Prompt-Injection-Angriff kann den Agenten dazu bringen, beliebige Befehle mit den Berechtigungen des Agent-Prozesses auszuführen. Sandboxing isoliert die Ausführungsumgebung, sodass selbst kompromittierter Code nicht auf das Host-System, Netzwerk oder Daten zugreifen kann. OWASPs Top 10 for Agentic Applications (ASI05) fordert explizit isolierte Ausführung für allen LLM-generierten Code.
Was ist die sicherste Methode zum Sandboxing von KI-Agent-Code?
MicroVMs (Firecracker, Kata Containers) bieten die stärkste Isolation, weil jeder Workload seinen eigenen Kernel mit hardwaregestützten Grenzen via KVM bekommt. Firecracker startet in rund 125ms bei weniger als 5 MiB Overhead. gVisor bietet starke Isolation durch Syscall-Interception ohne den Overhead vollständiger Virtualisierung. Standard-Docker-Container teilen den Host-Kernel und gelten nicht als Sicherheitsgrenze für nicht vertrauenswürdigen Code.
Kann WebAssembly KI-Agent-Python-Code sandboxen?
Ja, mit Pyodide (CPython zu WASM kompiliert). WASM bietet die schnellste Startzeit (~10ms) und starke Speichersicherheit. Allerdings hat Pyodide Einschränkungen: Viele C-Erweiterungen funktionieren nicht, Netzwerk ist eingeschränkt, und Dateisystemzugriff ist limitiert. WASM eignet sich am besten für klar definierte Berechnungsaufgaben, nicht für allgemeine Python-Ausführung. LangChains WASM-Sandbox warnt ausdrücklich, dass sie nicht für den Produktionseinsatz empfohlen wird.
Welche Sandbox nutzt Docker für KI-Coding-Agenten?
Docker Desktop 4.58 (Januar 2026) führte Docker Sandboxes mit MicroVMs ein, nicht mit Standard-Containern. Jede Sandbox betreibt ihren eigenen isolierten Docker-Daemon in einer leichtgewichtigen VM, wobei der Netzwerkverkehr über einen filterenden Proxy mit TLS-Inspektion geleitet wird. Docker Sandboxes unterstützen Claude Code, Codex CLI, Copilot CLI, Gemini CLI und Kiro.
Wie klassifiziert OWASP Risiken der KI-Agent-Code-Ausführung?
Die OWASP Top 10 for Agentic Applications (Dezember 2025) klassifizieren unerwartete Code-Ausführung als ASI05. Sie stellen fest, dass rein softwarebasiertes Sandboxing unzureichend ist und dass aller LLM-generierter Code in einer isolierten Sandbox ohne Zugriff auf das Host-System ausgeführt werden muss. Das Framework führt außerdem das Least-Agency-Prinzip ein: Agenten sollen die minimale erforderliche Autonomie erhalten.