- Sandbox-Isolationsmodelle
- Sandbox-Ausgangsverkehr und Netzwerkrichtlinie
- Dateizugriff und das Host-Dateisystem
- Sitzungszustand und Persistenz
- Paketinstallationen und Laufzeitabhängigkeiten
- Geheimnisse und Umgang mit Anmeldeinformationen
- Prüfprotokolle und Beobachtbarkeit
- Compliance und Sicherheitsüberprüfung
- Sandbox-Preise und Kostentreiber
- Self-Hosting vs. verwaltete KI-Agenten-Sandbox
- Empfohlene Artikel
Sandbox-Isolationsmodelle
Was bedeutet „Isolation“ in einer KI-Agenten-Sandbox?
Isolation bedeutet, dass der Code, die Dateien, 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 Betriebssystem-Primitiven (Namespaces, cgroups, seccomp), um Systemaufrufe und Ressourcenzugriff einzuschränken; Container-Isolation fügt eine Dateisystem- und Netzwerk-Namespace-Grenze hinzu; und MicroVM-Isolation kapselt die Arbeitslast in einer leichtgewichtigen virtuellen Maschine mit eigenem Gast-Kernel. Jede Erhöhung der Stufe verstärkt die Grenze, allerdings mit etwas zusätzlichem Start-Overhead und betrieblicher Komplexität. Siehe Firecracker für KI-Agenten-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 Systemaufruf, der durch den seccomp-Filter schlüpft, kann andere Arbeitslasten beeinträchtigen. Für risikoarme, kurzlebige Aufgaben mit vertrauenswürdigem oder nahezu vertrauenswürdigem Code sind Container bei korrekter Härtung oft ausreichend – 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, Unterprozesse starten oder beliebige Shell-Befehle ausführen kann, lohnt sich die Evaluierung einer stärkeren Grenze. Die Antwort hängt von Ihrem tatsächlichen Bedrohungsmodell ab. Siehe KI-generierte Code-Sandbox: Anforderungen für Produktions-Apps für die Überprüfungs-Checkliste 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 eigenen Gast-Kernel in einer leichtgewichtigen virtuellen Maschine, unterstützt durch Hardware-Virtualisierung (KVM). Eine MicroVM-basierte Sandbox, die Technologien wie Firecracker verwendet, bietet eine VM-artige Grenze ohne den vollständigen Overhead einer traditionellen VM: Die Startlatenz ist schnell, das Gerätemodell ist minimal, um die Angriffsfläche zu reduzieren, und der Gast ist 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 KI-Agenten-Sandboxes für eine Einordnung, 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 dem Anwendungsdesign ab. 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 Anmeldeinformationsbereich hat. Die gemeinsame Nutzung einer Sandbox über Benutzer oder über nicht zusammenhängende Aufgaben hinweg ist die häufigste Ursache für Zustandslecks in produktiven Agenten-Apps. Wenn Sie eine Plattform bewerten, stellen Sie sicher, dass gleichzeitige Sitzungen auf Dateisystem-, Prozess- und Netzwerkebene isoliert sind, nicht nur auf der API-Routing-Ebene. Siehe KI-generierte Code-Sandbox: Anforderungen für Produktions-Apps für die Checkliste zur Sitzungsisolation.
Sandbox-Ausgangsverkehr und Netzwerkrichtlinie
Kann ein KI-Agent ausgehende Netzwerkaufrufe aus einer Sandbox tätigen?
Das hängt von der Ausgangsrichtlinie 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 Ausgang ein Risiko: Ein kompromittierter oder fehlfunktionierender Agent kann Daten exfiltrieren, interne Metadaten-Dienste erreichen oder unerwarteten Code von beliebigen URLs abrufen. Eine stärkere Produktionshaltung ist ein standardmäßig verweigernder Ausgang mit einer expliziten Positivliste erlaubter Ziele. Unabhängig von Ihrer gewählten Richtlinie sollte sie explizit und protokolliert sein. Siehe Firecracker für KI-Agenten-Sandboxes für die Bewertung von Netzwerkkontrollen.
Wie wird DNS in einer Sandbox kontrolliert?
DNS ist eine häufige Lücke in der Ausgangsrichtlinie: Eine Positivliste 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 Ausgangsrichtlinie sollte die DNS-Auflösung konsistent erfolgen – entweder durch einen internen Resolver, der die Positivliste respektiert, oder durch Einschränkung der Auflösung auf genehmigte Domains. Fragen Sie Ihren Sandbox-Anbieter, wie DNS im Verhältnis zur allgemeinen Ausgangsrichtlinie abgegrenzt wird.
Wie werden Paketabrufe während netzwerkeingeschränkten Sitzungen kontrolliert?
Paketinstallationen sind Netzwerkoperationen. Wenn der Ausgang auf eine Positivliste beschränkt ist, muss die Positivliste die Paketregister 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 bietet den zusätzlichen Vorteil, als Inspektionspunkt zu dienen: Sie können sehen, welche Pakete abgerufen werden, unerwartete Abhängigkeiten erkennen und redundante Ausgänge reduzieren. Einige Teams verwenden vorgefertigte Sandbox-Vorlagen für Workloads, bei denen Reproduzierbarkeit wichtiger ist als Flexibilität, wodurch Laufzeit-Paketabrufe vollständig entfallen. Siehe den Abschnitt Paketinstallationen für weitere Informationen zur Steuerung von Laufzeitinstallationen.
Dateizugriff und das Host-Dateisystem
Auf welche Dateien hat ein sandboxierter Agent Zugriff?
Ein sandboxierter Agent sollte nur Zugriff auf die Dateien haben, die explizit in seinen Arbeitsbereich eingehängt wurden. Für einen Codierungsagenten könnte das ein ausgechecktes Repository und ein Arbeitsverzeichnis für generierte Artefakte sein. Für einen Datenanalyse-Agenten 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 Geheimnisse des Anwendungsservers oder Systemverzeichnisse außerhalb seiner eingehängten Pfade zuzugreifen. Gute Praxis ist es, Quellmaterial schreibgeschützt einzuhängen und ein separates Lese-/Schreib-Ausgabeverzeichnis für generierte Artefakte bereitzustellen. Siehe MCP-Server-Sandbox: Isolierte MCP-Server mit Dateisystem-, Geheimnis- und Netzwerkkontrollen für die Abgrenzung von Dateisystem-Mounts pro Werkzeug.
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 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, überprüfen 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, nachdem eine Sitzung endet?
Bei flüchtigen Sitzungen werden das Arbeitsverzeichnis und alle generierten Dateien gelöscht, wenn die Sitzung beendet wird. Dies ist die richtige Voreinstellung für Code-Vervollständigung, Evaluierungsläufe und alle Aufgaben, bei denen Reproduzierbarkeit wichtiger ist als Kontinuität. Für persistente Arbeitsbereiche (längere Codierungsagenten, iterative Entwicklungssitzungen) können Dateien über Ausführungsaufrufe innerhalb einer Sitzung hinweg erhalten bleiben und nach dem Ende der Sitzung weiterhin verfügbar sein, wenn die Plattform Arbeitsbereich-Persistenz oder Snapshots unterstützt. Die wichtigsten Fragen sind: Wem gehört ein beibehaltener Arbeitsbereich, wann wird er bereinigt und kann der Arbeitsbereich eines Benutzers in den eines anderen überlaufen? Siehe KI-generierte Code-Sandbox: Anforderungen für Produktions-Apps für die Checkliste zum Persistenzmodell.
Sitzungszustand und Persistenz
Ist eine Sandbox-Sitzung zustandsbehaftet oder flüchtig?
Beide Muster existieren und dienen unterschiedlichen Workloads. Flüchtige Sitzungen beginnen für jede Aufgabe mit einer sauberen Basis – keine akkumulierten Pakete, Dateien oder Verlaufsdaten. Sie sind einfacher zu durchschauen und ideal für Evaluierungsläufe oder einmalige Code-Ausführungen. Zustandsbehaftete Sitzungen bewahren Dateien, installierte Pakete, Shell-Verlauf und Umgebungszustand über mehrere Ausführungsaufrufe hinweg, was für mehrstufige Codierungsagenten, interaktive Datenanalyse und langlaufende Workflows erforderlich ist. Die meisten Produktionsplattformen unterstützen beides. Der Nachteil 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 Tarif. Einige Anbieter legen ein Standard-Sitzungs-Timeout fest (üblich sind 60 Minuten bis 24 Stunden), nach dem die Sitzung beendet und der Zustand verloren geht, sofern er nicht in einem Snapshot oder einem externen Speicher persistiert wird. Langlaufende Agenten-Workflows – Sitzungen, die zwischen LLM-Aufrufen minuten- oder stundenlang pausieren können – benötigen eine Plattform, die Sitzungspause und -fortsetzung oder eine automatische Pause 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 auftritt. Die Novita Agent Sandbox unterstützt Sitzungen von bis zu 24 Stunden und dokumentiert eine Pause-/Auto-Resume-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 denen 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 sich über mehrere Benutzerinteraktionen erstrecken. Die wichtigsten Überprüfungspunkte sind: Wie lange kann eine pausierte Sitzung im ausgelagerten Zustand bleiben, was passiert mit Netzwerkverbindungen, die während der Pause gehalten werden, und ob Anmeldeinformationen, die zu Sitzungsbeginn injiziert wurden, nach der Fortsetzung noch gültig sind oder aktualisiert werden müssen.
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 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 Basis ausgehen. Snapshots sind nützlich, um Teilarbeiten zu bewahren oder iterative Jobs vorzuwärmen. 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 Pakete zur Laufzeit installieren?
Die meisten Sandbox-Umgebungen erlauben standardmäßig Laufzeit-Paketinstallationen (pip install, npm install, apt-get usw.), da viele Agenten-Workloads dies 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 steuern Laufzeit-Paketinstallationen?
Eine Produktions-Paketrichtlinie umfasst typischerweise eine Kombination aus Positivliste für Register (nur von genehmigten Paketregistern oder Spiegelservern abrufen), Pull-Through-Caches (prüfen, was eintritt, bevor es ausgeführt wird), Installationsprotokollierung (Paketnamen, Version, Quelle und Ergebnis für jede Installation aufzeichnen) und optionalem Offline-Modus (Abhängigkeiten in die Vorlage einbetten und Laufzeitinstallationen für Evaluierungspipelines deaktivieren, bei denen Reproduzierbarkeit wichtig ist). Die richtige Richtlinie hängt vom Workload ab: Ein Codierungsagent, 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 eines KI-Datenanalysten mit sandboxiertem Python und kontrolliertem Paketzugriff für ein praktisches Implementierungsbeispiel.
Geheimnisse und Umgang mit Anmeldeinformationen
Wie werden Geheimnisse und Anmeldeinformationen in einer Sandbox gehandhabt?
Geheimnisse sollten eng injiziert werden – nur die Anmeldeinformationen, die eine bestimmte Aufgabe benötigt, für die Dauer dieser Sitzung. Das häufige Anti-Pattern ist das Einbinden einer breiten Umgebungsdatei mit allen API-Schlüsseln in jede Sitzung; dies bedeutet, dass jede kompromittierte Sitzung auf alle Anmeldeinformationen in dieser Datei zugreifen kann. Bevorzugen Sie kurzlebige Tokens, die auf die Aufgabe zugeschnitten sind, und bevorzugen Sie Injektionsmechanismen (Umgebungsvariablen oder eingehängte Dateien) gegenüber dem Hartcodieren. Für die sensibelsten Anmeldeinformationen bietet eine Laufzeit-Geheimnis-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 werden?
Ja, wenn die Umgebungsvariable in den Prozess injiziert wird, in dem der Code des Modells ausgeführt wird. 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 erfordert, und bevorzugen Sie kurzlebige Tokens, sodass ein durchgesickertes Geheimnis nur ein begrenztes Nutzungsfenster hat. Schwärzung ist eine Verantwortung der Anwendung: Protokollieren Sie die vollständige Standardausgabe nicht standardmäßig, wenn Geheimnisse in Fehlermeldungen oder Print-Anweisungen erscheinen könnten.
Was passiert mit Geheimnissen, wenn eine Sitzung endet?
Umgebungsvariablen und eingehängte Geheimnisdateien sollten als Teil des Sitzungsabbaus bereinigt werden. Wenn die Plattform den Zustand über Sitzungen hinweg bewahrt (Snapshots, persistente Volumes), überprüfen Sie, ob Anmeldeinformationen, die auf das Dateisystem geschrieben oder von einem Anmeldeinformationsanbieter zwischengespeichert wurden, ebenfalls bereinigt oder rotiert werden. Veraltete Anmeldeinformationen in einem wiederaufnehmbaren Snapshot sind ein Risiko – nach dem Sitzungsabbau sollte der Snapshot keine Tokens enthalten, die nur für die ursprüngliche Sitzungsdauer gültig waren.
Prüfprotokolle und Beobachtbarkeit
Welche Ereignisse werden in einer Sandbox protokolliert?
Nützliche Sandbox-Prüfdatensätze umfassen Sitzungserstellung und -abbau (Sitzungs-ID, Mandant, Vorlagenversion, Ressourcenzuweisung, Dauer), Ausführungsereignisse (welche Code- oder Befehlskategorie ausgeführt wurde, Start-/Endzeit, Exit-Status), Paketinstallationen (Name, Version, Quelle, Ergebnis), ausgehende Netzwerkkontakte (Domains, IPs, Ports), gelesene oder geschriebene Dateien von bestimmten Pfaden und das Bereinigungsergebnis. Das Ziel ist es, das Agentenverhalten im Nachhinein rekonstruierbar zu machen, ohne das Prüfprotokoll in einen zweiten Geheimnisspeicher zu verwandeln. Rohe Kundendateien, vollständige Befehlsausgaben und vollständige Prompts gehören im Allgemeinen nicht in Prüfprotokolle, es sei denn, Ihre Aufbewahrungs- und Zugriffskontrollen sind speziell für diese Daten ausgelegt.
Wer kann auf Prüfprotokolle zugreifen?
Zugriffskontrollen auf Prüfprotokolle sollten auf den Betreiber und, wo relevant, den Mandanten beschränkt sein. In Multi-Tenant-Plattformen sollten die Prüfdatensätze eines Mandanten für andere Mandanten nicht sichtbar sein. Für compliance-sensible Bereitstellungen muss die Prüfspur 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 Protokollaufbewahrungszeitraum standardmäßig bereitgestellt wird, ob Protokolle in Ihr eigenes SIEM oder Ihren eigenen Speicher exportiert werden können und welche Zugriffskontrollen die Protokolldaten 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 Ihrem Rechtsraum ab, aber die Standardfragen für jedes Produktions-Agenten-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 den Datenaufenthaltsort, wie ist das Isolationsmodell und kann es einem Prüfer dokumentiert werden, wie werden Anmeldeinformationen verwaltet und rotiert, und wie sieht die Prüfspur 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 Zertifizierungen des Anbieters.
Welche Fragen sollten Sicherheitsteams bei der Bewertung einer KI-Agenten-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?
- Ausgang: Was ist die standardmäßige Ausgangsrichtlinie? Können ausgehende Ziele auf eine Positivliste gesetzt werden? Wie wird DNS kontrolliert?
- Geheimnisse: Wie werden Anmeldeinformationen injiziert? Sind sie auf die Aufgabe beschränkt? Werden sie beim Sitzungsabbau bereinigt?
- Prüfung: Welche Ereignisse werden protokolliert? Wer kann auf die Protokolle zugreifen? Wie ist der Aufbewahrungszeitraum?
- Datenaufenthaltsort: Wo werden Sandboxes gehostet? Kann die Bereitstellung auf eine bestimmte Cloud-Region oder ein bestimmtes Konto beschränkt werden?
- Compliance-Position: 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?
Betrachten Sie diese als Fragen zur Bewertung und 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 lassen Sie die Überprüfung durch Ihr Sicherheitsteam vor der Produktionsbereitstellung durchführen, nicht danach.
Wann ist BYOC (Bring Your Own Cloud) oder VPC-Bereitstellung relevant?
Anforderungen an den Datenaufenthaltsort, Netzwerksicherheitsrichtlinien oder regulatorische Einschränkungen, die das Verlassen eines bestimmten Cloud-Kontos durch Daten verbieten, 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 Ausgang aus der Sandbox durch Ihre vorhandenen Netzwerkrichtlinien gesteuert werden kann. Der Kompromiss ist die betriebliche Verantwortung: Sie kümmern sich um die Infrastrukturverwaltung, Patches und Skalierung. Die 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 Kostentreiber
Was treibt die Sandbox-Kosten an?
Sandbox-Kosten setzen sich typischerweise aus Rechenzeit (vCPU und Speicher, abgerechnet pro Sekunde oder pro Minute), Sitzungsoverhead (eine Startgebühr pro Sitzung bei einigen Plattformen), persistentem Speicher oberhalb des enthaltenen kostenlosen Kontingents und ausgehendem Datentransfer (Egress) zusammen. Das relative Gewicht hängt von Ihrem Workload ab: Ein Kurzzeit-Code-Interpreter verbraucht hauptsächlich Rechenleistung; ein Browser-Automatisierungsagent, der große Dateien herunterlädt, kann erheblichen Egress verursachen; ein persistenter Codierungsarbeitsbereich wird Speicher ansammeln. Die Handhabung von Leerlaufzeiten ist ein wichtiges Unterscheidungsmerkmal – Plattformen mit automatischer Pause stellen die Abrechnung ein, wenn eine Sandbox auf eine LLM-Antwort wartet, was die Kosten für interaktive Workloads erheblich senken kann. Siehe KI-Agenten-Sandbox-Preismodelle: Pro Sitzung, Rechenleistung, Speicher und Egress für eine detaillierte Aufschlüsselung der einzelnen Preisdimensionen.
Wie interagieren Sitzungszeit, Rechenleistung und Egress bei den Kosten?
Für die meisten Workloads dominiert die Rechenzeit. Eine 10-minütige Codierungssitzung auf 1 vCPU kostet mehr als 1 GB Egress zu typischen Tarifen. Aber die Interaktion ist für bestimmte Workloads wichtig: Ein Datenagent, 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-Runden offen hält, sammelt Leerlauf-Rechenzeit an, wenn die automatische Pause nicht aktiviert ist. Der praktische Ansatz ist, jede Dimension gegen Ihr tatsächliches Workload-Profil abzuschätzen, bevor Sie sich für eine Plattform entscheiden. Die Novita Agent Sandbox rechnet pro Sekunde basierend auf der tatsächlichen vCPU- und Speichernutzung ab, ohne Startgebühr pro Sitzung; ab Mitte 2026 ist 1 vCPU mit $0,0000098/s bepreist. (Quelle: Novita AI Preisseite, überprüft in der veröffentlichten Dokumentation. Überprüfen Sie immer die aktuellen Tarife vor der Budgetplanung.)
Self-Hosting vs. verwaltete KI-Agenten-Sandbox
Wann sollten Teams selbst hosten anstatt eine verwaltete Sandbox zu nutzen?
Self-Hosting (Betreiben Ihrer eigenen Sandbox-Infrastruktur, oft auf Firecracker oder einer vergleichbaren MicroVM-Schicht) ist sinnvoll, wenn: Anforderungen an den Datenaufenthaltsort oder Netzwerksicherheitsrichtlinien die Nutzung eines verwalteten Drittanbieterdienstes verbieten, das Workload-Volumen hoch genug ist, dass die Kosten des verwalteten Dienstes die Betriebskosten für den Betrieb Ihrer eigenen Infrastruktur übersteigen, oder das Team über vorhandene 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, Ratelimitern, Metriken, Bereinigung und Multi-Tenant-Isolation ist echte Arbeit. Siehe Firecracker für KI-Agenten-Sandboxes für eine Beschreibung des betrieblichen Umfangs.
Wann ist eine verwaltete Sandbox sinnvoller?
Für die meisten Teams, die Codierungsagenten, Datenanalysewerkzeuge, Browser-Automatisierungs-Workflows oder Evaluierungspipelines entwickeln, ist eine verwaltete Sandbox der schnellere Weg in die Produktion. Die Plattform kümmert sich um die Bereitstellung der Infrastruktur, Sicherheitshärtung, Image-Updates, Skalierung und Lebenszyklusverwaltung. Das Team konzentriert sich auf die Agentenarchitektur, nicht auf die Sandbox-Interna. Der Kostenvergleich umfasst nicht nur Cloud-Computing-Tarife: Berücksichtigen Sie die Entwicklungszeit für den Aufbau und die Wartung der Isolationsschicht, die Compliance-Arbeit zur Dokumentation und die Reaktion auf Vorfälle, 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 KI-Agenten-Sandbox-Preismodelle für einen Rahmen zum Vergleich der Gesamtkosten von verwalteten und selbst gehosteten Lösungen.
Welche Fragen sollten Teams bei der Bewertung von verwalteten Sandbox-Anbietern stellen?
Praktische Evaluierungsfragen über die Schlagzeilenpreise hinaus:
- Wie ist das Isolationsmodell pro Sitzung (MicroVM, Container, Prozess)?
- Wie lautet die standardmäßige und konfigurierbare Ausgangsrichtlinie?
- Welche Optionen zur Steuerung von Paketinstallationen gibt es?
- Wie werden Geheimnisse injiziert und bereinigt?
- Welche Prüfprotokolldaten sind verfügbar und wie wird darauf zugegriffen?
- Welche Sitzungslängen- und Parallelitätsbeschränkungen gelten auf Ihrer benötigten Stufe?
- Unterstützt der Anbieter BYOC- oder VPC-Bereitstellung?
- Wie verhält sich die Pause-/Fortsetzungsfunktion und wie wirkt sie sich auf die Abrechnung aus?
- Wie verhält sich die Startlatenz bei Skalierung (Warm-Pool, Snapshot, Kaltstart)?
