AI Agent Sandbox FAQ: Sicherheit, Isolation, Egress, Dateien und Zustand

Dieses AI Agent Sandbox FAQ beantwortet die praktischen Sicherheitsfragen, die sich Entwickler stellen, bevor sie agentengenerierten Code ausführen: wie Isolation funktioniert, welchen Netzwerkzugriff Agenten haben, wohin Dateien und Sitzungszustände gehen und wie man mit Secrets, Audit-Logs, Compliance und Kosten umgeht. Wenn Sie neu bei Sandboxes sind, beginnen Sie mit Was ist eine AI Agent Sandbox? für eine Einführung in Isolationsmodelle, Egress und Snapshotting. Wenn Sie einen Anbieter auswählen, lesen Sie Die besten AI Agent Sandboxes 2026 oder den E2B vs. Daytona Evaluierungsleitfaden.

---

Warum AI Agenten sandboxen

Warum verwenden Teams eine dedizierte Sandbox für AI Agenten?

AI Agenten unterscheiden sich in einem entscheidenden Punkt von traditioneller Software: Der Code, den sie ausführen, wird nicht von einem Menschen geschrieben und vor der Ausführung geprüft. Ein LLM generiert Anweisungen, wählt Tools aus, installiert Pakete und tätigt API-Aufrufe dynamisch – oft auf Weisen, die der Anwendungsentwickler nicht im Voraus aufgelistet hat. Eine Sandbox bietet eine Laufzeit-Erzwingungsschicht, die die Konsequenzen dieser Aktionen eingrenzt, ohne dass jede mögliche Aktion vorab genehmigt werden muss. Ohne eine Sandbox kann ein fehlverhaltender oder manipulierte Agent das Host-System, benachbarte Workloads oder die externe Infrastruktur beeinträchtigen. Mit einer Sandbox ist der schlimmste anzunehmende Schadensradius auf die isolierte Umgebung beschränkt, die nach der Sitzung verworfen werden kann.

Was ist die Codeausführung eines AI Agenten?

Die Codeausführung eines AI Agenten ist die Laufzeitphase, in der die Entscheidungen eines LLMs zu tatsächlichen Anweisungen werden, die ein Computer ausführt. Der Agent erhält eine Aufgabe, denkt darüber nach, generiert Code oder Tool-Aufrufe, und die Ausführungsschicht führt diese Aktionen aus und gibt die Ergebnisse an den Agenten zurück. Eine Sandbox ist die Standard-Infrastrukturschicht für diese Ausführungsphase: Sie stellt die Rechenleistung, das Dateisystem und die Netzwerkumgebung bereit, die der Agent benötigt, während diese Umgebung von allem anderen isoliert bleibt. Der Zyklus „Modell denkt → Ausführungsschicht läuft → Ergebnisse fließen zurück zum Modell“ wiederholt sich, bis der Agent die Aufgabe abgeschlossen hat.

Wie unterscheidet sich Sandboxing von der bloßen Ausführung eines Agenten in einem Container?

Ein Container fügt eine Trennung von Dateisystem- und Netzwerk-Namespaces hinzu, aber alle Container auf demselben Host teilen sich den OS-Kernel. Bei AI Agenten, die LLM-generierten Code aus nicht vertrauenswürdigen Eingaben ausführen, könnte ein Kernel-Level-Escape durch eine gemeinsam genutzte Schwachstelle benachbarte Workloads beeinträchtigen. Eine dedizierte AI Agent Sandbox fügt typischerweise eine microVM-Grenze hinzu: Der Code des Agenten läuft in einer leichtgewichtigen virtuellen Maschine mit einem eigenen Gast-Kernel, sodass selbst ein Kernel-Exploit im Gast den Host nicht beeinträchtigt. Der praktische Kompromiss ist ein kleiner zusätzlicher Kaltstart-Overhead (normalerweise unter 500 ms für Firecracker-basierte Plattformen). Siehe den Abschnitt Isolationsmodelle für einen vollständigen Vergleich.

---

Sandbox-Isolationsmodelle

Was bedeutet „Isolation“ in einer AI Agent Sandbox?

Isolation bedeutet, dass der Code, die Dateien, die Prozesse und der Netzwerkzugriff des Agenten auf eine begrenzte Umgebung beschränkt sind, die das Host-System oder andere Mandanten nicht beeinträchtigen kann. In der Praxis ist Isolation ein Spektrum: Prozess-Isolation verwendet OS-Primitive (Namespaces, cgroups, seccomp), um Syscalls und Ressourcenzugriff einzuschränken; Container-Isolation fügt eine Dateisystem- und Netzwerk-Namespace-Grenze hinzu; und microVM-Isolation hüllt die Workload in eine leichtgewichtige virtuelle Maschine mit einem eigenen Gast-Kernel ein. Jede Stufe aufwärts im Stack erhöht die Grenzstärke auf Kosten von etwas Start-Overhead und betrieblicher Komplexität. Für einen umfassenden Überblick über alle Isolationsdimensionen siehe Was ist eine AI Agent Sandbox?. Siehe Firecracker für AI Agent Sandboxes für einen detaillierten Bewertungsrahmen.

