- Warum AI Agents sandboxen
- Sandbox-Isolationsmodelle
- Sandbox-Egress und Netzwerkrichtlinie
- Dateizugriff und das Host-Dateisystem
- Sitzungszustand und Persistenz
- Paketinstallationen und Laufzeitabhängigkeiten
- Secrets und Credential-Handling
- Audit-Logs und Beobachtbarkeit
- Compliance und Sicherheitsüberprüfung
- Sandbox-Preise und Kostenfaktoren
- Self-Hosting vs. verwaltete AI-Agent-Sandbox
- Nicht vertrauenswürdigen Code sicher ausführen
- Empfohlene Artikel
AI-Agent-Sandboxes isolieren generierten Code von Host-Systemen, aber die Details – wie Isolation funktioniert, welchen Netzwerkzugriff Agents haben, wohin Dateien gehen, wie Secrets behandelt werden – variieren erheblich zwischen den Implementierungen. Dieses FAQ fasst die häufigsten Fragen in einer Referenz zusammen, mit Verweisen auf die tiefergehenden Artikel in jedem Bereich. Wenn Sie neu bei Sandboxes sind, beginnen Sie mit Was ist eine AI-Agent-Sandbox? für eine Grundlage zu Isolationsmodellen, Egress und Snapshotting. Wenn Sie einen Anbieter auswählen, lesen Sie Beste AI-Agent-Sandboxes 2026 oder den E2B-vs.-Daytona-Bewertungsleitfaden.
Warum AI Agents sandboxen
Warum verwenden Teams eine dedizierte Sandbox für AI Agents?
AI Agents 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 überprüft. Ein LLM generiert Anweisungen, wählt Werkzeuge 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-Durchsetzungsschicht, die die Konsequenzen dieser Aktionen eindämmt, ohne dass jede mögliche Aktion vorab genehmigt werden muss. Ohne eine Sandbox kann ein fehlverhaltender oder manipulierter Agent das Host-System, benachbarte Workloads oder 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 von AI Agents?
Die Codeausführung von AI Agents 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 standardmäßige Infrastrukturschicht für diese Ausführungsphase: Sie stellt die Rechen-, Dateisystem- und 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 davon, einen Agenten einfach in einem Container auszuführen?
Ein Container fügt eine Dateisystem- und Netzwerk-Namespace-Trennung hinzu, aber alle Container auf demselben Host teilen sich den OS-Kernel. Bei AI Agents, die LLM-generierten Code aus nicht vertrauenswürdigen Eingaben ausführen, könnte ein Kernel-Level-Escape durch eine gemeinsame Sicherheitslücke benachbarte Workloads beeinträchtigen. Eine dedizierte AI-Agent-Sandbox fügt typischerweise eine MicroVM-Grenze hinzu: Der Code des Agents läuft in einer leichtgewichtigen virtuellen Maschine mit einem eigenen Gast-Kernel, sodass selbst ein Kernel-Level-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 der Sandbox 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 Agents 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-Level-Isolation verwendet OS-Primitive (Namespaces, cgroups, seccomp), um Systemaufrufe und Ressourcenzugriff einzuschränken; Container-Isolation fügt eine Dateisystem- und Netzwerk-Namespace-Grenze hinzu; und MicroVM-Isolation umschließt die Workload in einer leichtgewichtigen virtuellen Maschine mit einem eigenen Gast-Kernel. Jede Stufe im Stack erhöht die Grenzstärke auf Kosten eines gewissen Start-Overheads 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.
Ist Docker ausreichend, um agentengenerierten Code auszuführen?
Container bieten wiederholbare Images und gute Ressourcenkontrollen, aber alle Container auf demselben Host teilen sich den Host-Kernel. Eine Kernel-Sicherheitslücke oder ein Systemaufruf, 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 bei korrekter Härtung oft ausreichend – kein privilegierter Modus, minimale Capabilities, kein eingehängter Docker-Socket, read-only Root-Dateisystem wo möglich. Für nicht vertrauenswürdigen AI-generierten Code, der Pakete installieren, Unterprozesse 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-generierter Code-Sandbox: Anforderungen für Produktions-Apps für die Überprüfungsliste auf jeder Isolationsstufe.
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 schnell ausgelegt, das Gerätemodell ist minimal, um die Angriffsfläche zu reduzieren, und der Gast ist konstruktionsbedingt vom Host-Kernel isoliert. Die praktische Auswirkung ist, dass ein Kernel-Exploit im Gast nicht automatisch den Host oder andere Gäste beeinträchtigt, während dies in einem Shared-Kernel-Container-Modell möglich wäre. Siehe Firecracker für AI-Agent-Sandboxes für Informationen, wo die MicroVM-Grenze hilft und wo sie nicht das gesamte Problem löst.
Gibt es 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 über Benutzer oder über nicht zusammenhängende Aufgaben hinweg ist die häufigste Quelle für State-Leaks in Produktions-Agent-Apps. Wenn Sie eine Plattform bewerten, verifizieren Sie, dass gleichzeitige Sitzungen auf Dateisystem-, Prozess- und Netzwerkebene isoliert sind, nicht nur auf der API-Routing-Ebene. Siehe AI-generierter Code-Sandbox: Anforderungen für Produktions-Apps für die Checkliste zur Sitzungs-isolation.
Sandbox-Egress und Netzwerkrichtlinie
Kann ein AI Agent ausgehende Netzwerkaufrufe aus einer Sandbox tätigen?
Das hängt von der Egress-Richtlinie der Sandbox ab. Standardmäßig erlauben viele Sandboxes ausgehende Verbindungen, was für Web-Recherche, API-Aufrufe und Paketinstallationen praktisch 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 verweigernder Egress mit einer expliziten Allowlist erlaubter Ziele. Welche Richtlinie Sie auch wählen, sie sollte explizit und protokolliert sein. Siehe Firecracker für AI-Agent-Sandboxes für Informationen zur 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 ausspähen 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 Verweis auf einen internen Resolver, der die Allowlist respektiert, oder durch Einschränkung der Auflösung auf genehmigte Domains. Verifizieren Sie mit Ihrem Sandbox-Anbieter, wie DNS in Bezug auf die allgemeine Egress-Richtlinie abgegrenzt ist.
Wie werden Paketabrufe während netzwerkbeschränkten Sitzungen kontrolliert?
Paketinstallationen sind Netzwerkoperationen. Wenn der Egress auf eine Allowlist beschränkt ist, muss die Allowlist die Paketregistries enthalten, die der Agent legitim 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 weitere Informationen zur Steuerung von Laufzeitinstallationen.
Dateizugriff und das Host-Dateisystem
Auf welchen Dateizugriff hat ein gesandboxten Agent?
Ein gesandboxten Agent sollte nur Zugriff auf die Dateien haben, die explizit in seinen Arbeitsbereich eingehängt 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, auf das Host-Dateisystem, die Arbeitsbereiche anderer Mandanten, die Secrets des Anwendungsservers oder Systemverzeichnisse außerhalb seiner eingehängten Pfade zuzugreifen. Gute Praxis ist es, Quellmaterial schreibgeschützt einzuhängen und ein separates beschreibbares Ausgabeverzeichnis für generierte Artefakte bereitzustellen. Siehe MCP-Server-Sandbox: Isolierte MCP-Server mit Dateisystem-, Secrets- und Netzwerkkontrollen für Informationen zur 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 Agents 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 Einhängen breiter Verzeichnisse (wie das Home-Verzeichnis eines Entwicklers oder /), die Verwendung des privilegierten Modus in Containern oder das Einhängen des Docker-Sockets in die Sandbox. Wenn Sie eine Plattform bewerten oder Ihre eigene bauen, verifizieren Sie, was eingehängt 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 endet. Dies ist die richtige Voreinstellung für Code-Vervollständigung, Evaluierungsläufe und alle Aufgaben, bei denen Reproduzierbarkeit wichtiger ist als Kontinuität. Bei persistenten Arbeitsbereichen (langlaufende Coding-Agents, iterative Entwicklungssitzungen) können Dateien über Ausführungsaufrufe innerhalb einer Sitzung hinweg überleben und nach dem Ende der Sitzung beibehalten werden, wenn die Plattform Arbeitsbereichspersistenz 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 dem eines anderen durchsickern? Siehe AI-generierter Code-Sandbox: Anforderungen für Produktions-Apps für die Checkliste zum Persistenzmodell.
Sitzungszustand und Persistenz
Ist eine Sandbox-Sitzung zustandsbehaftet oder ephemer?
Beide Muster existieren und dienen unterschiedlichen Workloads. Ephemere Sitzungen beginnen für jede Aufgabe von einer sauberen Basislinie – keine angesammelten Pakete, Dateien oder Verlauf. Sie sind einfacher 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-Agents, 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 Mandantenisolation 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 (üblicherweise 60 Minuten bis 24 Stunden), nach dem die Sitzung beendet und der Zustand verloren ist, sofern er nicht in einem Snapshot oder externen Speicher persistiert wurde. Langlaufende Agent-Workflows – Sitzungen, die zwischen LLM-Aufrufen für Minuten oder Stunden pausieren können – benötigen eine Plattform, die Sitzungspause und -wiederaufnahme oder Autopause unterstützt, um Abrechnung für Leerlaufzeit zu vermeiden und gleichzeitig den Zustand zu bewahren. Verifizieren 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 wieder aufgenommen werden?
Einige Plattformen unterstützen Pause und Wiederaufnahme, bei denen die Sitzung auf die Festplatte ausgelagert und später vom selben Zustand aus neu gestartet werden kann. Dies ist nützlich für Agents, die zwischen Schritten auf LLM-Antworten warten, für die Ratenbegrenzung teurer Workloads und für Sitzungen, die sich über mehrere Benutzerinteraktionen erstrecken. Die wichtigsten Punkte, die zu überprüfen sind: Wie lange kann eine pausierte Sitzung ausgelagert bleiben, was passiert mit Netzwerkverbindungen, die während einer Pause gehalten werden, und bleiben die zu Sitzungsbeginn injizierten Anmeldeinformationen nach der Wiederaufnahme 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, Werkzeuge, genehmigte Pakete – von der aus neue Sitzungen starten. 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 Agents von einer konsistenten, geregelten Basislinie aus starten. 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 Agents Pakete zur Laufzeit installieren?
Die meisten Sandbox-Umgebungen erlauben standardmäßig Laufzeit-Paketinstallationen (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 sind eine der 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 regeln Laufzeit-Paketinstallationen?
Eine Produktions-Paketrichtlinie umfasst typischerweise eine Kombination aus Registry-Allowlisting (nur von genehmigten Paketregistern oder Spiegeln 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, deaktivieren). 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 gesandboxten Python und kontrolliertem Paketzugriff für ein praktisches Implementierungsbeispiel.
Secrets und Credential-Handling
Wie werden Secrets und Anmeldeinformationen in einer Sandbox gehandhabt?
Secrets sollten eng injiziert werden – nur die Anmeldeinformationen, die eine bestimmte Aufgabe benötigt, für die Dauer dieser Sitzung. Das häufige Antipattern ist das Einhängen einer breiten Umgebungsdatei mit allen API-Schlüsseln in jede Sitzung; das bedeutet, dass jede Sitzung, wenn sie kompromittiert wird, auf jede Anmeldeinformation in dieser Datei zugreifen kann. Bevorzugen Sie kurzlebige Token, die auf die Aufgabe beschränkt sind, und bevorzugen Sie Injektionsmechanismen (Umgebungsvariablen oder eingehängte Dateien) gegenüber Hardcoding. Für die sensibelsten Anmeldeinformationen bietet eine Laufzeit-Secrets-API, die Werte nur an einen explizit autorisierten Prozess liefert, 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 ähnlichem lesen. Deshalb ist ein enger Geltungsbereich wichtig: Injizieren Sie nur die Anmeldeinformationen, die die Aufgabe benötigt, und bevorzugen Sie kurzlebige Token, damit ein durchgesickertes Credential nur ein begrenztes Zeitfenster der Nützlichkeit hat. Schwärzung ist eine Anwendungsverantwortung: Protokollieren Sie nicht standardmäßig die gesamte Standardausgabe, wenn Secrets in Fehlermeldungen oder Print-Anweisungen erscheinen könnten.
Was passiert mit Secrets, wenn eine Sitzung endet?
Umgebungsvariablen und eingehängte Secret-Dateien sollten als Teil des Sitzungsabbaus bereinigt werden. Wenn die Plattform den Zustand über Sitzungen hinweg bewahrt (Snapshots, persistente Volumes), verifizieren Sie, dass Anmeldeinformationen, die auf das Dateisystem geschrieben oder von einem Credential-Provider zwischengespeichert wurden, ebenfalls bereinigt oder rotiert werden. Veraltete Anmeldeinformationen in einem wiederaufnehmbaren Snapshot sind ein Risiko – nach dem Sitzungsabbau sollte der Snapshot keine Token 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 es, 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 in der Regel 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 für 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-Pfad manipulationssicher sein, für den erforderlichen Zeitraum aufbewahrt werden und autorisierten Prüfern (Sicherheitsteam, Compliance-Beauftragter) auf Anfrage zugänglich sein. Fragen Sie Ihren Sandbox-Anbieter, welcher Log-Aufbewahrungszeitraum standardmäßig bereitgestellt wird, ob Logs in Ihr eigenes SIEM oder Ihren eigenen Speicher exportiert werden können und welche Zugriffskontrollen die Log-Daten schützen.
Compliance und Sicherheitsüberprüfung
Welche Compliance-Überprüfung ist erforderlich, bevor eine Sandbox in der Produktion eingesetzt wird?
Die spezifischen Anforderungen hängen von Ihrer Branche und Gerichtsbarkeit ab, aber die Standardfragen für jedes Produktions-Agent-System umfassen: Welche Daten gelangen in die Sandbox (und unterliegen diese Daten der 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 Anmeldeinformationen verwaltet und rotiert, und wie sieht der Audit-Pfad aus? Die meisten Sicherheitsüberprüfungen werden auch fragen, ob generierter Code Produktionsdatenbanken, interne Administrationsoberflächen oder Kundendaten außerhalb des beabsichtigten Umfangs erreichen könnte. Dies sind architektonische Kontrollen, nicht nur Anbieterzertifizierungen.
Welche Fragen sollten Sicherheitsteams bei der Bewertung einer AI-Agent-Sandbox stellen?
Eine praktische Bewertungscheckliste 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 Anmeldeinformationen injiziert? Sind sie auf die Aufgabe beschränkt? Werden sie beim Sitzungsabbau bereinigt?
- Audit: Welche Ereignisse werden protokolliert? Wer kann auf Logs zugreifen? Wie ist der Aufbewahrungszeitraum?
- 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 ist ihr Shared-Responsibility-Modell?
- Netzwerkreichweite: Kann eine Sandbox interne Metadaten-Dienste, private APIs oder Ressourcen anderer Mandanten erreichen? Wie wird laterale Bewegung verhindert?
Betrachten Sie diese als Fragen zur Bewertung, nicht als Anforderungen, die ein einzelner Anbieter automatisch erfüllt. Sicherheits- und Compliance-Angaben in der Anbieterdokumentation sollten anhand der aktuellen Produktdokumentation überprüft werden und nicht für bare Münze genommen werden. Für Teams mit regulatorischen oder vertraglichen Anforderungen lassen Sie die Überprüfung von Ihrem Sicherheitsteam vor der Produktionsbereitstellung durchführen, nicht danach.
Wann ist BYOC (Bring Your Own Cloud) oder VPC-Bereitstellung relevant?
Anforderungen an die Datenresidenz, Netzwerksicherheitsrichtlinien oder regulatorische Einschränkungen, die es verbieten, dass Daten ein bestimmtes Cloud-Konto verlassen, sind die Hauptgründe, warum Teams BYOC oder VPC-Bereitstellung gegenüber einem gemeinsam genutzten verwalteten Dienst wählen. 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 geregelt werden kann. Der Kompromiss ist die betriebliche Verantwortung: Sie sind für das Infrastrukturmanagement, Patchen und Skalieren zuständig. 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 setzen sich typischerweise aus Rechenzeit (vCPU und Speicher, abgerechnet pro Sekunde oder Minute), Sitzungs-Overhead (eine Startgebühr pro Sitzung auf einigen Plattformen), persistentem Speicher über dem kostenlosen Kontingent hinaus und ausgehendem Datentransfer (Egress) zusammen. Die relative Gewichtung hängt von Ihrem Workload ab: Ein Kurzzeit-Code-Interpreter ist hauptsächlich Rechenzeit; ein Browser-Automatisierungs-Agent, der große Dateien herunterlädt, kann erheblichen Egress verursachen; ein persistenter Coding-Arbeitsbereich wird Speicher ansammeln. Die Handhabung von Leerlaufzeiten ist ein wesentliches Unterscheidungsmerkmal – Plattformen mit Autopause beenden die Abrechnung, wenn eine Sandbox auf eine LLM-Antwort wartet, was die Kosten für interaktive Workloads 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?
Für die meisten Workloads dominiert die Rechenzeit. Eine 10-minütige Coding-Sitzung auf 1 vCPU kostet bei typischen Tarifen mehr als 1 GB Egress. Aber die Interaktion ist für bestimmte Workloads wichtig: Ein Daten-Agent, der einen großen Trainingsdatensatz herunterlädt, verursacht 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 gegen Ihr tatsächliches Workload-Profil zu schätzen, bevor Sie sich für eine Plattform entscheiden. Novita Agent Sandbox berechnet pro Sekunde basierend auf tatsächlicher vCPU- und Speichernutzung ohne Startgebühr pro Sitzung; Stand Mitte 2026 wird 1 vCPU mit $0,0000098/s abgerechnet. (Quelle: Novita AI Preisseite, verifiziert in der veröffentlichten Dokumentation. Überprüfen Sie immer die aktuellen Tarife vor der Budgetplanung.)
Self-Hosting vs. verwaltete AI-Agent-Sandbox
Wann sollten Teams selbst hosten anstatt eine verwaltete Sandbox zu verwenden?
Self-Hosting (Betreiben eigener Sandbox-Infrastruktur, oft auf Firecracker oder einer vergleichbaren MicroVM-Ebene) ist sinnvoll, wenn: Anforderungen an die Datenresidenz oder Netzwerkrichtlinien die Nutzung eines verwalteten Drittanbieterdienstes verbieten, das Workload-Volumen hoch genug ist, dass die Kosten des verwalteten Dienstes die Betriebskosten des Betriebs eigener 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 wünscht. Self-Hosting 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 Informationen zum betrieblichen Umfang.
Wann ist eine verwaltete Sandbox sinnvoller?
Für die meisten Teams, die Coding-Agents, Datenanalyse-Tools, Browser-Automatisierungs-Workflows oder Evaluierungspipelines erstellen, ist eine verwaltete Sandbox der schnellere Weg in die Produktion. Die Plattform übernimmt die Infrastrukturbereitstellung, Sicherheitshärtung, Image-Updates, Skalierung und das Lifecycle-Management. Das Team konzentriert sich auf die Agentenarchitektur, nicht auf die Sandbox-Interna. Der Kostenvergleich umfasst nicht nur die Cloud-Computing-Preise: 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 in der Regel schneller die Produktion und haben niedrigere Gesamtbetriebskosten. Siehe AI Agent Sandbox Preismodelle für einen Rahmen zum Vergleich der Gesamtkosten von verwalteten und selbst gehosteten Lösungen.
Welche Fragen sollten Teams bei der Bewertung verwalteter Sandbox-Anbieter stellen?
Praktische Bewertungsfragen über die Schlagzeilenpreise hinaus:
- Welches Isolationsmodell wird pro Sitzung verwendet (MicroVM, Container, Prozess)?
- Was ist die Standard- und konfigurierbare Egress-Richtlinie?
- Welche Optionen zur Governance von Paketinstallationen gibt es?
- Wie werden Secrets injiziert und bereinigt?
- Welche Audit-Log-Daten sind verfügbar und wie wird auf sie zugegriffen?
- Welche Sitzungslängen- und Parallelitätsbeschränkungen gelten auf Ihrer benötigten Stufe?
- Unterstützt der Anbieter BYOC oder VPC-Bereitstellung?
- Wie ist das Pause-/Wiederaufnahmeverhalten und wie wirkt es sich auf die Abrechnung aus?
- Wie verhält sich die Startlatenz im Maßstab (Warm Pool, Snapshot, Kaltstart)?
Nicht vertrauenswürdigen Code sicher ausführen
Wie führe ich AI-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 bedeutenden Unterschied: (1) Legen Sie die Egress-Richtlinie explizit fest – Standard-Deny mit einer Allowlist ist sicherer als Standard-Open; (2) Beschränken Sie Secrets eng – injizieren Sie nur die Anmeldeinformationen, die die aktuelle Aufgabe benötigt; (3) Kontrollieren 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) Setzen Sie Ressourcengrenzen – CPU, Speicher, Festplatte und Wanduhr-Timeout – sodass ein außer Kontrolle geratener Agent benachbarte Sitzungen nicht beeinträchtigen kann. Siehe Wie sicher ist die AI-Sandbox für die Codeausführung? für eine vollständige Bewertungscheckliste.
Gibt es eine Open-Source-AI-Agent-Sandbox?
Ja. Daytona ist Open Source unter einer AGPL-Lizenz und unterstützt die selbst gehostete Bereitstellung. Das Kern-SDK von E2B ist Open Source, obwohl die verwaltete Laufzeitinfrastruktur es nicht ist. Wenn Sie Ihre eigene Sandbox von Grund auf neu bauen möchten, ist der häufigste Ansatz Firecracker (von AWS entwickelt, Apache 2.0 lizenziert) als MicroVM-Laufzeit, kombiniert mit Ihrem eigenen Image-Management, Orchestrierung und Lifecycle-Control. Self-Hosting bedeutet, den betrieblichen Umfang zu ü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 Informationen, wie dieser Umfang in der Praxis aussieht.
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 den Lifecycle. Novita Agent Sandbox, E2B und der verwaltete Modus von Daytona sind Beispiele. Die Alternative ist Self-Hosting, bei dem Sie die Sandbox-Infrastruktur selbst bereitstellen und betreiben. Die Schlüsselfragen für jede verwaltete Plattform sind: Welches Isolationsmodell wird verwendet, 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 Beste 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 in der Regel ü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 Token; und Datenresidenzkontrollen, die beschrä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 Unternehmensdatenresidenz und Netzwerkisolation erfüllt. Überprüfen Sie die aktuellen Compliance-Zertifizierungen und verfügbaren Konfigurationsoptionen in der Produktdokumentation, bevor Sie Architekturentscheidungen treffen.
