Anforderungen an KI-Code-Sandboxen für Produktions-Apps

Produktions-Apps, die KI-generierten Code ausführen, benötigen eine Sandbox, die Prozessisolierung auf Betriebssystemebene erzwingt, nebenläufige Sitzungen unterstützt, eine programmierbare Lebenszyklus-API bereitstellt, beobachtbare Logs und Ressourcenmetriken liefert, Paket- und Netzwerkrichtlinien durchsetzt und sauber in das App-Backend integriert ist. Eine Sandbox auszuwählen, ohne jede dieser Dimensionen systematisch zu bewerten, ist der häufigste Grund, warum Teams nach dem Launch auf Probleme stoßen: Eine Workload, die in der Staging-Umgebung sicher aussah, versagt unter echtem Traffic, lässt Zustand zwischen Mandanten auslaufen oder führt stillschweigend Code aus, den die App nie zulassen wollte.

Dieser Leitfaden ist eine Anforderungscheckliste. Er behandelt, was auf jeder Isolierungsstufe zu prüfen ist, was eine Produktions-Lebenszyklus-API bieten muss, wie Beobachtbarkeit und Ressourcenkontrollen aussehen sollten und wo Backend-Integrationsmuster das Design entscheidend beeinflussen. Egal, ob Sie eine verwaltete Sandbox evaluieren oder Ihre eigene bauen – das sind die Fragen, die es wert sind, beantwortet zu werden, bevor Sie ausliefern.

Sandbox-Isolierung: Prozess, Container und MicroVM

Isolierung ist ein Spektrum, und jede Stufe bringt unterschiedliche Kompromisse bei Leistung, Portabilität und dem Vertrauen, das Sie generiertem Code entgegenbringen.

Prozessisolierung nutzt Betriebssystem-Primitive – Namespaces, cgroups, seccomp und AppArmor- oder SELinux-Profile – um den Zugriff eines Prozesses einzuschränken. Sie ist schnell und benötigt keinen separaten VM-Kernel, aber alle Prozesse teilen sich den Host-Kernel. Eine Kernel-Schwachstelle oder ein privilegierter Systemaufruf, der durch den seccomp-Filter schlüpft, kann andere Workloads auf demselben Host beeinträchtigen. Prozessisolierung ist ein vernünftiger Ausgangspunkt für risikoarme, kurzlebige, vertrauenswürdige Codepfade, aber sie ist eine dünne Grenze für nicht vertrauenswürdigen KI-Code, der möglicherweise Systemaufrufe, das Erzeugen von Unterprozessen oder Paketinstallationen versucht.

Was auf dieser Ebene zu prüfen ist:

• Welche Systemaufrufe sind blockiert, und was ist die Standardrichtlinie, wenn ein unbekannter Systemaufruf versucht wird?
• Sind Namespaces pro Aufgabe, pro Mandant oder gemeinsam für Aufgaben festgelegt?
• Werden cgroup-Grenzen auf Aufgabenebene oder nur auf Hostebene durchgesetzt?
• Bereinigt die Sandbox bei Beendigung alle Prozesse, temporären Dateien, Sockets und Shared Memory?

Containerisolierung fügt eine Dateisystem- und Netzwerk-Namespace-Grenze hinzu und macht Image-Management wiederholbar. Container starten schneller als vollständige VMs, sind einfacher zu komponieren und werden weitgehend von Orchestrierungsschichten unterstützt. Der Kompromiss ist, dass Container immer noch den Host-Kernel teilen, und die Containergrenze ist nur so stark wie die zugrundeliegende Runtime-Konfiguration. Privilegierte Container, breite Capability-Sets, eingehängte Host-Sockets und der Host-Netzwerkmodus reduzieren die effektive Grenze auf nahezu nichts.

Was auf dieser Ebene zu prüfen ist:

• Ist das Container-Image minimal, mit nur den Laufzeiten und Werkzeugen, die die Workload tatsächlich benötigt?
• Sind Capabilities auf das minimal benötigte Set reduziert?
• Ist der Container rootless, oder benötigt er root und welche Kontrollen gibt es dafür?
• Sind Host-PID-Namespace, Host-Netzwerk und der Docker-Socket explizit ausgeschlossen?
• Sind eingehängte Volumes auf explizit definierte Pfade beschränkt, und ist das Root-Dateisystem wo möglich schreibgeschützt?

MicroVM-Isolierung platziert jede Workload in einer leichtgewichtigen virtuellen Maschine – mit eigenem Gast-Kernel, virtuellen Geräten und einer KVM-gestützten Grenze zwischen Gast und Host. Technologien wie Firecracker verwenden ein minimales Gerätemodell, um die Angriffsfläche zu reduzieren, während die Startgeschwindigkeit für interaktive Nutzung ausreicht. Die MicroVM-Grenze bedeutet, dass ein Kernel-Exploit im Gast nicht automatisch den Host oder andere Gäste beeinträchtigt.

Was auf dieser Ebene zu prüfen ist:

• Erhält jeder Agentenlauf, jeder Mandant oder jede nebenläufige Sitzung eine eigene MicroVM?
• Wie hoch ist die Startlatenz vom API-Aufruf bis zur Ausführungsbereitschaft, und wird diese aus einem Warm-Pool, einem Snapshot oder einem Kaltstart gemessen?
• Sind Gast-Images versioniert, auf enthaltene Laufzeiten und Werkzeuge geprüft und werden regelmäßig aktualisiert?
• Was passiert auf Host-Ebene, wenn der Gast-Kernel einen Panic hat oder nicht mehr reagiert?

Die praktische Entscheidung hängt von Ihrem Bedrohungsmodell ab. MicroVM-Isolierung ist die stärkste allgemein verfügbare Grenze für nicht vertrauenswürdigen KI-Code, ersetzt aber nicht Dateisystemrichtlinien, Ausgangskontrollen, Paket-Governance oder die Handhabung von Geheimnissen. Diese Kontrollen müssen zusätzlich zur gewählten Isolierungsebene implementiert werden.

Verwalten nebenläufiger Sandbox-Sitzungen

Eine Produktions-App, die gleichzeitig Code für mehrere Benutzer generiert, benötigt eine Sandbox, die Parallelität als erstklassiges Anliegen behandelt, nicht als nachträglichen Einfall.

Die wichtigsten Fragen sind:

Pro-Sitzungs-Isolierung: Wenn 50 Sitzungen gleichzeitig laufen, hat jede Sitzung ihr eigenes isoliertes Dateisystem, ihre eigene Prozessstruktur, ihren eigenen Netzwerk-Namespace und ihren eigenen Credential-Bereich? Zustandslecks zwischen Sitzungen sind einer der schädlichsten Fehlermodi in mandantenfähigen Sandbox-Apps und oft in Tests unsichtbar, bei denen Sitzungen nacheinander ausgeführt werden.

Sitzungslimits und Backpressure: Macht die Sandbox Parallelitätsgrenzen als klaren API-Vertrag sichtbar? Wenn 500 Anfragen eintreffen und die Plattform 100 gleichzeitige Sitzungen unterstützt, gibt die API einen strukturierten Fehler zurück, stellt die Anfrage in die Warteschlange oder verschlechtert sich stillschweigend? Produktions-Apps benötigen dieses Signal, um Backpressure, Warteschlangenmanagement und benutzerseitiges Feedback zu implementieren.

Ressourcenfairness unter Last: Wenn eine Sitzung ungewöhnlich viel CPU oder Speicher verbraucht, werden andere Sitzungen durch pro-Sitzung-Ressourcengrenzen geschützt, oder kann eine laute Workload den gesamten Pool beeinträchtigen?

Warm-Pools und Startlatenz von Sitzungen: Interaktive Code-Funktionen benötigen Startzeiten von unter einer Sekunde. Das erfordert normalerweise einen Pool vorinitialisierter Umgebungen, die sofort beansprucht werden können, anstatt bei Bedarf gebootet zu werden. Überprüfen Sie, ob die Plattform die Verfügbarkeit von Warm-Pools dokumentiert und welche Startlatenz bei verschiedenen Parallelitätsstufen zu erwarten ist.

Wiederverwendung von Sitzungen vs. frische Umgebungen: Einige Apps profitieren von der Wiederverwendung einer langlebigen Sitzung über mehrere Agentenrunden, während andere für jede Anfrage eine saubere Umgebung benötigen. Überprüfen Sie, ob beide Muster unterstützt werden und ob die Wiederverwendung von Sitzungen keinen veralteten Zustand aus einer vorherigen Konversation überträgt.

Lebenszyklus-API: Erstellen, Ausführen, Beenden

Die Lebenszyklus-API ist die Schnittstelle zwischen Ihrer Anwendung und der Sandbox-Runtime. Eine produktionsreife API muss mindestens Folgendes bereitstellen:

Erstellen: Initialisieren einer neuen Sandbox-Sitzung, optional aus einer Vorlage oder einem Snapshot, mit festgelegten Ressourcengrenzen, Umgebungsvariablen und eingehängten Volumes. Die Antwort sollte eine Sitzungs-ID und ein Bereitschaftssignal enthalten, nicht nur eine Bestätigung.

Ausführen: Übermitteln von Code oder einem Befehl zur Ausführung. Dies sollte ein asynchroner Aufruf sein, der eine Ausführungs-ID zurückgibt. Die API muss die Angabe eines Arbeitsverzeichnisses, von Umgebungsüberschreibungen für den Aufruf und eines Timeouts unterstützen.

Streaming der Ausgabe: Abrufen von stdout und stderr als Stream, nicht nur als Endergebnis nach Abschluss der Ausführung. Streaming ist wichtig für langlaufende Jobs, Agentenschritte, die viele Sekunden dauern, und jede Benutzeroberfläche, die dem Benutzer inkrementellen Fortschritt anzeigt.