Reicht Docker für die Ausführung von agentengeneriertem Code?

Container bieten wiederholbare Images und gute Ressourcenkontrollen, aber alle Container auf demselben Host teilen sich den Host-Kernel. Eine Kernel-Schwachstelle oder ein Syscall, der durch den seccomp-Filter schlüpft, kann andere Workloads beeinträchtigen. Für risikoarme, kurzlebige Aufgaben, die vertrauenswürdigen oder nahezu vertrauenswürdigen Code ausführen, sind Container oft ausreichend, wenn sie richtig gehärtet sind – kein privilegierter Modus, minimale Capabilities, kein gemounteter Docker-Socket, nach Möglichkeit read-only Root-Dateisystem. Für nicht vertrauenswürdigen KI-generierten Code, der Pakete installieren, Subprozesse erzeugen oder beliebige Shell-Befehle aufrufen kann, ist eine stärkere Grenze eine Überlegung wert. Die Antwort hängt von Ihrem tatsächlichen Bedrohungsmodell ab. Siehe AI-Generated Code Sandbox: Requirements for Production Apps für die Überprüfungsliste auf jeder Isolationsebene.

Was ist der Unterschied zwischen Container- und microVM-Isolation?

Der Hauptunterschied ist die Kernel-Grenze. Container teilen sich den Host-Kernel; microVMs führen jeweils einen Gast-Kernel in einer leichtgewichtigen virtuellen Maschine aus, unterstützt durch Hardware-Virtualisierung (KVM). Eine microVM-basierte Sandbox, die Technologie wie Firecracker verwendet, bietet eine VM-artige Grenze ohne den vollen Overhead einer traditionellen VM: Die Startlatenz ist für schnelle Ausführung ausgelegt, das Gerätemodell ist minimal, um die Angriffsfläche zu reduzieren, und der Gast ist per Design vom Host-Kernel isoliert. Die praktische Implikation ist, dass ein Kernel-Exploit im Gast nicht automatisch den Host oder andere Gäste beeinträchtigt, während dies in einem Shared-Kernel-Containermodell möglich wäre. Siehe Firecracker für AI Agent Sandboxes für Fälle, in denen die microVM-Grenze hilft und wo sie nicht das gesamte Problem löst.

Existiert eine Sandbox pro Agent, pro Benutzer oder pro Aufgabe?

Das hängt von der Plattform und davon ab, wie die Anwendung entworfen ist. Das sicherste Muster für Multi-Tenant-Apps ist eine isolierte Sandbox-Umgebung pro Agentenlauf oder pro Aufgabe – das bedeutet, dass jede Benutzersitzung ihren eigenen Prozessbaum, ihr eigenes Dateisystem, ihren eigenen Netzwerk-Namespace und ihren eigenen Credential-Bereich hat. Das Teilen einer Sandbox zwischen Benutzern oder zwischen nicht zusammenhängenden Aufgaben ist die häufigste Ursache für State-Leaks in Produktions-Agenten-Apps. Überprüfen Sie bei der Bewertung einer Plattform, ob gleichzeitige Sitzungen auf Dateisystem-, Prozess- und Netzwerkebene isoliert sind, nicht nur auf der API-Routing-Ebene. Siehe AI-Generated Code Sandbox: Requirements for Production Apps für die Checkliste zur Sitzungsisolation.

---

Sandbox-Egress und Netzwerkrichtlinien

Kann ein AI Agent ausgehende Netzwerkaufrufe aus einer Sandbox tätigen?

Es hängt von der Egress-Richtlinie der Sandbox ab. Standardmäßig erlauben viele Sandboxes ausgehende Verbindungen, was praktisch für Web-Recherche, API-Aufrufe und Paketinstallationen ist. Für Produktions-Workloads, die nicht vertrauenswürdigen Code ausführen, ist ein standardmäßig offener Egress ein Risiko: Ein kompromittierter oder fehlverhaltender Agent kann Daten exfiltrieren, interne Metadaten-Dienste erreichen oder unerwarteten Code von beliebigen URLs ziehen. Eine stärkere Produktionshaltung ist ein standardmäßig geschlossener Egress mit einer expliziten Allowlist erlaubter Ziele. Unabhängig von der gewählten Richtlinie sollte sie explizit sein und protokolliert werden. Siehe Firecracker für AI Agent Sandboxes für die Bewertung von Netzwerkkontrollen.

Wie wird DNS in einer Sandbox kontrolliert?

DNS ist eine häufige Lücke in der Egress-Richtlinie: Eine Allowlist für HTTP-Ziele schränkt die DNS-Auflösung nicht automatisch ein. Ein Agent, der beliebige Domainnamen auflösen kann, kann die Netzwerktopologie ableiten, interne Namen abfragen oder DNS als Seitenkanal nutzen, selbst wenn HTTP blockiert ist. Für eine kohärente Egress-Richtlinie sollte die DNS-Auflösung konsistent gehandhabt werden – entweder durch einen internen Resolver, der die Allowlist respektiert, oder durch Einschränkung der Auflösung auf genehmigte Domains. Fragen Sie bei Ihrem Sandbox-Anbieter, wie DNS im Verhältnis zur übergeordneten Egress-Richtlinie abgegrenzt ist.

