AI-generierte Code-Sandbox: Anforderungen für Produktionsanwendungen

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

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

Sandbox-Isolation: Prozess, Container und MicroVM

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

Prozessisolierung verwendet 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-Sicherheitslücke 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 eine dünne Grenze für nicht vertrauenswürdigen KI-generierten Code, der möglicherweise Syscalls, Subprozess-Spawning oder Paketinstallationen versucht.

Was auf dieser Ebene zu überprüfen ist:

• Welche Syscalls sind blockiert, und wie lautet die Standardrichtlinie bei einem unbekannten Syscall?
• Sind Namespaces pro Aufgabe, pro Mandant oder gemeinsam über Jobs hinweg angelegt?
• Werden Cgroup-Limits auf Aufgabenebene oder nur auf Host-Ebene durchgesetzt?
• Räumt die Sandbox bei Beendigung alle Prozesse, temporären Dateien, Sockets und den gemeinsamen Speicher auf?

Container-Isolierung fügt eine Dateisystem- und Netzwerk-Namespace-Grenzen hinzu und macht die Image-Verwaltung wiederholbar. Container starten schneller als vollständige VMs, sind einfacher zu komponieren und werden von Orchestrierungsschichten weitgehend unterstützt. Der Kompromiss ist, dass Container weiterhin den Host-Kernel teilen und die Containergrenze nur so stark ist wie die zugrunde liegende Laufzeitkonfiguration. Privilegierte Container, breite Capability-Sets, gemountete Host-Sockets und Host-Netzwerkmodus reduzieren die effektive Grenze auf so gut wie nichts.

Was auf dieser Ebene zu überprüfen ist:

• Ist das Container-Image minimal und enthält nur die Laufzeiten und Tools, die die Workload tatsächlich benötigt?
• Sind Capabilities auf die minimal notwendige Menge reduziert?
• Ist der Container rootless oder benötigt er Root-Rechte, und welche Kontrollen gibt es dafür?
• Sind Host-PID-Namespace, Host-Netzwerk und der Docker-Socket explizit ausgeschlossen?
• Sind gemountete Volumes auf explizit definierte Pfade beschränkt, und ist das Root-Dateisystem wo möglich schreibgeschützt?

MicroVM-Isolierung platziert jede Workload in einer leichten 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 der Start schnell genug für die interaktive Nutzung bleibt. Die MicroVM-Grenze bedeutet, dass eine Kernel-Exploit im Gast den Host oder andere Gäste nicht automatisch beeinträchtigt.

Was auf dieser Ebene zu überprüfen ist:

• Erhält jeder Agentenlauf, jeder Mandant oder jede gleichzeitige Sitzung eine separate MicroVM?
• Wie hoch ist die Startlatenz vom API-Aufruf bis zur Ausführungsbereitschaft, und wird diese aus einem Warmpool, einem Snapshot oder einem Kaltstart gemessen?
• Sind Gast-Images versioniert, hinsichtlich der enthaltenen Laufzeiten und Tools auditiert und werden sie regelmäßig aktualisiert?
• Was passiert auf Host-Ebene, wenn der Gast-Kernel einen Kernel 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-generierten Code, ersetzt aber nicht die Dateisystemrichtlinie, Ausgangskontrollen, Paketverwaltung oder Geheimnisbehandlung. Diese Kontrollen müssen zusätzlich zu der gewählten Isolierungsschicht implementiert werden.

Verwalten gleichzeitiger Sandbox-Sitzungen

Eine Produktionsanwendung, die Code für mehrere Benutzer gleichzeitig generiert, benötigt eine Sandbox, die Nebenläufigkeit als erstklassiges Anliegen behandelt, nicht als nachträglichen Einfall.

Die Schlüsselfragen sind:

Isolierung pro Sitzung: Wenn 50 Sitzungen gleichzeitig laufen, hat jede Sitzung ihr eigenes isoliertes Dateisystem, eigene Prozessbäume, eigenen Netzwerk-Namespace und eigenen Berechtigungsbereich? Zustandslecks zwischen Sitzungen sind einer der schädlichsten Fehlermodi in mandantenfähigen Sandbox-Apps und sind in Tests, bei denen Sitzungen sequenziell laufen, oft unsichtbar.

Sitzungslimits und Gegendruck: Macht die Sandbox Nebenläufigkeitsgrenzen 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 stillschweigend die Leistung? Produktionsanwendungen benötigen dieses Signal, um Gegendruck, Warteschlangenmanagement und benutzerseitiges Feedback zu implementieren.

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

