Agenten-Sandboxing 2026: Wie Sie KI-generierten Code im eigenen Rechenzentrum ausführen

Ein KI-Agent, der nur Text produziert, ist ein Chatbot. Ein Agent, der Code schreibt und ihn danach selbst ausführt, ist ein Ausführungssystem – und damit ein Sicherheitsproblem mit ganz anderen Eigenschaften. Sobald ein Modell pip install, curl oder ein Shell-Skript startet, gelten nicht mehr die Regeln der Prompt-Sicherheit, sondern die der Betriebssystem-Isolation.

Die Frage, die 2026 in jedem ernsthaften Agentic-AI-Projekt auf den Tisch kommt, lautet deshalb: Wo läuft der generierte Code, und was passiert, wenn er sich falsch verhält? Dieser Artikel beantwortet sie mit den drei realistischen Optionen – gehärteter Container, gVisor, MicroVM –, den dazugehörigen Messwerten und einer Topologie, die sich in ein eigenes Rack neben die Inferenz-Knoten stellen lässt.

Warum Prompt-Guardrails die Ausführungsebene nicht ersetzen

Guardrails sind eine gute Sache – aber sie wirken auf der falschen Ebene. Ein Guardrail prüft Eingaben und Ausgaben eines Modells: Es kann eine Anfrage blocken, eine Antwort filtern, eine Tool-Auswahl verhindern. Was es strukturell nicht kann: einen bereits gestarteten Prozess daran hindern, /etc/shadow zu lesen, einen Socket nach draußen zu öffnen oder ein gemountetes Verzeichnis zu überschreiben. Diese Entscheidungen fällt der Kernel, nicht der System-Prompt.

Damit ist die Architekturfrage entschieden, bevor man über Bypass-Quoten diskutiert: Sobald Tool Use echte Ausführung bedeutet, ist die Isolationsgrenze die Sicherheitsgrenze. Alles davor ist Vorfilterung.

Ein Agentenlauf ist keine einzelne Anfrage

Wie groß die Angriffsfläche tatsächlich ist, zeigt der Benchmark OSWorld 2.0 (arXiv 2606.29537). Er umfasst 108 Long-Horizon-Computer-Use-Workflows; Menschen brauchen dafür im Median rund 1,6 Stunden pro Aufgabe. Gemessen mit Claude Opus 4.7 bei maximalem Thinking fällt pro Aufgabe im Mittel 318 Tool-Calls an – gegenüber rund 30 in OSWorld 1.0. Ein einziger Agentenlauf ist also kein Request, sondern eine dreistellige Zahl von Ausführungsereignissen, von denen jedes einzelne einen Fehler oder einen Ausbruchsversuch enthalten kann.

Die Erfolgsquoten desselben Benchmarks erklären, warum das kein theoretisches Problem ist: Im 500-Schritte-Budget löst das beste getestete System (Claude Opus 4.8, maximales Thinking, gebatchte Tool-Calls) nur 20,6 Prozent der Aufgaben vollständig, bei 54,8 Prozent Partial Score; GPT-5.5 stagniert bei rund 13 Prozent. Lange Läufe scheitern also regelmäßig – und scheiternde Agenten probieren Dinge aus. Genau dieses Ausprobieren muss innerhalb einer Grenze stattfinden, die hält.

Die drei Isolationsstufen im Vergleich

Stufe 1: Der gehärtete Container

Ein Docker- beziehungsweise runC-Container ist kein virtueller Rechner, sondern ein Prozess mit Namespaces, cgroups, Seccomp-Profil und Capability-Beschränkungen. Die Trennung ist real, aber sie endet an einer Stelle: Der Kernel ist derselbe wie auf dem Host. Jede Kernel-Schwachstelle, die aus dem Container heraus erreichbar ist, ist ein potenzieller Vollzugriff auf den Knoten – und in einem Mehrbenutzer-Cluster damit auf alle anderen Sandboxes auf derselben Maschine.

Für vertrauenswürdigen Code – Ihre eigene Build-Pipeline, Ihre eigenen Tests – ist das völlig ausreichend und der Standardweg. Für Code, den ein Sprachmodell soeben erfunden hat oder den ein externer Nutzer über einen Prompt steuert, ist es die schwächste der drei Optionen.

Stufe 2: gVisor – Syscall-Interception im Userspace