Wie werden Paketabrufe während netzwerkeingeschränkter Sitzungen kontrolliert?

Paketinstallationen sind Netzwerkoperationen. Wenn der Egress auf eine Allowlist beschränkt ist, muss die Allowlist die Paketregistries enthalten, die der Agent legitimerweise benötigt, oder die Sandbox sollte einen Pull-Through-Cache innerhalb des vertrauenswürdigen Netzwerks bereitstellen. Der Pull-Through-Cache hat den zusätzlichen Vorteil, als Inspektionspunkt zu dienen: Sie können sehen, welche Pakete abgerufen werden, unerwartete Abhängigkeiten erkennen und redundanten Egress reduzieren. Einige Teams verwenden vorgefertigte Sandbox-Vorlagen für Workloads, bei denen Reproduzierbarkeit wichtiger ist als Flexibilität, was Laufzeit-Paketabrufe vollständig eliminiert. Siehe den Abschnitt Paketinstallationen für mehr Informationen zur Steuerung von Laufzeitinstallationen.

---

Dateizugriff und das Host-Dateisystem

Welchen Dateizugriff hat ein gesandboxtes Agent?

Ein gesandboxtes Agent sollte nur Zugriff auf die Dateien haben, die explizit in seinen Arbeitsbereich eingebunden wurden. Für einen Coding-Agent könnte das ein ausgechecktes Repository und ein Arbeitsverzeichnis für generierte Artefakte sein. Für einen Datenanalyse-Agent könnte das eine hochgeladene CSV-Datei und ein Ausgabeordner sein. Der Agent sollte nicht in der Lage sein, das Host-Dateisystem, die Arbeitsbereiche anderer Mandanten, die Secrets des Anwendungsservers oder Systemverzeichnisse außerhalb seiner eingebundenen Pfade zu erreichen. Eine gute Praxis ist, Quellmaterial schreibgeschützt zu mounten und ein separates Lese-/Schreib-Ausgabeverzeichnis für generierte Artefakte bereitzustellen. Siehe MCP Server Sandbox: Isolierte MCP-Server mit Dateisystem-, Secrets- und Netzwerkkontrollen für die Eingrenzung von Dateisystem-Mounts pro Tool.

Ist das Host-Dateisystem von innerhalb einer Sandbox aus zugänglich?

Es sollte nicht sein. Eine korrekt konfigurierte Sandbox – Container oder microVM – schränkt die Sicht des Agenten auf sein eigenes Gast-Dateisystem ein. Der Zugriff auf das Host-Dateisystem von innerhalb einer Sandbox ist ein Konfigurationsfehler, kein erwartetes Verhalten. Häufige Fehler, die diese Grenze durchbrechen, sind das Einbinden breiter Verzeichnisse (wie das Home-Verzeichnis eines Entwicklers oder /), die Verwendung des privilegierten Modus in Containern oder das Einbinden des Docker-Sockets in die Sandbox. Überprüfen Sie bei der Bewertung einer Plattform oder beim Bau einer eigenen, was eingebunden ist, welche Berechtigungen das Root-Dateisystem hat und ob Symlink-Escapes oder Archiv-Extraktions-Tricks Pfade außerhalb des beabsichtigten Arbeitsbereichs erreichen können.

Was passiert mit Dateien nach dem Ende einer Sitzung?

Bei ephemeren Sitzungen werden das Arbeitsverzeichnis und alle generierten Dateien gelöscht, wenn die Sitzung beendet wird. Dies ist die richtige Standardeinstellung für Code-Vervollständigung, Evaluierungsläufe und alle Aufgaben, bei denen Reproduzierbarkeit wichtiger ist als Kontinuität. Für persistente Arbeitsbereiche (langlebige Coding-Agenten, iterative Entwicklungssitzungen) können Dateien über Ausführungsaufrufe innerhalb einer Sitzung hinweg erhalten bleiben und nach dem Ende der Sitzung beibehalten werden, wenn die Plattform Arbeitsbereich-Persistenz oder Snapshots unterstützt. Die Schlüsselfragen sind: Wem gehört ein beibehaltener Arbeitsbereich, wann wird er bereinigt und kann der Arbeitsbereich eines Benutzers zu einem anderen durchsickern? Siehe AI-Generated Code Sandbox: Requirements for Production Apps für die Checkliste zum Persistenzmodell.

---

Sitzungszustand und Persistenz

Ist eine Sandbox-Sitzung zustandsbehaftet oder ephemer?

Beide Muster existieren und bedienen unterschiedliche Workloads. Ephemere Sitzungen beginnen für jede Aufgabe von einer sauberen Basislinie – keine angesammelten Pakete, Dateien oder Verlaufsdaten. Sie sind leichter zu durchschauen und ideal für Evaluierungsläufe oder einmalige Codeausführungen. Zustandsbehaftete Sitzungen bewahren Dateien, installierte Pakete, Shell-Verlauf und Umgebungszustand über mehrere Ausführungsaufrufe hinweg, was für mehrschrittige Coding-Agenten, interaktive Datenanalyse und langlaufende Workflows notwendig ist. Die meisten Produktionsplattformen unterstützen beides. Der Kompromiss ist, dass zustandsbehaftete Sitzungen explizite Bereinigungsrichtlinien und eine sorgfältigere Mandantenisolierung erfordern.