Warmpools und Startlatenz von Sitzungen: Interaktive Codierungsfunktionen benötigen Startzeiten unter einer Sekunde. Das erfordert in der Regel einen Pool vorinitialisierter Umgebungen, die sofort beansprucht werden können, anstatt bei Bedarf gestartet zu werden. Überprüfen Sie, ob die Plattform die Verfügbarkeit von Warmpools dokumentiert und welche Startlatenz bei verschiedenen Nebenläufigkeitsstufen zu erwarten ist.

Wiederverwendung von Sitzungen vs. frische Umgebungen: Einige Apps profitieren von der Wiederverwendung einer langlebigen Sitzung über mehrere Agenten-Durchläufe, während andere für jede Anfrage eine saubere Umgebung benötigen. Überprüfen Sie, ob beide Muster unterstützt werden und dass die Wiederverwendung von Sitzungen keine alten Zustände aus einer vorherigen Konversation überträgt.

Lebenszyklus-API: Erstellen, Ausführen, Beenden

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

Erstellen: Initialisiert eine neue Sandbox-Sitzung, optional aus einer Vorlage oder einem Snapshot, mit spezifizierten Ressourcengrenzen, Umgebungsvariablen und gemounteten Volumes. Die Antwort sollte eine Sitzungs-ID und ein Bereitschaftssignal enthalten, nicht nur eine Bestätigung.

Ausführen: Sendet Code oder einen 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.

Stream-Ausgabe: Ruft stdout und stderr als Stream ab, nicht nur als Endergebnis nach Abschluss der Ausführung. Streaming ist wichtig für langlebige Jobs, Agentenschritte, die mehrere Sekunden dauern, und jede Benutzeroberfläche, die dem Benutzer schrittweise Fortschritte zeigt.

Beenden: Beendet eine laufende Ausführung vor deren Abschluss. Die Sandbox sollte garantieren, dass der gesamte Prozessbaum bereinigt wird, nicht nur der Elternprozess.

Bereinigung: Zerstört die Sitzung und gibt alle zugehörigen Ressourcen frei – Dateisystem, Speicher, Prozessslots, Netzwerkstatus und alle gehaltenen Anmeldeinformationen. Dieser Aufruf sollte idempotent sein, sodass Wiederholungen nach einem Netzwerkfehler keine Fehler verursachen.

Dateien hoch- und herunterladen: Überträgt Eingabedateien vor der Ausführung in die Sandbox und ruft Ausgabeartefakte nach der Ausführung ab. Dateiübertragungen sollten durch Größenlimits begrenzt und richtliniengesteuert sein, welche Pfade beschreibbar sind.

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

• Pause und Fortsetzung: Kann eine langlebige Sitzung angehalten und später ohne Zustandsverlust fortgesetzt werden? Dies ist nützlich für Ratenbegrenzung, Kostenkontrolle und Sitzungsübergabe zwischen Agenten-Durchläufen.
• Snapshot: Kann der aktuelle Sitzungszustand erfasst und als Ausgangspunkt für zukünftige Sitzungen verwendet werden? Dies ist der Schlüsselmechanismus für Warmpools und wiederverwendbare Umgebungen.
• Timeout-Durchsetzung: Wenn der ausgeführte Code das Wanduhrzeit-Timeout überschreitet, beendet die Plattform ihn sauber und meldet den korrekten Exit-Status?

Beobachtbarkeit: Logs, Metriken und Traces

Sie können nicht debuggen oder auditieren, was Sie nicht sehen können. Produktionssandboxen benötigen eine integrierte Beobachtbarkeit, nicht eine nachträglich hinzugefügte.

Erfassung von stdout und stderr: Jede Ausführung sollte einen erfassten Ausgabedatensatz erzeugen, 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 sein.

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

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