Beenden: Beenden einer laufenden Ausführung vor ihrem Abschluss. Die Sandbox sollte garantieren, dass der Prozessbaum bereinigt wird, nicht nur der Elternprozess.

Bereinigung: Zerstören der Sitzung und Freigeben aller zugeordneten Ressourcen – Dateisystem, Speicher, Prozessslots, Netzwerkstatus und alle gehaltenen Anmeldeinformationen. Dieser Aufruf sollte idempotent sein, sodass Wiederholungen nach einem Netzwerkfehler keine Fehler verursachen.

Hochladen und Herunterladen von Dateien: Übertragen von Eingabedateien in die Sandbox vor der Ausführung und Abrufen von Ausgabeartefakten nach der Ausführung. Dateiübertragungen sollten durch Größenbeschränkungen begrenzt und richtlinienkontrolliert sein, welche Pfade beschreibbar sind.

Zusätzliche Fähigkeiten, die für den Produktionseinsatz zu prüfen sind:

• Anhalten und Fortsetzen: Kann eine langlaufende Sitzung angehalten und später ohne Zustandsverlust fortgesetzt werden? Dies ist nützlich für Ratenbegrenzung, Kostenkontrolle und die Übergabe von Sitzungen zwischen Agentenrunden.
• Snapshot: Kann der aktuelle Sitzungszustand erfasst und als Ausgangspunkt für zukünftige Sitzungen verwendet werden? Dies ist der Schlüsselmechanismus für Warm-Pools und wiederverwendbare Umgebungen.
• Timeout-Durchsetzung: Wenn der ausgeführte Code das Wanduhrzeit-Timeout überschreitet, beendet die Plattform ihn sauber und meldet den richtigen Exit-Status?

Beobachtbarkeit: Logs, Metriken und Traces

Sie können nicht debuggen oder prüfen, was Sie nicht sehen können. Produktions-Sandboxes benötigen von Anfang an integrierte Beobachtbarkeit, nicht nachträglich hinzugefügt.

Stdout- und Stderr-Erfassung: Jede Ausführung sollte einen erfassten Ausgabedatensatz produzieren, der mit der Sitzungs-ID und der Ausführungs-ID verknüpft ist. Dies sollte nach Abschluss der Ausführung über die API zugänglich sein, nicht nur als Echtzeit-Stream verfügbar.

Ausführungslogs: Die Plattform sollte aufzeichnen, welcher Code wann lief, wann er startete, wann er endete, welcher Exit-Code vorlag, welcher Benutzer oder Mandant die Sitzung besaß und welche Vorlage oder welcher Snapshot verwendet wurde. Diese Aufzeichnungen sind das Minimum, das benötigt wird, um zu rekonstruieren, was passiert ist, wenn etwas schief geht.

Ressourcenmetriken: Produktions-Apps benötigen pro-Sitzung-Metriken für CPU-Auslastung, Speicherspitze, Wanduhrzeit und Dateisystem-Schreibvorgänge. Dies ermöglicht Kapazitätsplanung, Anomalieerkennung und pro-Sitzung-Kostenzuordnung.

Fehlerverfolgung: Wenn eine Sandbox nicht startet, ausführt oder bereinigt, sollte die Fehleroberfläche strukturiert sein: Fehlercode, Nachricht, Sitzungs-ID und genügend Kontext, um einen Benutzerfehler (schlechter Code, fehlendes Paket) von einem Plattformfehler (Kontingent überschritten, interner Fehler) zu unterscheiden.

Prüfpfad: Für mandantenfähige Apps sollte der Prüfpfad das Agentenverhalten rekonstruierbar machen: Sitzungs-ID, Mandant, Ausführungssequenz, Paketinstallationen, kontakierte externe Domänen, geschriebene Dateien und Bereinigungsergebnis. Roher Kunden-Code und vollständige Befehlsausgabe gehören standardmäßig möglicherweise nicht in Prüfpfade – gestalten Sie für das, was Ihre Aufbewahrungs- und Zugriffsrichtlinien tatsächlich unterstützen können.

Was zu vermeiden ist: Eine Sandbox, die nur „Ausführung fehlgeschlagen“ mit keinem strukturierten Fehler, keinen sitzungsbezogenen Logs und keiner Möglichkeit anzeigt, ein Timeout von einem OOM von einem Prozessfluchtversuch zu unterscheiden. Das zwingt Sie, alles auf Anwendungsebene zu instrumentieren, was Arbeit dupliziert und Ereignisse übersieht, die die Sandbox direkt beobachten kann.

CPU-, Speicher- und Timeout-Grenzen

Unbegrenzter Ressourcenverbrauch ist einer der einfachsten Wege, wie eine Sandbox-Workload in der Produktion Probleme verursachen kann – entweder durch Beeinträchtigung anderer Sitzungen oder durch unerwartete Infrastrukturkosten.

Eine Produktions-Sandbox muss Grenzen auf Sitzungsebene durchsetzen, nicht nur auf Hostebene:

CPU: Begrenzen Sie die CPU-Zeit, die eine einzelne Sitzung verbrauchen kann. Eine Sitzung, die eine Endlosschleife erzeugt, sollte andere Sitzungen auf demselben Host nicht beeinträchtigen. Überprüfen Sie, ob die Grenze eine harte Grenze (der Prozess wird gedrosselt oder getötet) oder eine weiche Grenze (er konkurriert mit anderen Prozessen um verfügbare CPU) ist.

Speicher: Setzen Sie eine Speicherobergrenze, die eine Bereinigung oder Beendigung auslöst, anstatt dass die Sitzung den Host-Speicher erschöpft. Überprüfen Sie, was passiert, wenn die Grenze erreicht wird: OOM-Kill, strukturierte Fehlerantwort oder stilles Hängen.

Wanduhrzeit-Timeout: Jeder Ausführungsaufruf sollte eine maximale Dauer haben. Das Timeout sollte auf Plattformebene durchsetzbar sein, nicht nur auf Clientebene – wenn der Client die Verbindung trennt, sollte die Sandbox die Ausführung dennoch zur konfigurierten Grenze beenden.

Festplattennutzung: Generierter Code kann große Ausgabedateien schreiben, große Pakete installieren oder das Arbeitsverzeichnis füllen. Ein Festplattenkontingent für das Sitzungs-Arbeitsverzeichnis verhindert unkontrollierte Schreibvorgänge.

Prozessanzahl: KI-generierter Code kann Unterprozesse, Hintergrundarbeiter oder Shell-Befehle erzeugen, die selbst weitere Prozesse starten. Eine Begrenzung der Gesamtzahl der Prozesse im Namensraum der Sitzung verhindert Forkbomben und außer Kontrolle geratene Unterprozessbäume.

Bei der Bewertung einer Sandbox-Plattform prüfen Sie, ob diese Grenzen pro Sitzung konfigurierbar sind (sodass verschiedene Benutzerstufen oder Aufgabentypen unterschiedliche Grenzen haben können), ob sie auf Sandbox-Ebene durchgesetzt werden und ob das Erreichen einer Grenze einen strukturierten API-Fehler oder einen stillen Fehler erzeugt.

Paketinstallationsrichtlinien

KI-generierter Code fordert häufig Paketinstallationen an – pip install, npm install, apt-get, Git-Klone, direkte URL-Aufrufe. Jeder dieser Vorgänge zieht externen Code zur Laufzeit in die Sandbox, was eines der risikoreichsten Operationen ist, die eine Sandbox steuern muss.

Eine Produktions-Paketrichtlinie sollte Folgendes abdecken:

Registry-Allowlists: Welche Paketregistrierungen sind erlaubt? PyPI und npm sind Standard, aber viele Teams möchten die Möglichkeit, auf interne Mirror, kuratierte Registrierungen oder explizit genehmigte Quellen zu beschränken.

Installations-Caching: Wenn viele Sitzungen dieselben beliebten Pakete installieren, vermeidet ein Layer-Cache oder Pull-Through-Proxy redundante Downloads, reduziert die Startlatenz und gibt Ihnen einen Punkt, um zu überprüfen, was abgerufen wird.

Offline-Modus: Einige Workloads sollten überhaupt keine Paketinstallationen ausführen – die Umgebung ist im Image oder der Vorlage vorab enthalten, und Installationsversuche sollten mit einem klaren Fehler fehlschlagen. Dies ist der geeignete Modus für Evaluierungsläufe, bei denen Reproduzierbarkeit wichtiger ist als Flexibilität.

Hash-Überprüfung und Lockfiles: Wenn Pakete erlaubt sind, reduzieren festgelegte Versionen und Hash-Überprüfungen das Risiko, dass ein Registry-Kompromiss den Code ändert, der innerhalb der Sandbox ausgeführt wird.

Größenbeschränkungen: Pakete und ihre transitiven Abhängigkeiten können groß sein. Eine Größenobergrenze für den gesamten heruntergeladenen Umfang pro Sitzung verhindert versehentliche oder absichtliche Speichererschöpfung.

Paketprotokollierung: Jeder Installationsversuch sollte im Ausführungs-Prüfpfad aufgezeichnet werden: Paketname, angeforderte Version, Registry-Quelle und Erfolg oder Fehlschlag. Dies sind die Daten, die Sie benötigen, um zu rekonstruieren, was während eines Vorfalls in die Sandbox gelangt ist.

Die Frage, die Sie einem Sandbox-Anbieter stellen sollten, ist nicht „Können Benutzer Pakete installieren?“, sondern „Wie wird jede Installation geprüft, welche Registrierungen sind standardmäßig erlaubt und kann ich eine strengere Richtlinie für sensible Workloads konfigurieren?“

Netzwerk- und Ausgangskontrollen