Wie lange bleibt der Zustand in einer verwalteten Sandbox bestehen?

Die Sitzungsdauer variiert je nach Plattform und Plan. Einige Anbieter legen ein Standard-Sitzungs-Timeout fest (häufig 60 Minuten bis 24 Stunden), nach dem die Sitzung beendet und der Zustand verloren geht, sofern er nicht in einem Snapshot oder externen Speicher persistiert wird. Langlaufende Agent-Workflows – Sitzungen, die zwischen LLM-Aufrufen für Minuten oder Stunden pausieren können – benötigen eine Plattform, die Sitzungspause und -fortsetzung oder Autopause unterstützt, um Abrechnung für Leerlaufzeiten zu vermeiden und gleichzeitig den Zustand zu bewahren. Überprüfen Sie die maximale Sitzungslänge und was mit dem laufenden Zustand passiert, wenn ein Timeout eintritt. Novita Agent Sandbox unterstützt Sitzungen von bis zu 24 Stunden und dokumentiert eine Pause/Autoresume-Funktion zur Verwaltung von Leerlaufzeiten. Siehe Novita Sandbox: Eine kostengünstige Alternative zu E2B Pro mit nahtloser Kompatibilität für einen Funktionsvergleich.

Können Sitzungen pausiert und fortgesetzt werden?

Einige Plattformen unterstützen Pause und Fortsetzung, bei der die Sitzung auf die Festplatte ausgelagert und später aus demselben Zustand neu gestartet werden kann. Dies ist nützlich für Agenten, die zwischen Schritten auf LLM-Antworten warten, für die Ratenbegrenzung teurer Workloads und für Sitzungen, die mehrere Benutzerinteraktionen über die Zeit umfassen. Die wichtigsten Überprüfungspunkte sind: Wie lange kann eine pausierte Sitzung im ausgelagerten Zustand bleiben, was passiert mit Netzwerkverbindungen, die während einer Pause gehalten werden, und bleiben die zu Sitzungsbeginn injizierten Credentials nach der Fortsetzung gültig oder müssen sie erneuert werden?

Kann der Sandbox-Zustand gesnapshotet und wiederverwendet werden?

Vorlagen und Snapshots sind verwandt, aber unterschiedlich. Eine Vorlage ist eine vorgefertigte Basisumgebung – Laufzeiten, Tools, genehmigte Pakete – von der neue Sitzungen ausgehen. Ein Snapshot erfasst den aktuellen Zustand einer laufenden Sitzung und verwendet ihn als Ausgangspunkt für zukünftige Sitzungen. Vorlagen reduzieren den Start-Overhead pro Sitzung und stellen sicher, dass alle Agenten von einer konsistenten, kontrollierten Basislinie ausgehen. Snapshots sind nützlich, um Teilarbeiten zu bewahren oder iterative Jobs warm zu starten. Beide benötigen Governance: Wer kann sie erstellen, wer kann sie lesen, zu welchem Mandanten gehören sie und wie werden sie versioniert?

---

Paketinstallationen und Laufzeitabhängigkeiten

Können Agenten zur Laufzeit Pakete installieren?

Die meisten Sandbox-Umgebungen erlauben standardmäßig Paketinstallationen zur Laufzeit (pip install, npm install, apt-get usw.), da viele Agent-Workloads sie benötigen. Die Frage ist nicht, ob Installationen erlaubt sind, sondern ob jede Installation kontrolliert wird. Ungesteuerte Paketinstallationen gehören zu den risikoreichsten Operationen in einer Sandbox: Sie ziehen externen Code zur Laufzeit in die Ausführungsumgebung, können Post-Install-Skripte enthalten, die beliebige Befehle ausführen, und können Lieferkettenrisiken einführen.

Welche Richtlinien steuern Paketinstallationen zur Laufzeit?

Eine Produktions-Paketrichtlinie umfasst typischerweise eine Kombination aus Registry-Allowlisting (nur von genehmigten Paketregistries oder Mirrors abrufen), Pull-Through-Caches (inspizieren, was eintritt, bevor es ausgeführt wird), Installationsprotokollierung (Paketname, Version, Quelle und Ergebnis für jede Installation aufzeichnen) und optionalem Offline-Modus (Abhängigkeiten in die Vorlage einbacken und Laufzeitinstallationen für Evaluierungspipelines, bei denen Reproduzierbarkeit wichtig ist, verbieten). Die richtige Richtlinie hängt vom Workload ab: Ein Coding-Agent, der einem Entwickler beim Debuggen von Code hilft, benötigt möglicherweise flexiblen Paketzugriff; eine automatisierte Evaluierungspipeline sollte wahrscheinlich aus einer eingefrorenen Umgebung laufen. Siehe Erstellen Sie einen AI-Datenanalysten mit gesandboxtem Python und kontrolliertem Paketzugriff für ein praktisches Implementierungsbeispiel.

