Was ist eine KI-Agenten-Sandbox?

Eine KI-Agenten-Sandbox ist die Ausführungsebene, in der ein KI-Agent seine eigentliche Arbeit erledigt: Code schreiben und ausführen, Pakete installieren, Dateien lesen und ändern, API-Aufrufe tätigen und mit Browser-Sitzungen oder Desktop-GUIs interagieren. Die Sandbox bietet eine begrenzte Umgebung mit eigenem Dateisystem, CPU- und Speicherzuweisung, Netzwerkschnittstelle und Prozess-Namespace – und ist von allem außerhalb isoliert.

Das zentrale Designziel ist die Eindämmung. Wenn ein LLM einen Shell-Befehl generiert und ein Agent ihn ausführt, läuft der Befehl innerhalb der Sandbox. Wenn er ein Paket installiert, einen Unterprozess startet oder versucht, Anmeldeinformationen zu lesen, sind diese Operationen auf die Sandbox beschränkt. Wenn der Code den Prozess zum Absturz bringt oder die Festplatte füllt, bleibt der Schaden lokal.

Sandboxes dienen auch als Abrechnungs- und Ressourcen-Controlling-Einheit für Cloud-Anbieter. Wenn Sie ein SDK wie E2B, Daytona oder Novita Agent Sandbox aufrufen, erstellen Sie eine Sandbox-Instanz, führen darin Operationen aus und schließen sie dann – und der Anbieter berechnet basierend auf der verbrauchten Rechenleistung.

Wie unterscheidet sich eine Agent-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-Sicherheitslücke oder einen falsch konfigurierten Syscall-Filter ausnutzt, kann dies potenziell den Host oder andere Container beeinträchtigen.

Eine Agent-Sandbox geht in der Regel eine Ebene weiter, indem sie eine MicroVM-Grenze verwendet. Eine MicroVM verpackt die Workload in eine leichtgewichtige virtuelle Maschine mit eigenem Gast-Kernel, unterstützt durch Hardware-Virtualisierung (KVM). Der Gast ist per Design vom Host-Kernel isoliert, sodass eine Kernel-Ausnutzung im Gast den Host nicht automatisch beeinträchtigt.

Der praktische Kompromiss ist der Leistungs-Overhead. Eine MicroVM startet langsamer als ein Container, da sie einen Kernel booten muss, selbst einen minimalen. Schnelle MicroVM-Plattformen wie Firecracker haben diesen Overhead in den meisten Fällen auf unter 500 ms reduziert, und snapshotbasierte 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 Grenze den Aufwand wert. Wenn Sie vollständig vertrauenswürdigen internen Code ohne benutzergenerierte Eingaben ausführen, kann ein gehärteter Container ausreichend sein.

Was ist Isolierung im Kontext von KI-Agenten?

Isolierung in Agent-Sandboxes wirkt auf mehreren Ebenen. Eine technische Tiefenbohrung zur Sandbox-Isolierung unter realen Workloads, einschließlich wo MicroVM-Grenzen helfen und wo nicht, finden Sie im Firecracker-Bewertungsleitfaden.

Dateisystem-Isolierung – 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-Isolierung – Prozesse innerhalb der Sandbox können keine Prozesse außerhalb sehen oder signalisieren. Der Agent kann Unterprozesse, Hintergrundjobs oder Server innerhalb der Sandbox starten, aber sie können nicht mit der Host-Prozessbaumkommunizieren.

Netzwerk-Isolierung – Standardmäßig können Agent-Sandboxes so konfiguriert werden, dass ausgehende Netzwerkaufrufe entweder blockiert, auf eine Whitelist gesetzt oder ratenbegrenzt sind. Ein Agent, der keine Daten an beliebige Internetadressen exfiltrieren soll, kann auf eine bekannte Liste von Endpunkten beschränkt werden. Siehe den Abschnitt zur Ausgangsfilterung weiter unten für Details.

Ressourcen-Isolierung – CPU- und Speicherzuweisungen sind begrenzt. Ein Agent, der in eine Endlosschleife gerät oder große Ausgaben erzeugt, wird andere Sandboxes auf demselben Host nicht aushungern, da Ressourcengrenzen auf VM- oder Containerebene durchgesetzt werden.