Fehlerverfolgung: Wenn eine Sandbox nicht starten, ausführen oder bereinigen kann, sollte die Fehleroberfläche strukturiert sein: Fehlercode, Nachricht, Sitzungs-ID und genügend Kontext, um einen Benutzerfehler (schlechter Code, fehlendes Paket) von einem Plattformfehler (Quotenüberschreitung, 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 Kundencode und vollständige Befehlsausgabe gehören standardmäßig möglicherweise nicht in Audit-Logs – gestalten Sie sie so, dass sie von Ihren tatsächlichen Aufbewahrungs- und Zugriffsrichtlinien unterstützt werden 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 dazu, alles auf der Anwendungsschicht zu instrumentieren, was Arbeit verdoppelt und Ereignisse übersieht, die die Sandbox direkt beobachten kann.

CPU-, Speicher- und Timeout-Grenzen

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

Eine Produktionssandbox muss Limits auf Sitzungsebene durchsetzen, nicht nur auf Host-Ebene:

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 das Limit eine harte Grenze ist (der Prozess wird gedrosselt oder beendet) oder eine weiche Grenze (er konkurriert mit anderen Prozessen um verfügbare CPU).

Speicher: Legen Sie eine Speicherobergrenze fest, die eine Bereinigung oder Beendigung auslöst, anstatt der Sitzung zu erlauben, den Host-Speicher zu erschöpfen. Überprüfen Sie, was passiert, wenn das Limit 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 Client-Ebene – wenn der Client die Verbindung trennt, sollte die Sandbox die Ausführung trotzdem zum konfigurierten Limit beenden.

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

Prozessanzahl: KI-generierter Code kann Subprozesse, Hintergrundarbeiter oder Shell-Befehle erzeugen, die selbst weitere Prozesse spawnen. Ein Limit der Gesamtzahl der Prozesse im Namespace der Sitzung verhindert Fork-Bomben und außer Kontrolle geratene Subprozessbäume.

Wenn Sie eine Sandbox-Plattform evaluieren, überprüfen Sie, ob diese Limits pro Sitzung konfigurierbar sind (sodass verschiedene Benutzerstufen oder Aufgabentypen unterschiedliche Limits haben können), ob sie auf Sandbox-Ebene durchgesetzt werden und ob das Erreichen eines Limits 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-Abrufe. Jede dieser Operationen zieht externen Code zur Laufzeit in die Sandbox, was eines der risikoreichsten Operationen ist, die eine Sandbox regeln muss.

Eine Produktions-Paketrichtlinie sollte Folgendes abdecken:

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

Installationscaching: 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 ohne Paketinstallationen ausgeführt werden – die Umgebung ist in das Image oder die Vorlage eingebacken, 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-Verifizierung und Lockfiles: Wenn Pakete erlaubt sind, verringern festgelegte Versionen und Hash-Verifizierung das Risiko, dass ein Kompromiss der Registrierung den Code ändert, der innerhalb der Sandbox ausgeführt wird.

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

Paketlogging: Jeder Installationsversuch sollte im Ausführungs-Audit-Log aufgezeichnet werden: Paketname, angeforderte Version, Registrierungsquelle 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 an einen Sandbox-Anbieter ist nicht „Können Benutzer Pakete installieren?“, sondern „Wie wird jede Installation auditiert, 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 Standardeinstellung für Produktionsanwendungen, die KI-generierten Code ausführen.

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

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

DNS-Richtlinie: DNS sollte konsistent mit der Ausgangsrichtlinie behandelt werden. Eine Sitzung, die keine beliebigen HTTP-Ziele erreichen kann, sollte auch nicht in der Lage sein, beliebige DNS-Namen aufzulösen und dies zu nutzen, um Netzwerktopologie abzuleiten oder Kontrollen über DNS-basierte Kanäle zu umgehen.

Interner Service-Zugriff: KI-generierter Code sollte nicht auf Cloud-Metadaten-Endpunkte (z.B. den AWS-Instanz-Metadatendienst), interne APIs, private Datenbanken oder Admin-Panels zugreifen können, es sei denn, diese sind explizit konfiguriert. Überprüfen Sie, ob die Standard-Netzwerkrichtlinie der Sandbox bekannte interne Adressbereiche blockiert.

Paket-Download-Ausgang: Paketinstallationen sind Netzwerkoperationen. Wenn der Ausgang eingeschränkt ist, stellen Sie sicher, dass die Paketregistrierungs-Allowlist mit der Ausgangsrichtlinie konsistent 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 an; überprüfen Sie, was Sie erhalten werden.

Geheimnisse und Berechtigungsinjektion

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

Enger Gültigkeitsbereich: Jede Sitzung sollte nur die Geheimnisse erhalten, die sie für die spezifische auszuführende Aufgabe benötigt. Das Bereitstellen einer breiten Umgebungsdatei mit allen Anmeldeinformationen in jeder Sitzung ist betrieblich praktisch, 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 Tokens mit einer auf die Sitzungsdauer begrenzten TTL. Dies begrenzt das Zeitfenster, in dem eine durchgesickerte Anmeldeinformation nützlich ist.

Injektionsmechanismus: Überprüfen Sie, ob Geheimnisse als Umgebungsvariablen, als gemountete Dateien oder über eine Secrets-API injiziert werden. Umgebungsvariablen sind standardmäßig für alle Prozesse in der Sitzung zugänglich; gemountete Dateien können auf einen Pfad und Berechtigungssatz beschränkt werden. Für die sensibelsten Anmeldeinformationen ziehen Sie eine Secrets-API in Betracht, 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ückgeben. Schwärzung ist eine Verantwortung der Anwendungsschicht, aber eine Sandbox, die konfigurierbare Logbereinigung unterstützt, reduziert den Schadensradius einer versehentlichen Offenlegung.

Bereinigung: Nachdem die Sitzung beendet ist, überprüfen Sie, ob Umgebungsvariablen, gemountete Geheimnisdateien und zwischengespeicherte Anmeldeinformationen als Teil des Sitzungsabbaus bereinigt werden und nicht für die nächste Sitzung übrig bleiben.

Ephemere vs. persistente Dateispeicherung

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

Ephemere Sitzungen: Der Standard für kurzlebige Codeausfü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 startet 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: Langlebige Codierungsagenten, iterative Entwicklungsworkflows und mehrschrittige Agentensitzungen benötigen oft einen Arbeitsbereich, der über mehrere Ausführungsaufrufe hinweg erhalten bleibt. Dateien, die in einem Durchlauf installiert, Abhängigkeiten zwischengespeichert, Code geschrieben und Verlauf gesammelt wurden, sollten im 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 Basislinienumgebung zu definieren – Laufzeiten, Tools, Abhängigkeiten – und Sitzungen konsistent 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, ob Vorlagen versioniert sind, wer sie erstellen und aktualisieren kann, kontrolliert wird und dass Snapshots pro Mandant isoliert sind.

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

Zustand zwischen Sitzungen: Legen Sie explizit fest, ob Ihr Anwendungsdesign beabsichtigt, dass Sitzungen Zustand teilen oder nicht. Versehentliches Teilen – durch einen gemeinsamen Paketcache, ein gemeinsames Volume oder einen falsch weitergeleiteten Arbeitsbereich – ist ein häufiger Fehler der Mandantenisolierung.

Backend-Integration: REST, WebSocket, SDK

Eine Sandbox ist nur nützlich, wenn sie sich sauber in das Anwendungs-Backend integrieren lässt. Die drei Hauptintegrationsmuster sind REST, WebSocket und SDK.

REST: Eine REST-API ist die Integration mit der geringsten Reibung für Apps, die diskrete Ausführungsanfragen senden und auf Ergebnisse warten. Sie funktioniert gut für kurzlebige Aufgaben, ist mit Standard-HTTP-Tools einfach zu debuggen und fügt sich natürlich in bestehende Service-Architekturen ein. Der Kompromiss ist, dass Polling nach Ergebnissen im Vergleich zu Push-Benachrichtigungen Latenz hinzufügt und das Streamen langlebiger Ausgaben entweder SSE oder Polling eines Log-Endpunkts erfordert.

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

SDK: Ein sprachnatives 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, ob das SDK aktiv gewartet wird, die vollständige API-Oberfläche abdeckt und Fehler strukturiert behandelt, sodass Ihre Anwendung darauf 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), Genehmigungsstufen (welche Tool-Aufrufe oder Codeausführungen vor dem Ausführen eine menschliche Überprüfung erfordern), Ergebnisbehandlung (wie die Sandbox-Ausgabe dem Agenten präsentiert oder von ihm verarbeitet wird) und Bereinigung (Auslösen des Sitzungsabbaus, wenn der Benutzerfluss abgeschlossen ist oder die Agentenrunde endet).