gVisor schiebt einen im Userspace laufenden Kernel (Sentry) zwischen Anwendung und Host. Systemaufrufe der Sandbox landen nicht direkt beim Host-Kernel, sondern werden von gVisor abgefangen und großteils selbst implementiert. Die dem Host exponierte Syscall-Fläche schrumpft dadurch drastisch, ohne dass eine vollständige VM nötig wäre.

Wichtig für die Bewertung von Benchmarks: gVisor hat die Plattform gewechselt. Die alte ptrace-Plattform, auf der viele der kursierenden Overhead-Zahlen basieren, wurde durch Systrap abgelöst, das mit Signal-Handlern und Shared Memory statt mit ptrace-Stops arbeitet. Messwerte aus der ptrace-Ära überzeichnen den heutigen Overhead teils erheblich.

Stufe 3: MicroVM – eigener Kernel je Lauf

Firecracker startet für jede Sandbox eine eigene, sehr schlanke virtuelle Maschine mit eigenem Gast-Kernel hinter der KVM-Grenze. Der Virtual Machine Monitor implementiert bewusst nur ein Minimalgerätemodell – kein BIOS, keine PCI-Emulation, keine grafische Konsole. Das ist der Grund, warum eine MicroVM nicht die Startzeiten einer klassischen VM hat.

Für Betreiber, die ohnehin Kubernetes fahren, ist Kata Containers oft der praktikablere Weg zum gleichen Schutzniveau: rund 200 ms Bootzeit bei geringem Speicherverbrauch, dieselbe hardwaregestützte Isolationsgrenze, aber Ansteuerung über die Standard-Container-APIs und die CRI-Schnittstelle. Man bekommt VM-Isolation, ohne den Scheduler zu ersetzen.

Messwerte: Startzeit, Speicher-Overhead, I/O-Kosten

Die Auswahl entscheidet sich an drei Zahlenreihen: Wie lange dauert der Kaltstart, was kostet die Isolation im Speicher, und wie stark bremst sie den konkreten Workload.

Runtime	Isolationsgrenze	Startzeit	SQLite-Insert vs. runC	K8s-Integration
runC / Docker	Namespaces, cgroups, Seccomp – geteilter Host-Kernel	Zehner-Millisekunden	Baseline (0 %)	nativ
gVisor (Systrap)	Userspace-Kernel, stark reduzierte Syscall-Fläche	nahe Container	+125 % Laufzeit	RuntimeClass
Kata Containers	eigener Gast-Kernel, Hardware-Virtualisierung	~200 ms	+17 % Laufzeit	CRI / RuntimeClass
Firecracker	eigener Gast-Kernel, KVM, Minimalgerätemodell	≤ 125 ms bis /sbin/init	VM-Klasse (≈ Kata)	eigener Orchestrator

Was die Firecracker-Zahlen wirklich sagen

Die vielzitierten 125 ms sind keine Durchschnittsmessung und auch nicht der Zeitpunkt „Gast einsatzbereit". Die offizielle SPECIFICATION.md nennt sie als Obergrenze vom Empfang des InstanceStart-API-Calls bis zum Start des Gast-Userspace-Prozesses /sbin/init – und zwar für eine Referenzkonfiguration mit 1 vCPU, 128 MiB RAM, Firecracker-getuntem Kernel, deaktivierter serieller Konsole und minimalem Root-Dateisystem. Dieselbe Spezifikation nennt ≤ 5 MiB Speicher-Overhead für die VMM-Threads (MMDS-Datastore ausgenommen, workload- und konfigurationsabhängig) sowie bis zu 150 microVM-Erzeugungen pro Sekunde und Host.

Wer diese Zahlen ohne die Konfigurationsangabe in ein Konzeptpapier schreibt, bekommt sie im Review um die Ohren gehauen. Mit der Angabe sind sie belastbar – und sie reichen völlig aus, um die eigentliche Aussage zu tragen: Kernel-Isolation pro Agentenlauf ist wirtschaftlich machbar, nicht nur pro Mandant oder pro Session.

gVisor: der Overhead skaliert mit der Syscall-Frequenz

Die in Anbieter-Leitfäden übliche Angabe „10 bis 30 Prozent auf I/O-lastigen Workloads bei minimalem Overhead auf CPU-lastigen Aufgaben" ist eine Untergrenze für freundliche Lasten. Unabhängige Runtime-Benchmarks zeichnen ein deutlich raueres Bild: Ein SQLite-Insert-Benchmark läuft unter gVisor rund 125 Prozent länger als unter runC beziehungsweise Bare Metal – Kata kostet in derselben Messung nur 17 Prozent. Ein Redis-Benchmark verliert auf der KVM-Plattform rund 56 Prozent Leistung, auf der alten ptrace-Plattform rund 95 Prozent; auch TCP-Durchsatz und Request/Response-Raten fallen spürbar ab.