---

Secrets und Credential-Handling

Wie werden Secrets und Credentials in einer Sandbox gehandhabt?

Secrets sollten eng injiziert werden – nur die Credential, die eine bestimmte Aufgabe benötigt, für die Dauer dieser Sitzung. Der häufige Anti-Pattern ist das Einbinden einer breiten Umgebungsdatei mit allen API-Keys in jede Sitzung; das bedeutet, dass jede Sitzung, wenn sie kompromittiert wird, auf jede Credential in dieser Datei zugreifen kann. Bevorzugen Sie kurzlebige Tokens, die auf die Aufgabe beschränkt sind, und bevorzugen Sie Injektionsmechanismen (Umgebungsvariablen oder eingebundene Dateien) gegenüber Hardcoding. Für die sensibelsten Credentials bietet eine Laufzeit-Secrets-API, die Werte nur einem explizit autorisierten Prozess bereitstellt, eine stärkere Isolation als eine flache Umgebungsvariable, die für alle Prozesse verfügbar ist.

Kann das Modell Umgebungsvariablen sehen, die in die Sandbox injiziert wurden?

Ja, wenn die Umgebungsvariable in den Prozess injiziert wird, in dem der Code des Modells läuft. Umgebungsvariablen sind standardmäßig für alle Prozesse in derselben Sitzung sichtbar. Das Modell kann sie nicht direkt aus seinem Kontextfenster lesen, aber generierter Code, der innerhalb der Sandbox ausgeführt wird, kann sie mit os.environ, process.env oder Äquivalenten lesen. Deshalb ist ein enger Geltungsbereich wichtig: Injizieren Sie nur die Credentials, die die Aufgabe erfordert, und bevorzugen Sie kurzlebige Tokens, damit eine durchgesickerte Credential ein begrenztes Nutzungsfenster hat. Die Redaktion liegt in der Verantwortung der Anwendung: Protokollieren Sie nicht standardmäßig die vollständige Standardausgabe, wenn Secrets in Fehlermeldungen oder Print-Anweisungen erscheinen könnten.

Was passiert mit Secrets, wenn eine Sitzung endet?

Umgebungsvariablen und eingebundene Secret-Dateien sollten im Rahmen des Sitzungsabbaus bereinigt werden. Wenn die Plattform den Zustand über Sitzungen hinweg bewahrt (Snapshots, persistente Volumes), überprüfen Sie, ob Credentials, die auf das Dateisystem geschrieben oder von einem Credential-Provider zwischengespeichert wurden, ebenfalls bereinigt oder rotiert werden. Veraltete Credentials in einem wiederaufnehmbaren Snapshot sind ein Risiko – nach dem Sitzungsabbau sollte der Snapshot keine Tokens behalten, die nur für die ursprüngliche Sitzungsdauer gültig waren.

---

Audit-Logs und Beobachtbarkeit

Welche Ereignisse werden in einer Sandbox protokolliert?

Nützliche Sandbox-Audit-Aufzeichnungen umfassen Sitzungserstellung und -abbau (Sitzungs-ID, Mandant, Vorlagenversion, Ressourcenzuweisung, Dauer), Ausführungsereignisse (welcher Code oder Befehlsart lief, Start-/Endzeit, Exit-Status), Paketinstallationen (Name, Version, Quelle, Ergebnis), ausgehende Netzwerkkontakte (Domains, IPs, Ports), von bestimmten Pfaden gelesene oder geschriebene Dateien und das Bereinigungsergebnis. Das Ziel ist, das Agentenverhalten im Nachhinein rekonstruierbar zu machen, ohne das Audit-Log in einen zweiten Secrets-Speicher zu verwandeln. Rohe Kundendateien, vollständige Befehlsausgaben und vollständige Prompts gehören im Allgemeinen nicht in Audit-Logs, es sei denn, Ihre Aufbewahrungs- und Zugriffskontrollen sind speziell für diese Daten ausgelegt.

Wer kann auf Audit-Logs zugreifen?

Zugriffskontrollen auf Audit-Logs sollten auf den Betreiber und, wo relevant, auf den Mandanten beschränkt sein. In Multi-Tenant-Plattformen sollten die Audit-Aufzeichnungen eines Mandanten für andere Mandanten nicht sichtbar sein. Für compliance-sensitive Bereitstellungen muss der Audit-Trail manipulationssicher, für den erforderlichen Zeitraum aufbewahrt und für autorisierte Prüfer (Sicherheitsteam, Compliance-Beauftragter) auf Anfrage zugänglich sein. Fragen Sie Ihren Sandbox-Anbieter, welche Log-Aufbewahrungsfrist standardmäßig gilt, ob Logs in Ihr eigenes SIEM oder Ihren eigenen Speicher exportiert werden können und welche Zugriffskontrollen die Logdaten schützen.

---

Compliance und Sicherheitsüberprüfung

Welche Compliance-Überprüfung ist vor der Verwendung einer Sandbox in der Produktion erforderlich?