Diese Dimensionen definieren zusammen den Explosionsradius: Was ist das Schlimmste, was passieren kann, wenn der Agent sich falsch verhält, abstürzt oder unerwarteten Code ausführt?

Was ist Ausgangsfilterung und warum ist sie wichtig?

Ausgangsfilterung (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 Codierungsagenten, die Pakete abrufen, externe APIs aufrufen oder im Web 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 Ausgangsverkehr 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, während sich die Abhängigkeiten Ihres Agenten ändern, bietet aber eine viel kleinere Angriffsfläche.

Die meisten Produktionsumgebungen für Agenten bewegen sich irgendwo zwischen diesen Extremen: Der Ausgangsverkehr ist nicht vollständig uneingeschränkt, aber auch nicht von Anfang an auf eine Zero-Trust-Liste beschränkt. Übliche Muster sind das Blockieren bekannter schädlicher Ziele, das Protokollieren aller ausgehenden Aufrufe zur Prüfung und das schrittweise Verschärfen der Liste, sobald das Verhalten des Agenten vorhersagbar wird. Eine vollständige Aufschlüsselung der Ausgangskontrollen und was dennoch aus jeder Isolierungsgrenze entweichen kann, finden Sie im Leitfaden zur sicheren Codeausführung.

Einige Sandbox-Anbieter bieten programmgesteuerte Ausgangskontrollen über das SDK. Andere behandeln die Sandbox als standardmäßig vollständig ausgehend geöffnet. Wissen Sie, welches Modell Ihr Anbieter verwendet, bevor Sie annehmen, dass Ihre Agenten keine externen Hosts erreichen können.

Wie werden Geheimnisse und Anmeldeinformationen in einer Agent-Sandbox abgegrenzt? {#secrets-and-credentials}

Geheimnisse, die in eine Sandbox übergeben werden, sollten nur auf das beschränkt sein, was dieser spezifische Agentenlauf benötigt – und als Umgebungsvariablen oder kurzlebige Token übergeben werden, nicht als langlebige Anmeldeinformationen, die auf die Festplatte geschrieben werden. Die Sandbox-Grenze begrenzt den Explosionsradius, verhindert aber nicht automatisch, dass ein Agent Anmeldeinformationen, auf die er innerhalb der Umgebung zugreifen kann, liest und weiterleitet.

Das Kernprinzip ist die minimale Rechtevergabe: Übergeben Sie die engste Anmeldeinformation, die funktioniert, nicht einen Root-Cloud-Key oder ein Dienstkonto mit breiten Berechtigungen. Übliche Muster:

Umgebungsvariablen beim Start – Injizieren Sie ein Geheimnis zur Startzeit in die Sandbox-Umgebung. Es ist für den Code des Agenten verfügbar, bleibt aber standardmäßig nicht in Dateisystem-Snapshots erhalten oder in Logs sichtbar. Bevorzugen Sie kurzlebige Token gegenüber statischen API-Schlüsseln.

DNS-basierte Blockierung – Einige Bereitstellungskonfigurationen ermöglichen es Ihnen, einzuschränken, welche DNS-Namen von innerhalb der Sandbox aufgelöst werden können. Dies verhindert, dass ein Agent einen Endpunkt zur Exfiltration von Anmeldeinformationen kontaktiert, selbst wenn er Netzwerkzugriff hat, indem die Auflösung auf DNS-Ebene und nicht nach einzelner IP blockiert wird.

Begrenzte Dienstkonten mit kurzer TTL – Für Agenten, die Cloud-APIs aufrufen, verwenden Sie Rollenannahmeketten mit einer kurzen Lebensdauer. Wenn die Anmeldeinformationen durchsickern, ist das Zeitfenster des Angreifers durch die Token-Lebensdauer begrenzt.

Keine Host-Anmeldeinformationsdateien – Vermeiden Sie es, Host-Anmeldeinformationsdateien (wie ~/.aws/credentials) in das Sandbox-Dateisystem einzubinden. Generieren Sie stattdessen pro Sitzung frische, kurzlebige Anmeldeinformationen.

Die Sandbox bietet die Prozessebenen-Grenze; Sie bleiben dafür verantwortlich, was Sie in sie hineingeben.

Wie funktionieren Prüfprotokolle in KI-Agenten-Sandboxes? {#audit-logs}

Prüfprotokolle (Audit Logs) für Agent-Sandboxes decken in der Regel zwei Ebenen ab: plattformbezogene Ereignisse (Sandbox erstellt, gestartet, gestoppt, Zeitüberschreitung) und anwendungsbezogene Ereignisse (ausgeführte Befehle, geänderte Dateien, externe API-Aufrufe). Die meisten verwalteten Anbieter geben plattformbezogene Ereignisse automatisch aus; die anwendungsbezogene Protokollierung liegt in Ihrer Verantwortung.

Was für eine aussagekräftige Prüfprotokoll-Abdeckung erfasst werden sollte:

Sandbox-Lebenszyklus-Ereignisse – Erstellungszeitstempel, Sitzungsdauer, Beendigungsgrund (normales Schließen, Zeitüberschreitung oder Absturz). Die meisten verwalteten Plattformen protokollieren diese automatisch und stellen sie über API oder Dashboard zur Verfügung.

Ausgehende Netzwerkaufrufe – Welche Hosts der Agent kontaktiert hat, mit Zeitstempeln. Hier überschneiden sich Ausgangsprotokollierung und Prüfprotokollierung. Wenn Ihre Plattform Ausgangsprotokollierung unterstützt, aktivieren Sie sie und leiten Sie die Ausgabe an Ihren Log-Aggregator weiter.

Codeausführung Eingabe/Ausgabe – Die Befehle, die ein Agent ausgeführt hat, und die Ergebnisse, die er erhalten hat. Dies ist anwendungsbezogen und muss in Ihrem Agenten-Framework erfasst werden, nicht auf der Sandbox-Infrastrukturebene.

Dateisystem-Änderungen – Geschriebene, gelöschte oder geänderte Dateien. Relevant für Codierungsagenten und Datenverarbeitungspipelines. Einige Sandbox-Plattformen bieten Dateisystem-Diff-APIs am Sitzungsende; andere erfordern eine Instrumentierung in Ihrem Agenten-Code.

Für Compliance-Anwendungsfälle (SOC 2, HIPAA, regulierte Branchen) benötigen Sie in der Regel plattformbezogene Logs in einem manipulationssicheren Speicher, kombiniert mit anwendungsbezogenen Logs aus Ihrem Agenten-Framework. Überprüfen Sie, was Ihr Anbieter tatsächlich ausgibt, im Vergleich zu dem, was eine explizite Aktivierung erfordert, bevor Sie eine Abdeckung annehmen.

Was ist Snapshotting in einer Agent-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 bei jedem 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 aus fort. Daytonas Kaltstarts unter 90 ms sind aufgrund dieser Technik möglich.

Checkpointing für langlebige Agenten – Ein Codierungsagent, 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 Modellauswertungspipelines können Sie einen bekannten guten Startzustand snapshotten und vor jeder Auswertungsepisode auf diesen zurücksetzen. Dies gibt Ihnen über viele Läufe hinweg wirklich identische Startbedingungen, anstatt neu bereitzustellen und zu hoffen, dass der Zustand übereinstimmt.

Nicht alle Sandbox-Anbieter stellen Snapshot-Kontrollen auf API-Ebene zur Verfügung. E2Bs Templatesystem deckt den Anwendungsfall „vorinstallierte Umgebung“ ab, bietet aber keine beliebigen Checkpoint-Wiederherstellungen mitten in der Sitzung. Daytonas Snapshot-API ist flexibler.

Welche Technologien treiben Agent-Sandboxes an?

Die gängigsten zugrunde liegenden Technologien sind:

Firecracker – Eine MicroVM-Laufzeit, die von AWS entwickelt und intern für Lambda und Fargate verwendet wird. Firecracker bootet einen minimalen Gast-Kernel in unter 500 ms, bietet ein minimales Gerätemodell zur Reduzierung der Angriffsfläche und wird durch KVM-Hardware-Virtualisierung unterstützt. E2B und Novita Agent Sandbox verwenden beide Firecracker.

gVisor – Eine von Google entwickelte Kernel-Sandbox, die sich in Syscalls einklinkt, anstatt einen vollständigen Gast-Kernel auszuführen. Es ist leichter als eine MicroVM, bietet aber keine vollständige Kernel-Isolierung – es liegt auf dem Isolierungsspektrum zwischen Prozessebene und VM-Ebene.

Docker-Container mit Syscall-Filterung – Container, die mit seccomp, AppArmor und minimalen Capabilities gehärtet sind. Dies ist der häufigste Ausgangspunkt, aber die schwächste Isolierungsgrenze für nicht vertrauenswürdigen Code.

V8 / Deno – JavaScript-spezifische Isolierung unter Verwendung des Berechtigungsmodells von V8. Geeignet für die 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 zugrunde liegenden Technologie bestimmt die Startleistung, Isolierungsstärke und Betriebskomplexität der Sandbox. Für Agenten-Workloads, die nicht vertrauenswürdigen oder LLM-generierten Code in einem Multi-Tenant-Kontext ausführen, ist Firecracker-ähnliche Isolierung 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, schreibgeschütztem Root-Dateisystem und minimalen Capabilities reduziert dieses Risiko erheblich, beseitigt es jedoch nicht.

MicroVM-Ausbrüche erfordern eine Hypervisor-Sicherheitslücke oder einen Fehler im Gerätemodell. Diese sind selten, da die Angriffsfläche per Design klein ist. Firecrackers minimales Gerätemodell wurde speziell entwickelt, um die Hypervisor-Exposition zu reduzieren. AWS hat keine Firecracker-Ausbrüche in der Produktion offengelegt.

Prompt Injection in Sandbox-Aktionen ist eine andere Art von „Ausbruch“ – keine Kernel-Ausnutzung, sondern ein Angreifer, der Anweisungen in benutzergenerierte Inhalte einbettet, die den Agenten dazu veranlassen, Aktionen auszuführen, die er nicht sollte. Dies ist ein Anwendungsproblem, kein Sandbox-Problem. Sandboxes helfen, den Schaden durch Prompt Injection einzudämmen (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 ausbruchssicher, aber die Angriffshürde ist hoch genug, dass für die meisten Unternehmens-Agenten-Bereitstellungen das Restrisiko beherrschbar ist. Die häufigeren Fehlermodi sind Fehlkonfiguration (zu permissiver Ausgangsverkehr, falsch abgegrenzte Anmeldeinformationen, die in die Sandbox übergeben werden) und nicht Kernel-Level-Ausnutzungen.

Unterstützen KI-Agenten-Sandboxes GPU-Workloads?

Die meisten KI-Agenten-Sandboxes unterstützen Mitte 2026 keine GPUs. E2B, Daytona und Vercel Sandbox sind alle reine CPU-Lösungen.

Modal ist die Hauptausnahme im Bereich der verwalteten Sandboxes – es bietet On-Demand-GPU-Zugriff innerhalb von Containern, geeignet für Modellinferenz, Fine-Tuning 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 (wie die Inferenz-Endpunkte von Novita) auf, 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 Codierungsagenten, Datenanalyseagenten und den meisten Browser-Automatisierungs-Workflows verwendet wird.

Wenn Sie jedoch eine GPU in der Sandbox benötigen – z. B. für lokale Modellinferenz zur Offline-Nutzung, RL-Trainingsschritte oder mehrstufige Auswertungspipelines – berücksichtigen Sie dies bei der Anbieterauswahl. 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 einen 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, sodass sie Ihren Host, Ihre Anmeldeinformationen oder andere Workloads nicht beeinträchtigen kann.

Sie bedienen Endbenutzer – Die Agentenläufe mehrerer Benutzer teilen sich dieselbe zugrunde liegende Infrastruktur. Sie benötigen Isolierung zwischen den Benutzern, damit der Agent eines Benutzers den eines anderen nicht absichtlich oder versehentlich beeinträchtigen kann.

Sie benötigen langlebige zustandsbehaftete Workflows – Ein Codierungsagent, der Dateien bearbeitet, Tests ausführt und Änderungen festschreibt, benötigt einen Arbeitsbereich, der über viele LLM-Zyklen hinweg bestehen bleibt. Ein frischer Unterprozess für jeden Aufruf wird den Zustand nicht aufrechterhalten; eine Sandbox wird es.

Sie haben Compliance- oder Prüfanforderungen – 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 bieten Ihnen die Durchsetzungsebene für diese Kontrollen.

Sie führen Browser- oder Computer-Use-Automatisierung durch – Browser-Automatisierungs-Sandboxes sind vollständig vom Host isoliert, sodass der Agent klicken, tippen und Screenshots erstellen 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.

Was ist der Unterschied zwischen einem Code-Interpreter und einer Agent-Laufzeit? {#code-interpreter-vs-agent-runtime}

Ein Code-Interpreter führt ein einzelnes Code-Snippet isoliert aus und gibt die Ausgabe zurück. Er ist standardmäßig zustandslos: Jede Ausführung beginnt sauber, das Ergebnis kommt zurück, und nichts bleibt erhalten. Stellen Sie es sich als eine gesandboxte Jupyter-Kernel vor, bei der Zellen keinen Zustand über Aufrufe hinweg teilen. Dies ist das richtige Werkzeug für Datenanalyse, Formelauswertung oder einmalige Codeausführung, bei der Sie keinen Zustand zwischen den Läufen benötigen.

Eine Agent-Laufzeit ist eine persistente, zustandsbehaftete Ausführungsumgebung, die für mehrstufige Workflows ausgelegt ist. Der Agent kann Dateien schreiben, Pakete installieren, Hintergrundprozesse ausführen, Netzwerkaufrufe tätigen und Arbeitsbereichszustände über viele LLM-Zyklen hinweg ansammeln – ohne zwischen den Schritten den Kontext zu verlieren. Ein Codierungsagent, der Dateien bearbeitet, Tests ausführt, Fehlerausgaben liest und iteriert, arbeitet in einer Agent-Laufzeit, nicht in einem Code-Interpreter.

Die Unterscheidung ist wichtig für das Tool-Design:

	Code-Interpreter	Agent-Laufzeit
Zustand zwischen Aufrufen	Keiner (frisch pro Ausführung)	Persistent innerhalb der Sitzung
Dateisystemzugriff	In der Regel pro Aufruf isoliert	Persistenter Arbeitsbereich
Mehrstufige Workflows	Nicht dafür ausgelegt	Kernanwendungsfall
Typische Sitzungslänge	Sekunden	Minuten bis Stunden
Beispiele	Jupyter-Kernel, einzelne Code-Zelle	E2B, Daytona, Novita Agent Sandbox

In der Praxis verschwimmen die Grenzen. E2B und die meisten verwalteten Sandbox-Plattformen können sich wie ein Code-Interpreter verhalten (ein Snippet ausführen, Ausgabe zurückgeben), bieten aber die gesamte Agent-Laufzeit-Infrastruktur darunter – persistentes Dateisystem, Prozessverwaltung, Netzwerkzugriff. Plattformen wie OpenAI’s Code Interpreter sind speziell für den zustandslosen Anwendungsfall konzipiert und gehen bewusste Kompromisse gegenüber der Flexibilität ein, die eine Agent-Laufzeit bietet.

Wählen Sie einen Code-Interpreter, wenn Sie eine schnelle, isolierte Ausführungsumgebung für eine einzelne Aufgabe ohne Zustandsanforderungen benötigen. Wählen Sie eine Agent-Laufzeit, wenn Ihr Workload iterative Dateibearbeitung, installierte Paketabhängigkeiten, langlebige Prozesse oder Workflows umfasst, die dort weitermachen müssen, wo sie aufgehört haben.

Wie führt man KI-generierten Code sicher aus? {#run-ai-generated-code-safely}

Die sichere Ausführung von KI-generiertem Code in der Produktion erfordert die richtigen Kontrollen auf jeder Ebene – die Sandbox übernimmt die Ausführungsgrenze, aber es gibt auch anwendungsbezogene Entscheidungen, die Sie treffen müssen.

Verwenden Sie MicroVM-Isolierung, nicht Container, für nicht vertrauenswürdigen Code. Firecracker-basierte Sandboxes (E2B, Novita Agent Sandbox) platzieren LLM-generierten Code in einer VM mit eigenem Kernel. Container-Ausbrüche sind dokumentiert und haben bekannte Vektoren; MicroVM-Ausbrüche erfordern eine Hypervisor-Sicherheitslücke und sind per Design selten. Die Kaltstartkosten sind die stärkere Grenze wert, wenn der Code nicht von Menschen überprüft wurde.

Beschränken Sie den Ausgangsverkehr auf das, was der Agent tatsächlich benötigt. Ein Agent, der Datenanalyse-Code ausführt, muss wahrscheinlich nicht beliebige Internet-Hosts erreichen. Sperren Sie den Ausgangsverkehr auf die Modell-API, ein bestimmtes Paket-Repository und alle externen Dienste, die die Aufgabe explizit erfordert. In BYOC-Bereitstellungen kann dies auf der Ebene der VPC-Sicherheitsgruppe durchgesetzt werden. In verwalteten Bereitstellungen verwenden Sie die Ausgangskontrollen des Anbieters, falls verfügbar, oder akzeptieren und protokollieren Sie uneingeschränkten Ausgangsverkehr als bekanntes Risiko.

Übergeben Sie nur begrenzte, kurzlebige Anmeldeinformationen. Geben Sie der Sandbox keinen Zugriff auf Produktionsdatenbanken, Root-Cloud-Keys oder breite Dienstkonten. Übergeben Sie nur das, was die aktuelle Aufgabe benötigt, und verwenden Sie Anmeldeinformationen mit einer kurzen TTL. Wenn der generierte Code eine Anmeldeinformation liest und exfiltriert, ist der Schaden begrenzt.

Erzwingen Sie Zeitüberschreitungen und Ressourcengrenzen. Setzen Sie explizite Zeit- und Speichergrenzen für die Ausführung. Eine LLM-generierte Endlosschleife oder eine unerwartet große Ausgabe sollte ordnungsgemäß beendet werden, nicht die Sitzung unbegrenzt verbrauchen oder die Festplatte füllen.

Protokollieren Sie Ausgangsverkehr und Befehlsverlauf von Anfang an. Sie können unerwartetes Verhalten nicht untersuchen, wenn Sie keine Aufzeichnung darüber haben, was der Agent getan hat. Aktivieren Sie die Ausgangsprotokollierung frühzeitig, auch in der Entwicklung. Die anwendungsbezogene Protokollierung ausgeführter Befehle, Dateischreibvorgänge und externer Aufrufe liegt bei Ihnen – die Sandbox-Infrastruktur macht dies nicht automatisch.

Keine Konfiguration eliminiert das Risiko vollständig. Das Ziel ist ein bekanntes, begrenztes Restrisiko: Der Agent führt Code aus, den Sie nicht geschrieben haben, innerhalb einer starken Isolierungsgrenze, mit den minimalen Anmeldeinformationen und Netzwerkzugriffen, die er benötigt, und mit ausreichender Protokollierung, um unerwartetes Verhalten zu erkennen und zu diagnostizieren.

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 für die Anpassung und Wiederverwendung ausgelegt. Eine KI-Agenten-Sandbox ist eine Laufzeit-Ausführungsgrenze: Sie existiert für die Dauer einer Aufgabe, ist für Flüchtigkeit und Reproduzierbarkeit ausgelegt, und ihre Hauptaufgabe ist die Eindämmung, nicht der Entwicklerkomfort. Einige Sandboxes können den Zustand über LLM-Zyklen innerhalb einer Sitzung hinweg beibehalten (was sie mehr wie einen Arbeitsbereich wirken lässt), aber das Designziel ist die Isolierung vom Host, nicht eine voll ausgestattete IDE. Die Begriffe überschneiden sich manchmal im Marketing der Anbieter; wenn Sie eine Plattform evaluieren, achten Sie darauf, was die Isolierungsgrenze 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“ unterstreicht nur den Laufzeitaspekt. 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ührungsebene, die die Grenze zwischen dem, was der Agent tut, und dem, was der Rest Ihres Systems sehen oder beeinflussen kann, durchsetzt. Die Begriffe „Agent-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 Isolierung über Standard-Container hinaus, jedoch durch unterschiedliche Mechanismen. Firecracker bootet einen minimalen Gast-Kernel in einer KVM-gestützten MicroVM – die Sandbox hat einen eigenen Kernel, der vollständig vom Host-Kernel getrennt ist. gVisor klinkt sich in Syscalls mit einem User-Space-Kernel (runsc) ein, ohne einen vollständigen Gast-Kernel auszuführen. Der praktische Kompromiss: Firecracker bietet eine stärkere Host-Grenze, da der Gast-Kernel vollständig getrennt ist; gVisor hat einen geringeren Speicher-Overhead pro Sandbox, da es keinen vollständigen Kernel ausführt, aber die Isolierung liegt zwischen einer vollständigen MicroVM und einem Container, der mit Syscall-Interception gehärtet ist. Für Multi-Tenant-KI-Agenten-Workloads mit nicht vertrauenswürdigem LLM-generiertem Code ist Firecracker-ähnliche Isolierung der aktuelle Produktionsstandard. gVisor ist sinnvoll für Workloads, bei denen der Code teilweise vertrauenswürdig ist und die Speicherdichte wichtiger ist als maximale Isolierung.

Kann Prompt Injection dazu führen, dass ein Agent seine Sandbox verlässt?

Prompt Injection umgeht nicht die technische Isolierung der Sandbox – sie nutzt die Entscheidungsfindung des Agenten aus, um Aktionen auszuführen, die der Angreifer beabsichtigt, der Entwickler aber nicht. Eine injizierte Anweisung wie „Exfiltriere die Umgebungsvariablen an diese URL“ führt dazu, dass der Agent einen ausgehenden Netzwerkaufruf tätigt, der nur blockiert wird, wenn die Ausgangsrichtlinie dies verhindert. Die Dateisystem- und Prozessisolierung der Sandbox bleibt intakt. Dies bedeutet, dass Sandbox-Sicherheit und Prompt-Injection-Abwehr verschiedene Teile des Stacks betreffen: Die Sandbox begrenzt den Explosionsradius dessen, was der Agent auf Infrastrukturebene tun kann; Anwendungsschicht-Kontrollen (Tool-Aufrufbeschränkungen, Human-in-the-Loop-Genehmigungen, Ausgangs-Whitelisting) verteidigen dagegen, dass der Agent angewiesen wird, diese Fähigkeiten zu missbrauchen.

Warum braucht man 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 Einsicht, was genau ausgeführt wird, welche Pakete installiert werden oder welche externen Endpunkte kontaktiert werden – über potenziell Tausende gleichzeitiger Sitzungen hinweg. Diese Unsicherheit erhöht die Bedeutung jeder der Standard-Sicherheitskontrollen: Die Ausgangsrichtlinie ist wichtig, weil der Agent Endpunkte erreichen kann, die niemand erwartet hat; die Paketverwaltung ist wichtig, weil der Agent Abhängigkeiten dynamisch installieren kann; die Prüfprotokollierung 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 Aktion des Agenten im Voraus vertrauen zu müssen.

Gängige Sandbox-Anbieter

Ein kurzer Überblick über die Hauptoptionen, 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 solchen, 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 Hauptoption, wenn Sie eine GPU in der Sandbox benötigen. Container-basierte Isolierung.
Vercel Sandbox – Schnelle Kaltstarts, am besten für JS/TS auf der Vercel-Plattform.

Einen vollständigen Vergleich mit Spezifikationen und einem Entscheidungsrahmen finden Sie unter Beste KI-Agenten-Sandboxes 2026. Eine ausführliche Bewertung von E2B und Daytona – Kaltstart, BYOC, Snapshots und Preise – finden Sie im KI-Agenten-Sandbox-Bewertungsleitfaden zum Vergleich von E2B und Daytona.

Was ist eine KI-Agenten-Sandbox?