Umgekehrt gilt: Rechenlastige Schleifen laufen unter gVisor-KVM praktisch auf Bare-Metal-Niveau, unter der alten ptrace-Plattform mit rund 13 Prozent CPU-Overhead. Die Faustregel für die Auslegung lautet deshalb nicht „gVisor kostet X Prozent", sondern: Der Overhead skaliert mit der Syscall-Frequenz, nicht mit der Rechenlast. Ein Agent, der numerische Auswertungen rechnet, merkt gVisor kaum. Ein Agent, der eine Datenbank befüllt, Dateien in Schleife schreibt oder viele kleine Netzwerkpakete verschickt, merkt es sofort.

Defense in Depth: fünf Schichten statt einer VM

Eine MicroVM ist eine gute Grenze – aber sie ist nur eine. Der 2026er Sandboxing-Leitfaden von Northflank gliedert die Absicherung in fünf Schichten, und diese Gliederung hat sich in der Praxis als brauchbare Checkliste erwiesen. Sie ist eine Empfehlung eines Anbieters, kein Normwerk und kein BSI-Dokument – als Struktur für ein eigenes Konzept taugt sie trotzdem:

1. Isolationsgrenze: hardware- oder syscall-erzwungen. MicroVM für nicht vertrauenswürdigen Code, gVisor als Kompromiss, Container nur für vertrauenswürdige Last.
2. Ressourcenlimits: CPU-Throttling, Memory-Caps, Disk-Quotas, Bandbreitenbegrenzung. Ohne sie ist jede Endlosschleife eines Agenten ein Denial of Service gegen den eigenen Cluster.
3. Netzwerkkontrollen: Egress-Filter, DNS-Restriktionen, Segmentierung. Diese Schicht hat die höchste Wirkung pro investierter Stunde.
4. Rechte-Scoping: Least Privilege und kurzlebige Credentials. Ein Token, das nach dem Lauf noch gültig ist, ist eine Zeitbombe.
5. Monitoring: Ausführungs-Tracking, Anomalieerkennung, Logging aller Zugriffsversuche – auch der abgewiesenen.

Der Standard für Schicht 3 lautet: kein Egress. Nicht „gefilterter Egress", sondern gar keiner, bis jemand ein konkretes Ziel begründet und über ein Gateway freigibt. Ein Agent, der keinen Weg nach draußen hat, kann keine Daten exfiltrieren – unabhängig davon, wie überzeugend die Prompt-Injection war, die ihn dazu gebracht hat, es zu versuchen.

Ein Detail, das bei der Umsetzung gerne unterschätzt wird: In Kubernetes-Messungen klafft zwischen Pod- und Host-Netzwerk bei klassischem iptables-Routing bis zu 40 Prozent Leistungsunterschied, während eBPF-basiertes Routing die Lücke praktisch schließt. Wenn Sie Egress-Filterung vor die Sandbox-Pools setzen, ist die Wahl der CNI-Datenebene also keine Geschmacksfrage, sondern ein messbarer Kapazitätsfaktor.

Aufbau eines Sandbox-Pools neben den Inferenz-Knoten

Die häufigste Fehlentscheidung beim On-Premise-Aufbau ist, Ausführung und Inferenz auf dieselben Knoten zu legen. Das ist verlockend – die GPU-Server sind schließlich da –, aber es hebelt die Isolation aus: Ein Ausbruch aus einer Sandbox säße dann auf einem Knoten, der Modellgewichte, KV-Caches und häufig auch die internen Service-Credentials hält.

Eine tragfähige Topologie

• GPU-Knoten (Inferenz): halten Modelle und Vektorindizes. Erreichbar nur über eine interne API. Keine Ausführung von Nutzer- oder Modellcode.
• CPU-Knoten (Sandbox-Pool): ausschließlich Kata- oder Firecracker-Sandboxes. Kein Internet-Egress, keine Default-Route nach draußen. Erreichen die Inferenz-API nicht direkt.
• Orchestrator / Broker: die einzige Komponente, die beide Seiten sieht. Nimmt Tool-Calls des Agenten entgegen, startet Sandboxes, reicht Ergebnisse zurück, protokolliert alles.
• Egress-Gateway: falls überhaupt Außenzugriff nötig ist – eine explizite Allowlist auf Domain- und Portebene, mit vollständigem Logging.
• Artefakt-Store: definierter Ablageort für Ergebnisse. Die Sandbox schreibt dorthin und nirgendwo sonst.