Eine gut gestaltete Sandbox-API versucht nicht, die Geschäftslogik Ihrer Anwendung zu besitzen. Sie stellt Grundfunktionen 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 Timeout überschreitet, sollte die Plattform den Prozessbaum sauber beenden und eine strukturierte Fehlerantwort zurückgeben – keine Zombie-Sitzung hinterlassen, die Ressourcen verbraucht. Ü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 Zustand über die API signalisieren, damit die Anwendung reagieren kann. Sitzungen sollten nicht stillschweigend ohne API-Signal verschwinden.

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

Partielle Ausführungsfehler: Wenn Code mitten in der Ausführung fehlschlägt – eine unbehandelte Ausnahme, ein beendeter Prozess, ein fehlendes Paket – sollte die Sandbox ein strukturiertes Ergebnis zurückgeben, das zwischen partiellem Erfolg (vor dem Fehler wurde etwas Ausgabe produziert) und totalem Fehler unterscheidet. Anwendungen, die auf Teilergebnissen aufbauen, benötigen dies, um vermeiden zu können, Benutzern unvollständige oder irreführende Ausgaben zu präsentieren.

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 ihm zu erlauben, unbegrenzt weiterzulaufen. Überprüfen Sie, ob die Bereinigung der Plattform den gesamten Prozessbaum abdeckt, nicht nur das unmittelbare Kind des Ausführungsaufrufs.