Die spezifischen Anforderungen hängen von Ihrer Branche und Ihrem Rechtsraum ab, aber die Standardfragen für jedes Produktions-Agenten-System umfassen: Welche Daten gelangen in die Sandbox (und unterliegen diese Daten DSGVO, HIPAA, SOC 2 oder anderen Rahmenwerken), wo wird die Sandbox gehostet und erfüllt dies die Anforderungen an die Datenresidenz, welches Isolationsmodell wird verwendet und kann es einem Prüfer dokumentiert werden, wie werden Credentials verwaltet und rotiert, und wie sieht der Audit-Trail aus? Die meisten Sicherheitsüberprüfungen werden auch fragen, ob generierter Code Produktionsdatenbanken, interne Admin-Oberflächen oder Kundendaten außerhalb des beabsichtigten Bereichs erreichen könnte. Dies sind architektonische Kontrollen, nicht nur Zertifizierungen des Anbieters.

Welche Fragen sollten Sicherheitsteams bei der Bewertung einer AI Agent Sandbox stellen?

Eine praktische Evaluierungs-Checkliste für die Sicherheitsüberprüfung:

• Isolation: Was ist die Grenze – Prozess, Container oder microVM? Ist jede Agentensitzung auf Dateisystem-, Prozess- und Netzwerkebene isoliert?
• Egress: Was ist die Standard-Egress-Richtlinie? Können ausgehende Ziele auf eine Allowlist gesetzt werden? Wie wird DNS kontrolliert?
• Secrets: Wie werden Credentials injiziert? Sind sie auf die Aufgabe beschränkt? Werden sie beim Sitzungsabbau bereinigt?
• Audit: Welche Ereignisse werden protokolliert? Wer kann auf Logs zugreifen? Wie lang ist die Aufbewahrungsfrist?
• Datenresidenz: Wo werden Sandboxes gehostet? Kann die Bereitstellung auf eine bestimmte Cloud-Region oder ein bestimmtes Konto beschränkt werden?
• Compliance-Posture: Verfügt der Anbieter über relevante Zertifizierungen (SOC 2, ISO 27001)? Wie sieht das Shared-Responsibility-Modell aus?
• Netzwerkreichweite: Kann eine Sandbox interne Metadaten-Dienste, private APIs oder Ressourcen anderer Mandanten erreichen? Wie wird laterale Bewegung verhindert?

Formulieren Sie dies als Fragen zur Bewertung, nicht als Anforderungen, die ein einzelner Anbieter automatisch erfüllt. Sicherheits- und Compliance-Behauptungen in der Anbieterdokumentation sollten anhand der aktuellen Produktdokumentation überprüft werden, nicht für bare Münze genommen werden. Für Teams mit regulatorischen oder vertraglichen Anforderungen sollte Ihr Sicherheitsteam die Überprüfung vor der Produktionsbereitstellung abschließen, nicht danach.

Wann ist BYOC (Bring Your Own Cloud) oder VPC-Bereitstellung relevant?

Datenresidenz-Anforderungen, Netzwerksicherheitsrichtlinien oder regulatorische Einschränkungen, die verbieten, dass Daten ein bestimmtes Cloud-Konto verlassen, sind die Hauptgründe, warum Teams BYOC oder VPC-Bereitstellung einem gemeinsam genutzten verwalteten Dienst vorziehen. Das Ausführen von Sandboxes in Ihrer eigenen AWS- oder GCP-VPC bedeutet, dass sich die Ausführungsumgebung innerhalb Ihres Netzwerkperimeters befindet, die Zugriffskontrollen Ihres Cloud-Kontos gelten und der Egress aus der Sandbox durch Ihre bestehenden Netzwerkrichtlinien gesteuert werden kann. Der Kompromiss ist die betriebliche Verantwortung: Sie kümmern sich um das Infrastrukturmanagement, Patchen und Skalieren. Novita Agent Sandbox dokumentiert die BYOC-Bereitstellung in AWS- oder GCP-Konten als Funktion für Teams mit diesen Anforderungen. Überprüfen Sie die aktuelle Verfügbarkeit und Konfigurationsoptionen in der Novita Agent Sandbox Dokumentation.

---

Sandbox-Preise und Kostenfaktoren

Was treibt die Sandbox-Kosten?

Die Sandbox-Kosten sind typischerweise eine Kombination aus Rechenzeit (vCPU und Speicher, abgerechnet pro Sekunde oder Minute), Sitzungs-Overhead (eine Startgebühr pro Sitzung auf einigen Plattformen), persistentem Speicher oberhalb der enthaltenen Free-Tier und ausgehendem Datentransfer (Egress). Das relative Gewicht jedes Faktors hängt von Ihrem Workload ab: Ein kurzlebiger Code-Interpreter ist hauptsächlich Rechenzeit; ein Browser-Automatisierungs-Agent, der große Dateien herunterlädt, kann erheblichen Egress erzeugen; ein persistenter Codierungsarbeitsbereich sammelt Speicher an. Die Handhabung von Leerlaufzeiten ist ein wichtiges Unterscheidungsmerkmal – Plattformen mit Autopause beenden die Abrechnung, wenn eine Sandbox auf eine LLM-Antwort wartet, was die Kosten für interaktive Workflows erheblich senken kann. Siehe AI Agent Sandbox Preismodelle: Pro Sitzung, Rechenzeit, Speicher und Egress für eine detaillierte Aufschlüsselung jeder Preisdimension.