Die Dateisysteme der Sandboxes sind ephemer: Root-Overlay im tmpfs oder als Copy-on-Write-Layer, der nach dem Lauf verworfen wird. Kein persistenter State bedeutet auch: keine Persistenz für einen Angreifer. Ein Agent, der sich in Lauf 41 eine Hintertür installiert hat, findet sie in Lauf 42 nicht wieder.

Die Übergabe von Artefakten läuft ausschließlich über definierte Kanäle – einen Ausgabepfad, einen Objektspeicher-Bucket, eine Message-Queue. Keine gemounteten Netzlaufwerke, keine geteilten Volumes zwischen Sandboxes, keine Schreibrechte auf das Verzeichnis eines anderen Laufs. Für Umgebungen mit besonders hohem Schutzbedarf lässt sich der Pool zusätzlich als air-gapped Segment ausführen, das nur über eine kontrollierte Datenschleuse befüllt wird.

Betriebspraxis: Lebenszyklus, Limits und Forensik

Harte Limits pro Lauf

Jeder Sandbox-Lauf bekommt zwei unabhängige Obergrenzen: eine Wall-Clock-Grenze (typisch 5 bis 15 Minuten, je nach Aufgabenklasse) und eine CPU-Zeit-Grenze. Beide sind nötig, weil sie verschiedene Fehlerbilder abfangen – die Wall-Clock erwischt den Agenten, der auf einen nie eintreffenden Netzwerk-Response wartet, die CPU-Grenze den, der in einer Rechenschleife feststeckt. Dazu kommen Memory-Cap, Disk-Quota und, wo Egress erlaubt ist, ein Bandbreitenlimit.

Ein Nebeneffekt der Firecracker-Kennzahlen: Bei bis zu 150 microVM-Erzeugungen pro Sekunde und Host ist es günstiger, aggressiv zu terminieren und neu zu starten, als einen hängenden Lauf am Leben zu halten. Kurzlebigkeit ist hier kein Kompromiss, sondern die Betriebsstrategie.

Logs gehören nach draußen

Die vollständige Trajektorie eines Laufs – jeder Tool-Call mit Argumenten, jedes Ergebnis, jeder Exit-Code, jeder abgewiesene Netzwerkversuch – wird außerhalb der Sandbox geschrieben, in einen Append-only-Speicher, auf den der Agent selbst keinen Zugriff hat. Bei 318 Tool-Calls im Mittel pro Aufgabe ist das kein Nice-to-have: Ohne diese Aufzeichnung lässt sich nach einem Vorfall schlicht nicht rekonstruieren, welcher der Hunderte Schritte der problematische war.

Planen Sie die Retention realistisch. Eine Trajektorie mit dreistelliger Tool-Call-Zahl und vollständigen Argumenten erzeugt je nach Aufgabe einige Megabyte. Bei tausend Läufen pro Tag ist das ein Speicherposten, der ins Konzept gehört – aber es ist der Posten, der im Ernstfall die forensische Frage beantwortet.

Vernichtung ist der Default

Nach dem Lauf wird die MicroVM zerstört, das Overlay verworfen, das ausgestellte Credential invalidiert. Die einzige Ausnahme: Bei einem erkannten Sicherheitsereignis wird stattdessen ein Snapshot des Speicher- und Dateisystemzustands gezogen und in einen isolierten Forensik-Bereich gelegt – vor der Zerstörung. Diese Verzweigung sollte automatisiert sein, denn manuell kommt sie immer zu spät.

Ergänzend gehört Red Teaming in den Betriebsrhythmus: Ein Team, das regelmäßig versucht, aus der eigenen Sandbox auszubrechen, findet die Lücken vor dem Vorfall. Wie sich das organisatorisch verankern lässt, beschreibt unser Angebot zur Agent-Governance.

Managed-Sandboxes: warum Region und Rechtslage das Ausschlusskriterium sind

Der Markt für Agenten-Sandboxes ist 2026 gut besetzt, und die Praxis ist alles andere als einheitlich: E2B und Vercel Sandbox setzen auf Firecracker, Modal betreibt produktiv gVisor mit eigenem Syscall-Filtering, Daytona nutzt Sysbox, Cloudflare containerbasierte Isolation, Northflank lässt pro Workload zwischen Kata, Firecracker, Cloud Hypervisor und gVisor wählen. Wer behauptet, es gäbe einen technischen Konsens, hat nicht hingesehen.