Netzwerkzugriff ist der zweite große Vektor für eine Sandbox, um unerwartete Ziele zu erreichen. Standardmäßig offener Ausgang ist in der Entwicklung praktisch, aber eine schlechte Voreinstellung für Produktions-Apps, die KI-generierten Code ausführen.

Standardmäßig verweigerter Ausgang: Die stärkste Produktionshaltung ist, alle ausgehenden Verbindungen standardmäßig zu blockieren und die Ziele, die eine Sitzung legitimerweise benötigt, explizit auf die Whitelist zu setzen. Dies erfordert mehr Konfiguration, macht das Zugriffsmodell jedoch prüfbar.

Auf die Whitelist gesetzte Ziele: Für Code-Agenten können typische erlaubte Ziele Paketregistrierungen, eine bestimmte Reihe öffentlicher APIs, die der Agent aufrufen soll, und nichts anderes sein. Für Datenanalyse-Agenten kann die Liste bestimmte Datenquellen enthalten. Überprüfen Sie, ob die Plattform pro-Sitzung oder pro-Mandant Ziel-Allowlists unterstützt.

DNS-Richtlinie: DNS sollte konsistent mit der Ausgangsrichtlinie behandelt werden. Eine Sitzung, die keine beliebigen HTTP-Ziele erreichen kann, sollte auch keine beliebigen DNS-Namen auflösen können, um die Netzwerktopologie zu erkennen oder Kontrollen über DNS-basierte Kanäle zu umgehen.

Zugriff auf interne Dienste: KI-generierter Code sollte keine Cloud-Metadaten-Endpunkte (z. B. den AWS-Instance-Metadata-Dienst), interne APIs, private Datenbanken oder Admin-Panels erreichen können, es sei denn, diese sind explizit konfiguriert. Überprüfen Sie, ob die Standardnetzwerkrichtlinie der Sandbox bekannte interne Adressbereiche blockiert.

Paket-Download-Ausgang: Paketinstallationen sind Netzwerkoperationen. Wenn der Ausgang eingeschränkt ist, stellen Sie sicher, dass die Paket-Registry-Allowlist konsistent mit der Ausgangsrichtlinie ist, oder verwenden Sie einen Pull-Through-Proxy innerhalb des vertrauenswürdigen Netzwerks.

Protokollierung ausgehender Verbindungen: Selbst wenn der Ausgang erlaubt ist, ist die Protokollierung, welche Domänen und IPs eine Sitzung kontaktiert hat, für die Untersuchung von Vorfällen nützlich. Nicht alle Sandbox-Plattformen bieten dies nativ; überprüfen Sie, was Sie erhalten.

Geheimnisse und Anmeldeinformationen-Injektion

KI-Agenten benötigen häufig Anmeldeinformationen – API-Schlüssel, Datenbankverbindungen, OAuth-Token, kurzlebige Cloud-Anmeldeinformationen. Wie eine Sandbox mit Geheimnissen umgeht, ist sowohl für die Sicherheit als auch für die betriebliche Zuverlässigkeit von Bedeutung.

Enger Gültigkeitsbereich: Jede Sitzung sollte nur die Geheimnisse erhalten, die sie für die spezifische Aufgabe benötigt. Das Einhängen einer breiten Umgebungsdatei mit allen Anmeldeinformationen in jede Sitzung ist betrieblich bequem, bedeutet aber, dass kompromittierter oder fehlverhaltender Code in jeder Sitzung auf alle diese Anmeldeinformationen zugreifen kann.

Kurzlebige Anmeldeinformationen: Wenn das Backend dies unterstützt, bevorzugen Sie kurzlebige Token mit einer TTL, die auf die Sitzungsdauer begrenzt ist. Dies begrenzt das Zeitfenster, in dem ein durchgesickertes Anmeldeinformations nützlich ist.

Injektionsmechanismus: Überprüfen Sie, ob Geheimnisse als Umgebungsvariablen, eingehängte Dateien oder über eine Secrets-API injiziert werden. Umgebungsvariablen sind standardmäßig für alle Prozesse in der Sitzung zugänglich; eingehängte Dateien können auf einen Pfad und Berechtigungssatz beschränkt werden. Für die sensibelsten Geheimnisse sollten Sie eine Secrets-API in Betracht ziehen, die Werte nur einem explizit autorisierten Prozess bereitstellt.

Schwärzung: Die Sandbox sollte Geheimnisse nicht über stdout, stderr, Ausführungslogs, Fehlermeldungen oder modellsichtbare Tool-Antworten zurückspiegeln. Schwärzung liegt in der Verantwortung der Anwendungsschicht, aber eine Sandbox, die konfigurierbare Log-Bereinigung unterstützt, reduziert die Auswirkung versehentlicher Offenlegung.

Bereinigung: Nachdem die Sitzung beendet ist, überprüfen Sie, dass Umgebungsvariablen, eingehängte Geheimnisdateien und alle zwischengespeicherten Anmeldeinformationen als Teil des Sitzungsabbaus bereinigt werden, nicht für die nächste Sitzung übrig bleiben.