Wie interagieren Sitzungszeit, Rechenzeit und Egress bei den Kosten?

Bei den meisten Workloads dominiert die Rechenzeit. Eine 10-minütige Codierungssitzung mit 1 vCPU kostet mehr als 1 GB Egress zu typischen Sätzen. Aber die Interaktion ist für bestimmte Workloads wichtig: Ein Daten-Agent, der einen großen Trainingsdatensatz herunterlädt, erzeugt Egress-Gebühren, die die Rechenkosten in den Schatten stellen. Ein Browser-Agent, der Sitzungen zwischen LLM-Durchgängen offen hält, sammelt Leerlauf-Rechenzeit an, wenn Autopause nicht aktiviert ist. Der praktische Ansatz ist, jede Dimension anhand Ihres tatsächlichen Workload-Profils zu schätzen, bevor Sie sich auf eine Plattform festlegen. Novita Agent Sandbox rechnet pro Sekunde basierend auf der tatsächlichen vCPU- und Speichernutzung ab, ohne Startgebühr pro Sitzung; Stand Mitte 2026 kostet 1 vCPU $0,0000098/s. (Quelle: Novita AI Preisseite, in der veröffentlichten Dokumentation überprüft. Überprüfen Sie vor der Budgetplanung immer die aktuellen Sätze.)

---

Selbsthosting vs. verwaltete AI Agent Sandbox

Wann sollten Teams selbst hosten, anstatt eine verwaltete Sandbox zu verwenden?

Selbsthosting (Betreiben einer eigenen Sandbox-Infrastruktur, oft auf Firecracker oder einer vergleichbaren microVM-Schicht) ist sinnvoll, wenn: Datenresidenz- oder Netzwerkrichtlinienanforderungen die Nutzung eines verwalteten Drittanbieterdienstes verbieten, das Workload-Volumen hoch genug ist, dass die Kosten des verwalteten Dienstes die Betriebskosten des Betriebs der eigenen Infrastruktur übersteigen, oder das Team bereits über Plattform-Engineering-Kapazitäten verfügt und die vollständige Kontrolle über das Isolationsmodell, die Image-Governance und die Netzwerkrichtlinie haben möchte. Selbsthosting ist schwieriger, als es aussieht: Die Verwaltung von Kernels, Root-Dateisystemen, Images, Snapshots, Ratenbegrenzern, Metriken, Bereinigung und Multi-Tenant-Isolation ist echte Arbeit. Siehe Firecracker für AI Agent Sandboxes für den Umfang der Betriebsaufgaben.

Wann ist eine verwaltete Sandbox sinnvoller?

Für die meisten Teams, die Coding-Agenten, Datenanalyse-Tools, Browser-Automatisierungs-Workflows oder Evaluierungspipelines entwickeln, ist eine verwaltete Sandbox der schnellere Weg in die Produktion. Die Plattform kümmert sich um die Infrastrukturbereitstellung, Sicherheitshärtung, Image-Updates, Skalierung und das Lebenszyklusmanagement. Das Team konzentriert sich auf die Agentenarchitektur, nicht auf die Sandbox-Interna. Der Kostenvergleich umfasst nicht nur Cloud-Compute-Sätze: Berücksichtigen Sie die Entwicklungszeit für den Aufbau und die Wartung der Isolationsschicht, die Compliance-Arbeit zu deren Dokumentation und die Incident-Response, wenn etwas Unerwartetes passiert. Für Teams ohne dedizierte Plattform-Engineering-Kapazitäten erreichen verwaltete Dienste typischerweise schneller die Produktion und weisen niedrigere Gesamtbetriebskosten auf. Siehe AI Agent Sandbox Preismodelle für einen Rahmen zum Vergleich der Gesamtkosten von verwaltetem und selbst gehostetem Betrieb.

Welche Fragen sollten Teams bei der Bewertung verwalteter Sandbox-Anbieter stellen?

Praktische Evaluierungsfragen über die Schlagzeilenpreise hinaus:

• Was ist das Isolationsmodell pro Sitzung (microVM, Container, Prozess)?
• Was ist die Standard- und konfigurierbare Egress-Richtlinie?
• Welche Optionen zur Steuerung von Paketinstallationen gibt es?
• Wie werden Secrets injiziert und bereinigt?
• Welche Audit-Log-Daten sind verfügbar und wie wird darauf zugegriffen?
• Was sind die Sitzungslängen- und Parallelitätsgrenzen auf Ihrer benötigten Stufe?
• Unterstützt der Anbieter BYOC- oder VPC-Bereitstellung?
• Wie ist das Pause/Fortsetzen-Verhalten und wie wirkt es sich auf die Abrechnung aus?
• Wie verhält sich die Startlatenz bei Skalierung (Warm Pool, Snapshot, Kaltstart)?

---

Ausführen von nicht vertrauenswürdigem Code sicher