Das Argument gegen Managed-Angebote für deutsche Unternehmen ist deshalb kein technisches, sondern ein rechtliches und geografisches. Vercel Sandbox etwa läuft derzeit in einer einzigen Region – iad1 an der US-Ostküste. Für einen Agenten, der Konstruktionsdaten, Vertragstexte oder Personaldaten verarbeitet, bedeutet das: Der Code und die Daten, auf denen er arbeitet, verlassen den europäischen Rechtsraum. Damit sind Auftragsverarbeitung, Drittlandtransfer und die Reichweite des US CLOUD Act auf dem Tisch – Fragen, die sich nicht durch ein besseres Seccomp-Profil lösen lassen.

Fairerweise: Mehrere Anbieter bieten Self-Hosted- oder BYOC-Varianten an, bei denen die Ausführung in Ihrer eigenen Infrastruktur stattfindet. Das ist ein gangbarer Mittelweg – aber es ist dann eben kein Managed-Betrieb mehr, sondern ein eingekaufter Sandbox-Layer auf eigenem Blech. Die Betriebsverantwortung für Netzgrenze, Logging und Lebenszyklus bleibt bei Ihnen.

Für die meisten mittelständischen Szenarien läuft es auf eine überschaubare Konfiguration hinaus: zwei bis vier CPU-Knoten mit Kata Containers unter Kubernetes, ohne Egress, neben den bestehenden GPU-Servern. Das ist kein Hyperscaler-Projekt, sondern eine Rack-Erweiterung. Wie sich das konkret in Ihre Umgebung fügt, klären wir im Rahmen unserer Leistung KI-Agenten sicher betreiben.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. Firecracker SPECIFICATION.md ≤ 125 ms bis /sbin/init, ≤ 5 MiB VMM-Overhead, bis 150 microVMs/s pro Host
2. firecracker-microvm.github.io Projektseite, Minimalgerätemodell und Einsatzprofil
3. Northflank – How to sandbox AI agents Fünf-Schichten-Modell, Anbieterübersicht, gVisor-Overhead-Angabe 10–30 %
4. arXiv 2606.29537 – OSWorld 2.0 108 Workflows, 318 Tool-Calls im Mittel, 500-Schritte-Budget
5. OSWorld 2.0 Leaderboard Erfolgsquoten: 20,6 % vollständig, 54,8 % Partial Score
6. KubeBlocks – Container-Runtime-Benchmarks runC vs. Kata vs. gVisor: SQLite-Insert +17 % / +125 %, Redis-Durchsatz
7. gVisor – Systrap-Plattform Ablösung der ptrace-Plattform, Einordnung älterer Benchmarks
8. Modal – MicroVM-Sandboxes für KI-Code Marktübersicht, Kata-Bootzeit, produktiver gVisor-Einsatz
9. Northflank – What is gVisor Architektur des Userspace-Kernels, Syscall-Interception

Häufig gestellte Fragen zum Agenten-Sandboxing

Reicht ein gehärteter Docker-Container für Agenten-Code?

Nur für Code, dem Sie vertrauen. Für KI-generierten oder nutzergesteuerten Code gilt MicroVM oder gVisor als Baseline, weil Container den Host-Kernel teilen.

Wie viel Overhead kostet gVisor?

10 bis 30 Prozent auf I/O-lastigen Workloads, aber nur minimalen Overhead auf rechenlastigen Aufgaben – deshalb gilt es als pragmatischer Mittelweg. Zu beachten: Diese Spanne stammt aus Anbieter-Leitfäden. Unabhängige Benchmarks messen bei stark syscall-intensiven Lasten deutlich mehr, etwa +125 Prozent Laufzeit in einem SQLite-Insert-Benchmark.

Sind MicroVMs nicht zu langsam für interaktive Agenten?

Nein. Firecracker-MicroVMs booten in rund 125 ms bei unter 5 MiB Speicher-Overhead pro VM – damit ist Kernel-Isolation pro Agentenlauf praktikabel. Die Werte sind laut Spezifikation Obergrenzen für eine Referenzkonfiguration mit 1 vCPU und 128 MiB RAM.

Muss die Sandbox ins Internet dürfen?

Als Default nein. Kein Egress ist die wirksamste Einzelmaßnahme; benötigte Ziele werden explizit über ein Gateway freigegeben.