Ephemeraler vs. persistenter Dateispeicher

Verschiedene Workloads haben unterschiedliche Persistenzanforderungen, und eine Produktions-Sandbox sollte beide Muster klar unterstützen.

Ephemere Sitzungen: Die Standardeinstellung für kurzlebige Code-Ausführung ist eine Sitzung, die ein sauberes Arbeitsverzeichnis erstellt, Code ausführt, Ausgabe produziert und zerstört wird. Ephemere Sitzungen sind einfach zu handhaben: Jeder Lauf beginnt von einer bekannten Basislinie, es sammelt sich kein Zustand an, und die Bereinigung ist unkompliziert. Sie sind die richtige Wahl für Evaluierungsjobs, einmalige Code-Vervollständigungen und jede Aufgabe, bei der Reproduzierbarkeit wichtiger ist als Kontinuität.

Persistente Arbeitsbereiche: Langlaufende Code-Agenten, iterative Entwicklungsabläufe und mehrrundige Agentensitzungen benötigen oft einen Arbeitsbereich, der über mehrere Ausführungsaufrufe hinweg bestehen bleibt. In einer Runde installierte Dateien, abhängige Caches, geschriebener Code und gesammelter Verlauf sollten in der nächsten verfügbar sein. Persistente Arbeitsbereiche sind komplexer zu betreiben: Sie sammeln Zustand an, können von der Vorlage abweichen und benötigen einen expliziten Lebenszyklus – wann wird der Arbeitsbereich bereinigt, wem gehört er und welche Zugriffskontrollen schützen ihn zwischen den Sitzungen?

Snapshots und Vorlagen: Vorlagen ermöglichen es Ihnen, eine bekannte gute Basisumgebung zu definieren – Laufzeiten, Werkzeuge, Abhängigkeiten – und konsistent Sitzungen daraus zu starten. Snapshots erfassen den aktuellen Zustand einer laufenden Sitzung und verwenden ihn als Ausgangspunkt für zukünftige Sitzungen. Beide sind nützlich für Teams, die wiederholbare Umgebungen und niedrige Startlatenz benötigen. Überprüfen Sie, dass Vorlagen versioniert sind, dass kontrolliert wird, wer sie erstellen und aktualisieren kann, und dass Snapshots nach Mandanten isoliert sind.

Export von Ausgabeartefakten: Nach der Ausführung: Was kann die Sandbox verlassen? Eine Produktionsrichtlinie sollte definieren, welche Dateipfade exportierbar sind, welche Größenbeschränkungen gelten und ob Artefakte überprüft oder gefiltert werden, bevor die Anwendung sie erhält.

Sitzungsübergreifender Zustand: Seien Sie explizit, ob Ihr App-Design beabsichtigt, dass Sitzungen Zustand teilen oder nicht. Versehentliches Teilen – durch einen gemeinsamen Paket-Cache, ein gemeinsames Volume oder einen falsch gerouteten Arbeitsbereich – ist ein häufiger Ausfall der Mandantenisolierung.

Backend-Integration: REST, WebSocket, SDK

Eine Sandbox ist nur nützlich, wenn sie sauber in das Anwendungsbackend integriert. Die drei Hauptintegrationsmuster sind REST, WebSocket und SDK.

REST: Eine REST-API ist die Integration mit der geringsten Friktion für Apps, die diskrete Ausführungsanfragen senden und auf Ergebnisse warten. Sie funktioniert gut für kurzlebige Aufgaben, ist mit Standard-HTTP-Werkzeugen einfach zu debuggen und passt natürlich in bestehende Dienstarchitekturen. Der Kompromiss ist, dass das Abfragen von Ergebnissen im Vergleich zu Push-Benachrichtigungen Latenz hinzufügt und das Streamen langlaufender Ausgaben entweder SSE oder das Abfragen eines Log-Endpunkts erfordert.

WebSocket: Eine WebSocket-Verbindung unterstützt bidirektionale, latenzarme Kommunikation zwischen der Anwendung und der Sandbox. Dies ist die richtige Wahl für interaktive Anwendungsfälle: ein Code-Assistent, der Ausgaben streamt, während Code läuft, ein Browser-Agent, der Befehle senden und in Echtzeit Antworten empfangen muss, oder ein Evaluierungs-Harness, der die Ausführung kontinuierlich überwacht. Der Kompromiss ist die betriebliche Komplexität: WebSocket-Verbindungen erfordern dauerhaften Zustand, Wiederherstellung nach Verbindungsabbruch und eine komplexere Infrastruktur sowohl auf Client- als auch auf Serverseite.

SDK: Ein sprachspezifisches SDK verbirgt Transportdetails, übernimmt die Authentifizierung, bietet typisierte Schnittstellen für Sitzungsverwaltung und Ausführung und enthält oft Helfer zum Streamen von Ausgaben, Hochladen von Dateien und Verwalten von Vorlagen. Ein SDK ist der schnellste Weg zur Integration für die meisten App-Entwickler. Überprüfen Sie, dass das SDK aktiv gewartet wird, die gesamte API-Oberfläche abdeckt und Fehler auf strukturierte Weise behandelt, auf die Ihre Anwendung reagieren kann.