Wie führe ich KI-generierten Code sicher in der Produktion aus?

Die Grundlage ist: Führen Sie LLM-generierten Code nicht auf Ihrem Host aus. Leiten Sie die gesamte Ausführung durch eine Sandbox, die Dateisystem-, Prozess- und Netzwerkisolation bietet. Darüber hinaus machen fünf Praktiken einen signifikanten Unterschied: (1) Legen Sie die Egress-Richtlinie explizit fest – Standardmäßig verweigern mit einer Allowlist ist sicherer als standardmäßig offen; (2) Grenzen Sie Secrets eng ein – injizieren Sie nur die Credentials, die die aktuelle Aufgabe benötigt; (3) Steuern Sie Paketinstallationen – erlauben Sie Installationen von genehmigten Registries oder verwenden Sie vorgebackene Images für reproduzierbare Workloads; (4) Protokollieren Sie auf Kernel- oder Hypervisor-Ebene, anstatt sich auf Anwendungsebene-Logs zu verlassen; (5) Legen Sie Ressourcengrenzen fest – CPU, Speicher, Festplatte und Wanduhr-Timeout – damit ein außer Kontrolle geratener Agent keine benachbarten Sitzungen beeinträchtigen kann. Siehe Wie sicher ist die AI Sandbox für die Codeausführung? für eine vollständige Evaluierungs-Checkliste.

Gibt es eine Open-Source-AI-Agent-Sandbox?

Ja. Daytona ist unter einer AGPL-Lizenz Open Source und unterstützt die selbst gehostete Bereitstellung. Das Kern-SDK von E2B ist Open Source, die verwaltete Laufzeitinfrastruktur jedoch nicht. Wenn Sie Ihre eigene Sandbox von Grund auf neu bauen möchten, ist der häufigste Ansatz Firecracker (von AWS entwickelt, lizenziert unter Apache 2.0) als microVM-Laufzeit, kombiniert mit Ihrem eigenen Image-Management, Ihrer eigenen Orchestrierung und Lebenszyklussteuerung. Selbsthosting bedeutet, dass Sie den betrieblichen Umfang übernehmen, den ein verwalteter Dienst abstrahiert: Kernel-Management, Root-Dateisystem-Governance, Ratenbegrenzung, Snapshot-Speicher, Bereinigungsrichtlinien und Multi-Tenant-Isolation. Siehe Firecracker für AI Agent Sandboxes für den praktischen Umfang dieser Aufgaben.

Was ist eine verwaltete AI Sandbox-Plattform?

Eine verwaltete AI Sandbox-Plattform ist ein Cloud-Dienst, der Sandbox-Infrastruktur als API bereitstellt: Sie rufen das SDK auf, eine Sandbox wird bereitgestellt und in einem bereiten Zustand zurückgegeben, und die Plattform kümmert sich um die zugrunde liegende Rechenleistung, Vernetzung, Image-Verwaltung und das Lebenszyklusmanagement. Novita Agent Sandbox, E2B und der verwaltete Modus von Daytona sind Beispiele. Die Alternative ist das Selbsthosting, bei dem Sie die Sandbox-Infrastruktur selbst bereitstellen und betreiben. Die Schlüsselfragen für jede verwaltete Plattform sind: Welches Isolationsmodell verwendet sie, welche Egress-Richtlinie ist konfigurierbar, ist BYOC- oder VPC-Bereitstellung verfügbar und wie sieht die Preisgestaltung pro Sekunde für Ihren erwarteten Workload aus? Siehe Die besten AI Agent Sandboxes 2026 für einen strukturierten Vergleich.

Was ist eine AI Agent Sandbox für den Unternehmenseinsatz?

Die Anforderungen an AI Agent Sandboxes für Unternehmen gehen typischerweise über das hinaus, was ein entwicklerorientierter verwalteter Dienst standardmäßig bietet. Häufige Anforderungen umfassen: BYOC- oder VPC-Bereitstellung (die Sandbox läuft in Ihrem Cloud-Konto, nicht in einem gemeinsam genutzten Drittanbieter-Mandanten); SOC 2- oder ISO 27001-Zertifizierung; konfigurierbare Egress-Richtlinie und Audit-Log-Export in ein SIEM; sitzungsbezogene Credential-Eingrenzung mit kurzlebigen Tokens; und Datenresidenzkontrollen, die einschränken, wo Agent-Workloads ausgeführt werden. Novita Agent Sandbox unterstützt die BYOC-Bereitstellung in Ihrer eigenen AWS- oder GCP-VPC, was die häufigsten Anforderungen an Datenresidenz und Netzwerkisolation im Unternehmen adressiert. Überprüfen Sie die aktuellen Compliance-Zertifizierungen und verfügbaren Konfigurationsoptionen in der Produktdokumentation, bevor Sie Architekturentscheidungen treffen.

---

Empfohlene Artikel

• Firecracker für AI Agent Sandboxes: Vorteile, Grenzen und Bewertungsfragen
• AI Agent Sandbox Preismodelle: Pro Sitzung, Rechenzeit, Speicher und Egress
• AI-Generated Code Sandbox: Anforderungen für Produktions-Apps