Kapazitäts- und Quotenfehler: Wenn die Plattform ihre Sitzungskapazität erreicht hat oder ein Mandant sein Kontingent ausgeschö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, zu warten, zurückzufahren oder dem Benutzer eine nützliche Nachricht anzuzeigen.

Novita Agent Sandbox

Novita Agent Sandbox ist eine verwaltete Sandbox-Plattform, die für Agenten-Workloads entwickelt wurde. Sie zielt auf Codierungsagenten, Datenanalyseagenten, browserorientierte Workflows und langlebigere 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 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, Genehmigungsstufen und Ergebnisbehandlung.

Novita hat Fähigkeiten beschrieben, darunter MicroVM-Isolierung, Unterstützung für gleichzeitige 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 schnellen und wiederholbaren Umgebungsstart sowie Integration mit Novita-Modell-APIs. Überprüfen Sie die aktuelle Feature-Verfügbarkeit, die Konfigurationsoptionen für Ressourcen und die Preisgestaltung in der Dokumentation zu Novita Agent Sandbox und auf der Produktseite, bevor Sie Architekturentscheidungen treffen. Behauptungen zu bestimmten Isolierungsgrenzen, Nebenläufigkeitslimits, Startlatenz und Netzwerkrichtlinie sollten anhand der aktuellen Produktdokumentation bestätigt werden.

Wenn Sie Novita Agent Sandbox anhand der 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-generierten Code, erhöht aber die operative Komplexität. Container-Isolierung ist für risikoärmere Workloads ausreichend, wenn der Container korrekt gehärtet ist – kein privilegierter Modus, minimale Capabilities, nach Möglichkeit schreibgeschütztes Root-Dateisystem und keine Host-Socket-Mounts. Prozessisolierung allein ist eine zu dünne Grenze für nicht vertrauenswürdigen Code, der möglicherweise Syscalls, Subprozess-Spawning oder Paketinstallationen versucht. Passen Sie die Isolierungsstufe an Ihr tatsächliches Bedrohungsmodell an.

Wie gehe ich mit Paketinstallationen in einer Produktionssandbox um?

Verwenden Sie Registry-Allowlists anstelle von standardmäßig offenem Zugriff. Fügen Sie einen Pull-Through-Cache hinzu, um redundante Downloads zu reduzieren und einen Inspektionspunkt zu erhalten. 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 vorgebacken ist und Installationen vollständig untersagt sind.

Was sollte eine Lebenszyklus-API mindestens bereitstellen?

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

Wie verhindere ich, dass Geheimnisse durch eine Sandbox durchsickern?

Beschränken Sie Anmeldeinformationen eng auf die Aufgabe – keine breite Umgebungsdatei. Bevorzugen Sie kurzlebige Tokens. Protokollieren Sie stdout nicht standardmäßig vollständig, wenn dort Geheimnisse auftauchen könnten. Überprüfen Sie, dass die Sandbox Umgebungsvariablen und gemountete Geheimnisdateien beim Sitzungsabbau bereinigt. Behandeln Sie Schwärzung als Verantwortung der Anwendung, nicht als Garantie der Sandbox.

---

Empfohlene Artikel

• Firecracker für KI-Agenten-Sandboxen: Vorteile, Grenzen und Bewertungsfragen
• MCP-Server in isolierten Sandboxen: Dateisystem-, Geheimnis- und Netzwerk-Kompromisse
• Erstellen eines KI-Datenanalysten mit sandboxiertem Python und kontrolliertem Paketzugriff