Integrationspunkte, die Ihre Anwendung selbst besitzen muss: Unabhängig vom Transport ist Ihre Anwendung verantwortlich für Autorisierung (welche Benutzer Sitzungen mit welchen Ressourcengrenzen erstellen können), Freigabestufen (welche Tool-Aufrufe oder Code-Ausführungen vor der Ausführung menschliche Überprüfung erfordern), Ergebnisbehandlung (wie die Sandbox-Ausgabe an den Agenten oder Benutzer weitergegeben wird) und Bereinigung (Auslösen des Sitzungsabbaus, wenn der Benutzerablauf abgeschlossen ist oder die Agentenrunde endet).

Eine gut gestaltete Sandbox-API versucht nicht, die Geschäftslogik Ihrer Anwendung zu besitzen. Sie stellt Primitive bereit – erstellen, ausführen, streamen, beenden, bereinigen – und lässt Ihre Anwendungsschicht das richtige Produktverhalten darauf aufbauen.

Fehlerbehebung und Bereinigung

Produktionssysteme fallen aus. Eine Sandbox, die Fehler elegant behandelt, verhindert Ressourcenlecks, veralteten Zustand und schwer zu debuggende Vorfälle.

Behandlung von Ausführungs-Timeouts: Wenn eine laufende Ausführung ihr Zeitlimit überschreitet, sollte die Plattform den Prozessbaum sauber beenden und eine strukturierte Fehlerantwort zurückgeben – keine Zombie-Sitzung, die Ressourcen verbraucht, zurücklassen. Überprüfen Sie, was mit der Sitzung nach einem Timeout passiert: Wird sie automatisch bereinigt oder erfordert sie einen expliziten Bereinigungsaufruf?

Wiederherstellung nach Sitzungsabsturz: Wenn der Sandbox-Host abstürzt oder die Sitzungs-VM unerwartet beendet wird, sollte die Plattform den Fehler erkennen, die Sitzung als beendet markieren und diesen Status über die API melden, damit die Anwendung reagieren kann. Sitzungen sollten nicht stillschweigend ohne API-Signal verschwinden.

Bereinigungsgarantien: Ein cleanup- oder terminate-API-Aufruf sollte zuverlässig alle Ressourcen freigeben: CPU- und Speicherzuweisungen, Dateisystemkontingent, Prozessslots, Netzwerkstatus und Anmeldeinformationen. Die Bereinigung sollte idempotent sein – das mehrmalige Aufrufen derselben Sitzungs-ID sollte keinen Fehler zurückgeben. Dies ist in der Praxis wichtig: Anwendungscode, der die Bereinigung nach einem Netzwerkfehler wiederholt, sollte nicht kaputt gehen.

Teilweise Ausführungsfehler: Wenn Code mitten in der Ausführung fehlschlägt – eine nicht abgefangene Ausnahme, ein getöteter Prozess, ein fehlendes Paket – sollte die Sandbox ein strukturiertes Ergebnis zurückgeben, das einen teilweisen Erfolg (einige Ausgabe wurde vor dem Fehler produziert) von einem totalen Fehler unterscheidet. Anwendungen, die auf Teilergebnissen aufbauen, benötigen dies, um unvollständige oder irreführende Ausgaben an Benutzer zu vermeiden.

Behandlung außer Kontrolle geratener Prozesse: Wenn generierter Code einen Hintergrundprozess erstellt, der die Hauptausführung überlebt, sollte die Sandbox ihn als Teil der Sitzungsbereinigung beenden, anstatt ihn unbegrenzt laufen zu lassen. Überprüfen Sie, ob die Bereinigung der Plattform den gesamten Prozessbaum abdeckt, nicht nur das unmittelbare Kind des Ausführungsaufrufs.

Kapazitäts- und Kontingentfehler: Wenn die Plattform ihre Sitzungskapazität erreicht hat oder ein Mandant sein Kontingent erschöpft hat, sollte die API einen spezifischen Fehlercode zurückgeben, den die Anwendung explizit behandeln kann – keinen generischen 500 oder ein stilles Hängen. Dies ermöglicht der Anwendung, in die Warteschlange zu stellen, zurückzufahren oder eine nützliche Nachricht an den Benutzer zu senden.

Novita Agent Sandbox

Novita Agent Sandbox ist eine verwaltete Sandbox-Plattform, die für Agenten-Workloads entwickelt wurde. Sie zielt auf Code-Agenten, Datenanalyse-Agenten, browserorientierte Arbeitsabläufe und länger laufende Agentensitzungen ab, bei denen generierter Code in einer isolierten, beobachtbaren Umgebung ausgeführt werden muss, ohne auf Anwendungsservern oder gemeinsam genutzter Infrastruktur zu landen.

