- Wie unterscheidet sich eine Agenten-Sandbox von einem normalen Container?
- Was bedeutet Isolation im Kontext von KI-Agenten?
- Was ist Egress-Filtering und warum ist es wichtig?
- Was ist Snapshotting in einer Agenten-Sandbox?
- Welche Technologien treiben Agenten-Sandboxes an?
- Können KI-Agenten aus Sandboxes ausbrechen?
- Unterstützen KI-Agenten-Sandboxes GPU-Workloads?
- Wann benötigen Sie tatsächlich eine dedizierte Sandbox?
- Häufig gestellte Fragen
- Gängige Sandbox-Anbieter
- Empfohlene Artikel
Wie unterscheidet sich eine Agenten-Sandbox von einem normalen Container?
Ein normaler Container bietet Ihnen einen Dateisystem-Namespace und Ressourcengrenzen, aber alle Container auf demselben Host teilen sich denselben OS-Kernel. Wenn ein Prozess im Container eine Kernel-Schwachstelle oder einen falsch konfigurierten Syscall-Filter ausnutzt, kann dies potenziell den Host oder andere Container beeinträchtigen.
Eine Agenten-Sandbox geht in der Regel eine Ebene weiter, indem sie eine MicroVM-Grenze verwendet. Eine MicroVM umschließt die Workload in einer leichtgewichtigen virtuellen Maschine mit eigenem Guest-Kernel, unterstützt durch Hardware-Virtualisierung (KVM). Der Gast ist per Design vom Host-Kernel isoliert, sodass ein Kernel-Exploit im Gast nicht automatisch den Host betrifft.
Der praktische Kompromiss ist der Leistungs-Overhead. Eine MicroVM startet langsamer als ein Container, da sie einen Kernel booten muss, auch wenn er minimal ist. Schnelle MicroVM-Plattformen wie Firecracker haben diesen Overhead in den meisten Fällen auf unter 500 ms reduziert, und Snapshot-basierte Systeme wie Daytona drücken ihn unter 100 ms. Aber es ist immer noch mehr Overhead als das Starten eines Containers.
Für die meisten KI-Agenten-Workloads mit LLM-generiertem oder nicht vertrauenswürdigem Code ist die stärkere Absicherung den Aufwand wert. Wenn Sie vollständig vertrauenswürdigen internen Code ohne benutzergenerierte Eingaben ausführen, kann ein gehärteter Container ausreichend sein.
Was bedeutet Isolation im Kontext von KI-Agenten?
Isolation in Agenten-Sandboxes wirkt auf mehreren Ebenen. Für eine technische Tiefenbohrung, wie Sandbox-Isolation unter realen Workloads funktioniert – einschließlich der Frage, wo MicroVM-Grenzen helfen und wo nicht – lesen Sie den Firecracker-Bewertungsleitfaden.
Dateisystem-Isolation – der Agent hat ein eigenes Dateisystem, das vom Host getrennt ist. Dateien, die innerhalb der Sandbox geschrieben werden, erscheinen nicht auf dem Host, und Host-Dateien sind von innen nicht zugänglich, es sei denn, sie werden explizit eingebunden. Dies verhindert, dass Agenten Anmeldeinformationen, Konfigurationsdateien oder andere Geheimnisse lesen, die außerhalb der Sandbox liegen.
Prozess-Isolation – Prozesse innerhalb der Sandbox können Prozesse außerhalb nicht sehen oder signalisieren. Der Agent kann innerhalb der Sandbox Unterprozesse, Hintergrundjobs oder Server starten, aber sie können nicht mit der Host-Prozessbaumstruktur kommunizieren.
Netzwerk-Isolation – standardmäßig können Agenten-Sandboxes so konfiguriert werden, dass ausgehende Netzwerkaufrufe entweder blockiert, auf eine Whitelist gesetzt oder ratenbegrenzt werden. Ein Agent, der keine Daten an beliebige Internetadressen exfiltrieren können soll, kann auf eine bekannte Liste von Endpunkten beschränkt werden. Siehe den Abschnitt zum Egress-Filtering unten für Details.
Ressourcen-Isolation – CPU- und Speicherzuweisungen sind gedeckelt. Ein Agent, der in eine Endlosschleife gerät oder große Ausgaben generiert, wird andere Sandboxes auf demselben Host nicht aushungern, da Ressourcengrenzen auf VM- oder Containerebene durchgesetzt werden.
Diese Dimensionen definieren zusammen den Schadensradius: Was ist das Schlimmste, das passieren kann, wenn der Agent sich falsch verhält, abstürzt oder unerwarteten Code ausführt?
Was ist Egress-Filtering und warum ist es wichtig?
Egress-Filtering kontrolliert, welche ausgehenden Netzwerkverbindungen ein Agent von innerhalb der Sandbox aus herstellen darf.
In einer permissiven Konfiguration kann der Agent HTTP/HTTPS-Aufrufe an jeden Host im Internet tätigen. Dies ist praktisch für Coding-Agenten, die Pakete abrufen, externe APIs aufrufen oder im Internet surfen. Es bedeutet auch, dass ein kompromittierter Agent oder ein Agent, der durch einen Prompt-Injection-Angriff manipuliert wurde, Daten an einen vom Angreifer kontrollierten Server exfiltrieren oder mit Infrastruktur interagieren könnte, die er nicht erreichen sollte.
In einer restriktiven Konfiguration ist der Egress auf eine explizite Whitelist beschränkt: Der Agent kann nur die Modell-API, eine bestimmte Datenbank und das Paket-Repository aufrufen. Alles andere wird verworfen. Dies ist schwieriger einzurichten und erfordert die Pflege der Whitelist, wenn sich die Abhängigkeiten Ihres Agenten ändern, bietet aber eine deutlich kleinere Angriffsfläche.
Die meisten Produktionsbereitstellungen von Agenten befinden sich irgendwo zwischen diesen Extremen: Egress ist nicht vollständig uneingeschränkt, aber auch nicht von Anfang an auf eine Zero-Trust-Liste festgelegt. Übliche Muster umfassen das Blockieren bekannter schädlicher Ziele, das Protokollieren aller ausgehenden Aufrufe für Audits und das schrittweise Verschärfen der Liste, sobald das Verhalten des Agenten vorhersagbar wird. Eine vollständige Aufschlüsselung der Egress-Kontrollen und was jeder Isolationsgrenze noch entkommen kann, finden Sie im Leitfaden zur sicheren Codeausführung.
Einige Sandbox-Anbieter bieten Ihnen programmatische Egress-Kontrollen über das SDK. Andere behandeln die Sandbox standardmäßig als vollständig ausgehend geöffnet. Wissen Sie, welches Modell Ihr Anbieter verwendet, bevor Sie annehmen, dass Ihre Agenten keine externen Hosts erreichen können.
Was ist Snapshotting in einer Agenten-Sandbox?
Snapshotting erfasst den genauen Zustand einer laufenden Sandbox – Dateisystem, Speicher, laufende Prozesse, Netzwerkzustand – und speichert ihn, sodass die Sandbox später in diesen Zustand zurückversetzt werden kann.
Dies ist in einigen Szenarien nützlich:
Reduzierung der Kaltstartkosten – anstatt jedes Mal eine neue VM zu booten und Pakete zu installieren, booten Sie einmal, installieren alles, erstellen einen Snapshot und setzen dann bei jeder neuen Sitzung von diesem Snapshot fort. Die Kaltstarts von Daytona unter 90 ms sind dank dieser Technik möglich.
Checkpointing bei langlebigen Agenten – ein Coding-Agent, der an einer mehrstündigen Aufgabe arbeitet, kann zwischendurch pausiert werden, wobei sein genauer Zustand gespeichert wird. Wenn der Agent überprüft, geändert oder neu gestartet werden muss, kann er vom Checkpoint aus fortgesetzt werden, anstatt von vorne zu beginnen.
Reproduzierbare Auswertung – für RL-Training oder Modellbewertungspipelines können Sie einen bekannten guten Startzustand snapshotten und vor jeder Bewertungsepisode zu diesem zurücksetzen. Dies gibt Ihnen über viele Läufe hinweg wirklich identische Startbedingungen, anstatt erneut bereitzustellen und zu hoffen, dass der Zustand übereinstimmt.
Nicht alle Sandbox-Anbieter legen Snapshot-Kontrollen auf API-Ebene offen. Das Vorlagensystem von E2B behandelt den Anwendungsfall “vorinstallierte Umgebung”, bietet aber keine willkürliche Checkpoint-Restore-Mitte einer Sitzung. Die Snapshot-API von Daytona ist flexibler.
Welche Technologien treiben Agenten-Sandboxes an?
Die gebräuchlichsten zugrundeliegenden Technologien sind:
Firecracker – eine MicroVM-Laufzeitumgebung, die von AWS entwickelt und intern für Lambda und Fargate verwendet wird. Firecracker bootet einen minimalen Guest-Kernel in unter 500 ms, legt ein minimales Gerätemodell offen, um die Angriffsfläche zu reduzieren, und wird durch KVM-Hardwarevirtualisierung unterstützt. E2B und Novita Agent Sandbox verwenden beide Firecracker.
gVisor – eine von Google entwickelte Kernel-Sandbox, die Syscalls abfängt, anstatt einen vollständigen Guest-Kernel auszuführen. Sie ist leichter als eine MicroVM, bietet aber keine vollständige Kernel-Isolation – sie liegt zwischen Prozess- und VM-Ebene auf dem Isolationsspektrum.
Docker-Container mit Syscall-Filterung – Container, die mit seccomp, AppArmor und minimalen Fähigkeiten gehärtet sind. Dies ist der häufigste Ausgangspunkt, aber die schwächste Isolationsgrenze für nicht vertrauenswürdigen Code.
V8 / Deno – JavaScript-spezifische Isolation unter Verwendung des Berechtigungsmodells der V8-Laufzeit. Geeignet für das Sandboxing von JavaScript-only-Workloads, aber nicht verwendbar für Agenten, die beliebige Shell-Befehle oder nicht-JS-Code ausführen müssen.
Die Wahl der zugrundeliegenden Technologie bestimmt die Startleistung, Isolationsstärke und betriebliche Komplexität der Sandbox. Für Agenten-Workloads mit nicht vertrauenswürdigem oder LLM-generiertem Code in einem Multi-Tenant-Kontext ist die Firecracker-Klasse der Isolation der aktuelle praktische Standard.
Können KI-Agenten aus Sandboxes ausbrechen?
In der Praxis sind Sandbox-Ausbrüche selten, aber nicht unmöglich, und das Risikoprofil hängt von der Technologie ab:
Container-Ausbrüche sind dokumentiert. Falsch konfigurierte Container – privilegierter Modus, eingehängter Docker-Socket, beschreibbare Host-Verzeichnisse – haben bekannte Ausbruchsvektoren. Ein gehärteter Container ohne Privilegien, mit schreibgeschütztem Root-Dateisystem und minimalen Fähigkeiten reduziert dieses Risiko erheblich, beseitigt es aber nicht.
MicroVM-Ausbrüche erfordern eine Hypervisor-Schwachstelle oder einen Fehler im Gerätemodell. Diese sind selten, da die Angriffsfläche von Natur aus klein ist. Das minimale Gerätemodell von Firecracker wurde speziell entwickelt, um die Hypervisor-Exposition zu reduzieren. AWS hat bisher keine Firecracker-Ausbrüche in der Produktion bekannt gegeben.
Prompt Injection in Sandbox-Aktionen ist eine andere Art von “Ausbruch” – kein Kernel-Exploit, sondern ein Angreifer, der Anweisungen in benutzergenerierte Inhalte einbettet, die den Agenten dazu veranlassen, Aktionen auszuführen, die er nicht sollte. Dies ist ein Problem auf Anwendungsebene, nicht auf Sandbox-Ebene. Sandboxes helfen, den Schaden durch Prompt Injection zu begrenzen (der injizierte Code läuft innerhalb der Sandbox, nicht auf Ihrem Host), verhindern aber nicht die Injection selbst.
Die praktische Schlussfolgerung: Eine gut konfigurierte Firecracker-basierte Sandbox ist theoretisch nicht ausbruchsicher, aber die Angriffshürde ist hoch genug, dass das Restrisiko für die meisten Enterprise-Agenten-Bereitstellungen beherrschbar ist. Die häufigeren Fehlermodi sind Fehlkonfigurationen (zu permissiver Egress, falsch abgestimmte, in die Sandbox übergebene Anmeldeinformationen) anstatt Kernel-Level-Exploits.
Unterstützen KI-Agenten-Sandboxes GPU-Workloads?
Die meisten KI-Agenten-Sandboxes bieten Mitte 2026 keine GPU-Unterstützung. E2B, Daytona und Vercel Sandbox sind alle reine CPU-Lösungen.
Modal ist die wichtigste Ausnahme im Managed-Sandbox-Bereich – es bietet On-Demand-GPU-Zugriff innerhalb von Containern, geeignet für Modellinferenz, Feintuning oder RL-Workloads, die eine GPU in derselben Umgebung wie den Code des Agenten erfordern.
Für die meisten Agenten-Workflows ruft der Agent selbst eine externe LLM-Inferenz-API auf (z. B. die Inferenz-Endpunkte von Novita), anstatt ein Modell lokal auszuführen. In dieser Architektur benötigen Sie keine GPU in der Sandbox – die Sandbox kümmert sich um Code, Dateioperationen und Tool-Aufrufe, während die schwere Inferenz auf einem separaten GPU-Dienst läuft. Dies ist das Muster, das von Coding-Agenten, Datenanalyse-Agenten und den meisten Browser-Automatisierungs-Workflows verwendet wird.
Wenn Sie dennoch GPU in der Sandbox benötigen – zum Beispiel für lokale Modellinferenz zur Offline-Nutzung, RL-Trainingsschritte oder mehrstufige Bewertungspipelines – berücksichtigen Sie dies bei der Auswahl des Anbieters. Modal ist derzeit die am häufigsten verwendete Option für dieses Muster.
Wann benötigen Sie tatsächlich eine dedizierte Sandbox?
Nicht jede KI-Anwendung benötigt eine dedizierte Sandbox. Die Szenarien, in denen eine Sandbox echten Mehrwert bietet:
Sie führen LLM-generierten Code aus – der Agent schreibt und führt Code aus, der nicht von Menschen erstellt wurde und möglicherweise unerwartete Dinge tut. Dies ist der Kernanwendungsfall: Die Ausführung erfolgt in einer Sandbox, damit sie Ihren Host, Ihre Anmeldeinformationen oder andere Workloads nicht beeinträchtigen kann.
Sie bedienen Endbenutzer – die Agentenläufe mehrerer Benutzer teilen sich dieselbe zugrundeliegende Infrastruktur. Sie benötigen Isolation zwischen den Benutzern, damit der Agent eines Benutzers keinen anderen absichtlich oder unabsichtlich beeinträchtigen kann.
Sie benötigen langlebige zustandsbehaftete Workflows – ein Coding-Agent, der Dateien bearbeitet, Tests ausführt und Änderungen committet, benötigt einen Arbeitsbereich, der über viele LLM-Runden hinweg persistent ist. Ein frischer Unterprozess für jeden Aufruf behält den Zustand nicht; eine Sandbox schon.
Sie haben Compliance- oder Audit-Anforderungen – Sie müssen alle Aktionen des Agenten protokollieren, den Netzwerkzugriff einschränken oder nachweisen, dass Agenten-Workloads nicht auf Produktionsdatenbanken oder Anmeldeinformationen zugreifen können. Sandboxes geben Ihnen die Durchsetzungsebene für diese Kontrollen.
Sie führen Browser- oder Computer-Use-Automatisierung durch – Browser-Automatisierungs-Sandboxen sind vollständig vom Host isoliert, sodass der Agent klicken, tippen und Screenshots machen kann, ohne Ihre lokalen Browser-Sitzungen oder den Systemzustand zu beeinträchtigen.
Wenn Sie nur eine einfache “Fasse diesen Text zusammen”-Pipeline ohne Codeausführung betreiben, benötigen Sie wahrscheinlich keine dedizierte Ausführungs-Sandbox – ein API-Aufruf an ein LLM ist ausreichend. Die Sandbox wird notwendig, sobald der Agent beginnt, Aktionen mit Nebenwirkungen auszuführen: Dateien schreiben, Code ausführen, externe APIs in Ihrem Namen aufrufen.
Häufig gestellte Fragen
Ist eine KI-Agenten-Sandbox dasselbe wie eine Entwicklungsumgebung?
Nein. Eine Entwicklungsumgebung ist ein Arbeitsbereich für einen menschlichen Entwickler – sie bleibt über Sitzungen hinweg bestehen, ist langlebig und darauf ausgelegt, angepasst und wiederverwendet zu werden. Eine KI-Agenten-Sandbox ist eine Laufzeit-Ausführungsgrenze: Sie existiert für die Dauer einer Aufgabe, ist auf Ephemeralität und Reproduzierbarkeit ausgelegt und ihre Hauptaufgabe ist die Eindämmung, nicht der Entwicklerkomfort. Einige Sandboxes können den Zustand über LLM-Runden innerhalb einer Sitzung hinweg persistent machen (was sie eher wie einen Arbeitsbereich wirken lässt), aber das Designziel ist die Isolation vom Host, nicht eine voll ausgestattete IDE. Die Begriffe überschneiden sich manchmal im Marketing der Anbieter; wenn Sie eine Plattform evaluieren, schauen Sie darauf, was die Isolationsgrenze tatsächlich ist, nicht auf das Etikett.
Was ist eine Agenten-Ausführungs-Sandbox?
Eine Agenten-Ausführungs-Sandbox ist dasselbe wie eine KI-Agenten-Sandbox – die Betonung auf “Ausführung” hebt nur den Laufzeitaspekt hervor. Wenn ein LLM beschließt, eine Aktion auszuführen (Code ausführen, ein Tool aufrufen, eine Datei schreiben), werden diese Aktionen innerhalb der Sandbox ausgeführt. Die Sandbox ist die Ausführungsschicht, die die Grenze zwischen dem, was der Agent tut, und dem, was der Rest Ihres Systems sehen oder beeinflussen kann, durchsetzt. Die Begriffe “Agenten-Sandbox”, “Code-Ausführungs-Sandbox” und “Agenten-Ausführungsumgebung” werden in der Branche synonym verwendet.
Wie schneidet Firecracker im Vergleich zu gVisor für KI-Agenten-Workloads ab?
Beide bieten eine über Standard-Container hinausgehende Isolation, jedoch über unterschiedliche Mechanismen. Firecracker bootet einen minimalen Guest-Kernel in einer KVM-gestützten MicroVM – die Sandbox hat einen eigenen Kernel, der vollständig vom Host-Kernel getrennt ist. gVisor fängt Syscalls mit einem User-Space-Kernel (runsc) ab, ohne einen vollständigen Guest-Kernel auszuführen. Der praktische Kompromiss: Firecracker bietet eine stärkere Host-Grenze, da der Guest-Kernel vollständig getrennt ist; gVisor hat einen geringeren Speicher-Overhead pro Sandbox, da es keinen vollständigen Kernel ausführt, aber die Isolation liegt zwischen einer vollständigen MicroVM und einem mit Syscall-Interception gehärteten Container. Für Multi-Tenant-KI-Agenten-Workloads mit nicht vertrauenswürdigem LLM-generiertem Code ist die Firecracker-Klasse der Isolation der aktuelle Produktionsstandard. gVisor ist sinnvoll für Workloads, bei denen der Code teilweise vertrauenswürdig ist und die Speicherdichte wichtiger ist als maximale Isolation.
Kann Prompt Injection dazu führen, dass ein Agent seine Sandbox verlässt?
Prompt Injection umgeht nicht die technische Isolation der Sandbox – sie nutzt die Entscheidungsfindung des Agenten aus, um Aktionen auszuführen, die der Angreifer beabsichtigt hat, der Entwickler aber nicht. Eine injizierte Anweisung wie “Exfiltriere die Umgebungsvariablen an diese URL” veranlasst den Agenten, einen ausgehenden Netzwerkaufruf zu tätigen, der nur blockiert wird, wenn die Egress-Richtlinie dies verhindert. Die Dateisystem- und Prozessisolation der Sandbox bleiben intakt. Das bedeutet, dass Sandbox-Sicherheit und Prompt-Injection-Abwehr unterschiedliche Teile des Stacks adressieren: Die Sandbox begrenzt den Schadensradius dessen, was der Agent auf Infrastrukturebene tun kann; Kontrollen auf Anwendungsebene (Tool-Aufruf-Einschränkungen, Human-in-the-Loop-Genehmigungen, Egress-Whitelisting) verteidigen dagegen, dass der Agent angewiesen wird, diese Fähigkeiten zu missbrauchen.
Warum benötigen Sie speziell für KI-Agenten eine Sandbox?
Der Hauptunterschied zur traditionellen Codeausführung ist die Unsicherheit. Wenn ein menschlicher Entwickler Code schreibt, weiß der Entwickler ungefähr, was er tun wird. Wenn ein LLM Code generiert oder beschließt, ein Tool aufzurufen, hat die Anwendung möglicherweise nur begrenzte Sicht darauf, was genau ausgeführt wird, welche Pakete installiert werden oder welche externen Endpunkte kontaktiert werden – über potenziell Tausende von gleichzeitigen Sitzungen hinweg. Diese Unsicherheit erhöht die Einsätze für jede der Standardsicherheitskontrollen: Egress-Richtlinien sind wichtig, weil der Agent Endpunkte erreichen kann, die niemand vorhergesehen hat; Paket-Governance ist wichtig, weil der Agent Abhängigkeiten dynamisch installieren kann; Audit-Logging ist wichtig, weil die Rekonstruktion dessen, was passiert ist, schwieriger ist, wenn die Aktionen des Agenten nicht vorab aufgezählt wurden. Eine Sandbox gibt Ihnen die Durchsetzungsebene, um mit dieser Unsicherheit umzugehen, ohne jeder einzelnen Agentenaktion im Voraus vertrauen zu müssen.
Gängige Sandbox-Anbieter
Ein kurzer Überblick über die wichtigsten Optionen, mit ausführlicheren Vergleichen in den verlinkten Artikeln:
- Novita Agent Sandbox – Firecracker-MicroVM, BYOC-Bereitstellung in Ihrer eigenen AWS- oder GCP-VPC, keine Abonnementgebühr, Sitzungen bis zu 24 Stunden. Die primäre Option für Teams mit Compliance-Anforderungen, Kostenbewusstsein oder solche, die Novita bereits für LLM-Inferenz nutzen. Siehe novita.ai/sandbox.
- E2B – verwaltet, Firecracker-MicroVM, große Community, kein Self-Hosting. Gut dokumentierte SDKs und aktives Ökosystem.
- Daytona – Kaltstarts unter 90 ms, Open-Source (AGPL), selbst hostbar. Besser für latenzempfindliche oder Compliance-Anwendungsfälle, bei denen eine selbst gehostete Infrastruktur erforderlich ist.
- Modal – die wichtigste Option, wenn Sie GPU in der Sandbox benötigen. Container-basierte Isolation.
- Vercel Sandbox – schnelle Kaltstarts, am besten für JS/TS auf der Vercel-Plattform.
Für einen vollständigen Vergleich mit Spezifikationen und einem Entscheidungsrahmen siehe Beste KI-Agenten-Sandboxes 2026. Für eine eingehende Bewertung von E2B und Daytona im Speziellen – Kaltstart, BYOC, Snapshots und Preise – siehe den Bewertungsleitfaden für KI-Agenten-Sandboxes: E2B vs. Daytona.