Für Teams, die bereits die Novita AI-Modell-APIs verwenden, kann Agent Sandbox Teil einer breiteren Agentenarchitektur sein: Das Modell plant und generiert Code, die Sandbox bietet isolierte Ausführung mit einem programmierbaren Lebenszyklus, und die Anwendungsschicht besitzt Autorisierung, Freigabestufen und Ergebnisbehandlung.

Novita hat Fähigkeiten beschrieben, darunter MicroVM-Isolierung, Unterstützung für nebenläufige Sitzungen, eine Lebenszyklus-API, die Erstellen, Ausführen, Streamen, Beenden und Bereinigen abdeckt, Pause und Autoresume zur Verwaltung des Sitzungszustands, Vorlagen und Snapshots für schnelle und wiederholbare Umgebungsstarts sowie Integration mit Novita-Modell-APIs. Überprüfen Sie die aktuelle Funktionsverfügbarkeit, Ressourcenkonfigurationsoptionen und Preise auf der Novita Agent Sandbox-Dokumentation und der Produktseite, bevor Sie Architekturentscheidungen treffen. Behauptungen zu bestimmten Isolierungsgrenzen, Parallelitätslimits, Startlatenz und Netzwerkrichtlinien sollten anhand der aktuellen Produktdokumentation bestätigt werden.

Wenn Sie Novita Agent Sandbox gegen die Anforderungen in diesem Leitfaden bewerten, wenden Sie dieselbe Checkliste wie bei jedem anderen Anbieter an: Isolierungsgrenze pro Sitzung, Vollständigkeit der Lebenszyklus-API, Beobachtbarkeitsoberfläche, konfigurierbare Ressourcengrenzen, Paketrichtlinienoptionen, Ausgangskontrollen, Geheimnisbehandlung, Persistenzmodell und Backend-Integrationsunterstützung.

FAQ

Welches Isolierungsmodell sollte ich für KI-generierten Code wählen?

MicroVM-Isolierung bietet die stärkste Grenze für nicht vertrauenswürdigen KI-Code, erhöht aber die betriebliche Komplexität. Containerisolierung ist für Workloads mit geringerem Risiko ausreichend, wenn der Container korrekt gehärtet ist – kein privilegierter Modus, minimale Capabilities, schreibgeschütztes Root-Dateisystem wo möglich und keine Host-Socket-Einhängungen. Prozessisolierung allein ist eine zu dünne Grenze für nicht vertrauenswürdigen Code, der möglicherweise Systemaufrufe, das Erzeugen von Unterprozessen oder Paketinstallationen versucht. Passen Sie die Isolierungsstufe an Ihr tatsächliches Bedrohungsmodell an.

Wie handhabe ich Paketinstallationen in einer Produktions-Sandbox?

Verwenden Sie Registry-Allowlists anstelle von standardmäßig offenem Zugriff. Fügen Sie einen Pull-Through-Cache hinzu, um redundante Downloads zu reduzieren und Ihnen einen Prüfpunkt zu geben. Protokollieren Sie jeden Installationsversuch mit Paketname, Version, Quelle und Ergebnis. Für Workloads, bei denen Reproduzierbarkeit wichtiger ist als Flexibilität – Evaluierungsläufe, automatisierte Pipelines – ziehen Sie einen Offline-Modus in Betracht, bei dem die Umgebung vorab erstellt wird und Installationen vollständig verboten sind.

Was sollte eine Lebenszyklus-API mindestens bereitstellen?

Erstellen, Ausführen mit Streaming-Ausgabe, Beenden und Bereinigen. Streaming-Ausgabe ist die Funktion, die in minimalistischen Implementierungen am häufigsten fehlt, und sie ist diejenige, die für interaktive Agenten-UI am wichtigsten ist. Die Bereinigung muss idempotent sein und den gesamten Prozessbaum abdecken, nicht nur den Einstiegspunkt-Prozess.

Wie verhindere ich, dass Geheimnisse durch eine Sandbox durchsickern?

Begrenzen Sie Anmeldeinformationen eng auf die Aufgabe – keine breite Umgebungsdatei. Bevorzugen Sie kurzlebige Token. Protokollieren Sie stdout standardmäßig nicht vollständig, wenn Geheimnisse darin erscheinen könnten. Überprüfen Sie, dass die Sandbox Umgebungsvariablen und eingehängte Geheimnisdateien beim Sitzungsabbau bereinigt. Behandeln Sie die Schwärzung als eine Verantwortung der Anwendung, nicht als eine Garantie der Sandbox.

---

Empfohlene Artikel

• Firecracker für KI-Agent-Sandboxes: Vorteile, Grenzen und Bewertungsfragen
• MCP-Server in isolierten Sandboxes: Dateisystem-, Geheimnis- und Netzwerk-Kompromisse
• Erstellen Sie einen KI-Datenanalysten mit Sandbox-Python und kontrolliertem Paketzugriff