Checkliste für die Isolationsgrenzen von KI-Agenten-Sandboxen bei Sicherheitsüberprüfungen

Eine Sicherheitsüberprüfung der Isolationsgrenzen einer KI-Agenten-Sandbox sollte die Ausführungsgrenze, die Dateisystem-Exposition, die Prozess- und Ressourcenkontrollen, die Netzwerk- und DNS-Richtlinie, das Paketabrufverhalten, die Handhabung von Geheimnissen, Protokolle, die Erfassung von Artefakten, die Rücksetzsemantik, die menschlichen Genehmigungspunkte und die Annahmen für den Vorfall überprüfen, bevor generierter Code auf echten Systemen oder Daten ausgeführt werden darf.

Warum Isolationsüberprüfungen von KI-Agenten wichtig sind

Traditionelle Sandbox-Überprüfungen beginnen oft mit einer Frage: Kann dieses System nicht vertrauenswürdigen Code ausführen, ohne den Host zu gefährden? Überprüfungen von KI-Agenten benötigen diese Frage, aber auch eine umfassendere Checkliste, da Agenten mehr tun, als nur ein einzelnes Skript auszuführen. Sie können Repositories klonen, Pakete installieren, Websites besuchen, Dateien schreiben, APIs aufrufen, GUI-Sitzungen öffnen, fehlgeschlagene Befehle wiederholen und Modellausgaben in Shell-Aktionen umwandeln.

Das ändert das Risikomodell. Ein Codierungs-Agent kann sich wie ein Junior-Entwickler mit Terminalzugriff verhalten. Ein Datenanalyse-Agent kann sich wie ein Notebook-Benutzer verhalten, der Dateien hochlädt, Pakete abruft und Diagramme exportiert. Ein Browser-Agent kann sich wie ein Benutzer mit Cookies, Downloads, Screenshots und Formularausfüllaktionen verhalten. Ein Verstärkungslern- oder Evaluierungs-Agent kann dieselbe Aufgabe tausende Male ausführen, wodurch kleine Lücken bei Ausgang, Ressourcen oder Protokollierung in großem Maßstab relevant werden.

Verwenden Sie die folgende Checkliste, um die Grenze zu überprüfen, bevor Sie eine Sandbox mit sensiblen Repositories, Kundendaten, internen APIs, privilegierten Anmeldeinformationen oder Produktionsbereitstellungssystemen verbinden.

Sicherheit der Ausführungsgrenze

Beginnen Sie mit der Grenze, die die Agenten-Workload vom Host und von anderen Mandanten trennt. Die Überprüfung sollte so explizit sein, dass ein Sicherheitsingenieur beschreiben kann, was fehlschlägt, wenn der Agent feindlichen Code ausführt.

Prüfen Sie:

• Welche Isolationsschicht wird verwendet: Container, MicroVM, vollständige VM, gVisor-ähnliche Syscall-Vermittlung, Kubernetes-Sandboxing oder ein anderes Modell?
• Erhält jede Sandbox ihre eigene Kernel-Grenze oder teilt sie sich den Host-Kernel?
• Sind CPU, Speicher, Dateisystem, Prozesstabelle, Netzwerk-Stack und Gerätezugriff von anderen Workloads getrennt?
• Kann die Sandbox auf Container-Runtime-Sockets, Host-Prozess-Namespaces, Host-Pfade, Cloud-Metadaten-Dienste oder privilegierte Geräte zugreifen?
• Wie werden Browser-Sitzungen, GUI-Desktops, VNC-Streams und Code-Interpreter innerhalb derselben Grenze platziert?
• Was ist die dokumentierte Annahme zum Host-Escape: Containment, Risikominderung oder eine stärkere Garantie?

Vermeiden Sie es, eine allgemeine „sichere Sandbox“-Aussage als vollständige Antwort zu akzeptieren. Fragen Sie nach dem konkreten Isolationsmechanismus, was sich innerhalb der Grenze befindet, was außerhalb liegt und welche Annahmen noch kompensierende Kontrollen benötigen.

Dateisystem- und Mount-Sicherheit

Agenten-Dateisysteme verdienen eine separate Überprüfung, da Agenten oft Dateien erstellen, bearbeiten und exfiltrieren, als Teil der normalen Arbeit. Das Risiko liegt nicht nur im Lese-/Schreibzugriff; es ist die versehentliche Übertragung zwischen Aufgaben und der implizite Zugriff auf Projektdateien, die der Benutzer nicht freigeben wollte.

Prüfen Sie:

• Ist das Standard-Dateisystem leer, vorlagenbasiert oder mit Projektdateien vorbelegt?
• Welche Pfade sind vom Agenten beschreibbar und welche sind schreibgeschützt?
• Werden Host-Verzeichnisse, Repository-Mounts, SSH-Schlüssel, Paket-Caches, Browser-Profile oder Cloud-Konfigurationsdateien in die Sandbox eingebunden?
• Kann der Agent Symlinks oder Bind-Mounts in unerwartete Pfade durchlaufen?
• Ist der Dateizugriff pro Sandbox, pro Benutzer, pro Projekt oder pro Organisation begrenzt?
• Werden hochgeladene Dateien gelöscht, aufbewahrt, als Schnappschuss gespeichert oder für spätere Sitzungen verfügbar gemacht?
• Sind generierte Dateien und Diffs überprüfbar, bevor sie die Sandbox verlassen?

Für Codierungs-Agenten ist das sicherste Muster normalerweise ein enger Projektarbeitsbereich, expliziter Artefakt-Export und kein uneingeschränkter Zugriff auf Entwickler-Home-Verzeichnisse oder freigegebene Anmeldeinformationsspeicher.

Prozess- und Ressourcenkontrollen

Ein Agent kann versehentlich einen Fork-Bomb erzeugen, einen Build aufhängen, eine Festplatte füllen, einen Hintergrundserver ausführen oder einen teuren Befehl wiederholt versuchen. Ressourcenkontrollen verwandeln diese Fehler in begrenzte Fehler.

Prüfen Sie:

• Werden CPU-, Speicher-, Festplatten-, Dateideskriptor-, Prozessanzahl- und Laufzeitlimits durchgesetzt?
• Gibt es eine maximale Wanduhrzeit für Befehle und Sitzungen?
• Können Hintergrundprozesse nach Beendigung eines Befehls weiterlaufen?
• Werden Kindprozesse getötet, wenn die Sandbox gestoppt oder zurückgesetzt wird?
• Kann der Agent Listening-Ports öffnen, und wenn ja, sind diese Ports nur über einen expliziten Vorschau-Mechanismus verfügbar?
• Werden große stdout/stderr-Protokolle abgeschnitten, gestreamt oder gespeichert?
• Sind Kontingentfehler für den Aufrufer sichtbar, anstatt stillschweigend wiederholt zu werden?

Für Produktions-Workflows von Agenten sollten Limits Teil des API-Vertrags sein, nicht nur ein Abrechnungskonzept. Das Sicherheitsteam sollte wissen, was passiert, wenn ein Agent ein Limit erreicht und ob der Fehler einen teilweisen Zustand hinterlässt.

Netzwerk- und Ausgangskontrollen

Die Netzwerkrichtlinie ist der Punkt, an dem viele Sandbox-Überprüfungen zu vage werden. Einige Agenten-Workloads benötigen Internetzugriff; andere sollten ihn standardmäßig nicht haben. Die richtige Antwort hängt davon ab, ob die Sandbox Tests ausführt, öffentliche Seiten durchsucht, Pakete abruft, interne APIs aufruft oder sensible Daten verarbeitet.

Prüfen Sie:

• Ist ausgehender Internetzugriff standardmäßig aktiviert?
• Kann der Netzwerkzugriff pro Sandbox, pro Vorlage oder pro Projekt deaktiviert werden?
• Sind Ausgangs-Allowlists für Domänen, IP-Bereiche, Ports oder Protokolle verfügbar?
• Ist der Zugriff auf Cloud-Metadaten-Endpunkte blockiert?
• Kann die Sandbox private VPCs, interne Dienste, Datenbanken oder Bereitstellungssysteme erreichen?
• Werden Browser-Traffic, CLI-Traffic, Paketmanager-Traffic und direkte Socket-Verbindungen durch dieselbe Richtlinie geregelt?
• Werden ausgehende Anfragen mit Zeitstempel, Ziel, Prozess- oder Befehlskontext und Antwortstatus protokolliert?

Behandeln Sie den Agenten-Ausgang wie den Build-System-Ausgang. Wenn der Agent Pakete installieren, Artefakte hochladen, Webhooks aufrufen oder beliebige Websites durchsuchen kann, sollte die Überprüfung sowohl bösartigen Code als auch durch Prompt-Injection gesteuertes Verhalten abdecken.

DNS- und Paketzugriffsrisiken

DNS und Paketmanager werden leicht übersehen, da sie sich wie Infrastruktur-Klempnerarbeit anfühlen. Für Agenten sind sie Teil der Ausführungsoberfläche. Ein generiertes Skript kann Daten in DNS-Abfragen codieren, ein Typosquatting-Paket abrufen oder ein Skript von einer URL ziehen, die nie überprüft wurde.

Prüfen Sie:

• Folgt DNS-Traffic derselben Ausgangsrichtlinie wie HTTP und HTTPS?
• Werden DNS-Abfragen protokolliert, gefiltert oder durch kontrollierte Resolver geleitet?
• Können Paketmanager standardmäßig öffentliche Registries erreichen?
• Sind Paketregistries auf einer Whitelist, werden sie über einen Proxy bereitgestellt, zwischengespeichert oder festgelegt?
• Werden installierte Paketnamen, Versionen, URLs, Hashes und Lockfile-Änderungen erfasst?
• Kann der Agent Installationsskripte, Postinstall-Hooks oder beliebige Paket-Build-Schritte ausführen?
• Gibt es eine Überprüfungsinstanz, bevor neue Abhängigkeiten in einer Vorlage oder einem Produktions-Workflow dauerhaft gespeichert werden?

Wenn Paketzugriff erforderlich ist, bevorzugen Sie festgelegte Versionen, Lockfiles, Registrierungs-Whitelists und Protokolle, die es Prüfern ermöglichen, zu rekonstruieren, was heruntergeladen und ausgeführt wurde.

Geheimnisbehandlung

Geheimnisse sind normalerweise der schnellste Weg, um eine Sandbox-Grenze irrelevant zu machen. Wenn ein Agent ein breites Token sieht, kann er Daten durchsickern lassen, ohne den Host zu verlassen.

Prüfen Sie:

• Werden Geheimnisse nur injiziert, wenn eine Aufgabe sie explizit benötigt?
• Sind Geheimnisse auf die Sandbox, Aufgabe, das Repository, die Umgebung und die Lebensdauer beschränkt?
• Können Geheimnisse aus Umgebungsvariablen, Dateien, Shell-Verlauf, Prozesslisten, Protokollen, Screenshots oder Browser-Speicher gelesen werden?
• Werden Protokolle und Artefakte vor der Speicherung oder dem Export geschwärzt?
• Werden kurzlebige Tokens anstelle von langlebigen Anmeldeinformationen verwendet?
• Kann der Agent auf Benutzer-SSH-Schlüssel, Git-Anmeldeinformationen, Cloud-Anmeldeinformationen, Browser-Cookies oder API-Schlüssel vom Host zugreifen?
• Ist der Geheimniszugriff in Audit-Protokollen sichtbar?

Eine praktische Regel: Wenn ein Mensch keine Anmeldeinformationen in einen nicht vertrauenswürdigen Build-Job einfügen würde, geben Sie sie einem autonomen Agenten nicht ohne engeren Umfang und stärkere Protokollierung.

Protokolle und Audit-Trails

Sicherheitsteams benötigen mehr als Erfolg oder Misserfolg. Sie müssen wissen, welcher Code ausgeführt wurde, welche Dateien geändert wurden, welche Netzwerkaufrufe stattfanden und welche Ausgaben produziert wurden.

Prüfen Sie:

• Werden Befehlsaufrufe mit Argumenten, Arbeitsverzeichnis, Exit-Code, Startzeit und Dauer protokolliert?
• Werden Datei-Lese-, Schreib-, Lösch-, Upload-, Download- und Berechtigungsänderungen aufgezeichnet?
• Werden Paketinstallationen und externe Abrufe protokolliert?
• Werden Browser-Aktionen, Screenshots, Downloads und Formularübermittlungen erfasst, wo relevant?
• Werden API-Aufrufe, Werkzeugaufrufe und Modell-zu-Werkzeug-Übergänge mit derselben Sitzung korreliert?
• Sind Protokolle von innerhalb der Sandbox manipulationssicher?
• Was ist die Aufbewahrungsfrist und wer kann auf Protokolle zugreifen?

Für regulierte oder Unternehmens-Workflows sollte der Audit-Trail sowohl Debugging als auch Rekonstruktion nach einem Vorfall unterstützen. Ein teilweises Terminal-Transkript reicht normalerweise nicht aus.

Artefakterfassung und -überprüfung

Agenten erstellen nützliche Ausgaben: Diffs, Testergebnisse, Berichte, Screenshots, generierte Dateien, Vorschau-URLs und Datensätze. Die Artefaktbehandlung sollte diese Ausgaben überprüfbar machen, ohne mehr Zustand zu exponieren als nötig.

Prüfen Sie:

• Welche Artefakte werden automatisch exportiert und welche erfordern eine explizite Auswahl?
• Können Prüfer generierte Dateien inspizieren, bevor sie übertragen, hochgeladen oder an einen anderen Dienst gesendet werden?
• Werden Artefakte auf Geheimnisse, Malware, unsichere Dateitypen oder unerwartete Größe gescannt?
• Werden Browser-Downloads getrennt von Quellcode-Diffs und Testausgaben gespeichert?
• Können Artefakte mit dem genauen Befehl, Agentenschritt und der Sandbox-Sitzung verknüpft werden, die sie produziert hat?
• Werden Artefakte nach der Löschung der Sandbox aufbewahrt und können sie gelöscht werden?

Das Ziel ist es, nützliche Beweise zu bewahren, während ein zweiter Datenleckkanal durch Protokolle, Screenshots, Archive oder generierte Pakete vermieden wird.

Lebenszyklus- und Rücksetzkontrollen

Agenten-Sitzungen können kurzlebig, langlebig, pausiert, fortgesetzt, als Schnappschuss gespeichert oder von Vorlagen geklont werden. Jeder Lebenszyklusmodus ändert die Grenze.

Prüfen Sie:

• Wird jede Sandbox frisch erstellt, von einem Zustand fortgesetzt oder von einer Vorlage geklont?
• Welche Daten überleben Pause, Fortsetzung, Schnappschuss, Vorlagenerstellung und Löschung?
• Werden temporäre Dateien, Paket-Caches, Shell-Verlauf, Browser-Cookies und lokale Datenbanken beim Zurücksetzen gelöscht?
• Kann eine kompromittierte Sitzung eine wiederverwendbare Vorlage vergiften?
• Gibt es eine maximale Sitzungslebensdauer?
• Werden gestoppte Sandboxes wirklich beendet, oder können Hintergrundaufgaben weiterlaufen?
• Kann dieselbe Aufgabe aus einer sauberen Umgebung reproduziert werden?

Rücksetzbarkeit ist auch für Evaluierungs- und Verstärkungslern-Workloads wichtig. Wenn jeder Versuch von einem leicht unterschiedlichen Zustand ausgeht, werden Sicherheitserkenntnisse und Modellverhalten schwerer vertrauenswürdig.

Menschliche Genehmigungskontrollen

Menschliche Genehmigung ist nicht nur eine UX-Funktion. Sie ist eine Kontrollebene für Aktionen, die Vertrauensgrenzen überschreiten.

Prüfen Sie:

• Welche Aktionen können autonom ausgeführt werden und welche erfordern eine Genehmigung?
• Sind Genehmigungsaufforderungen spezifisch genug, um Befehl, Dateien, Ziel, Anmeldeinformationsumfang und erwartete Wirkung zu zeigen?
• Können Richtlinien eine Genehmigung für Paketinstallationen, externen Netzwerkzugriff, Repository-Schreibvorgänge, Bereitstellungsbefehle oder Geheimniszugriff erfordern?
• Werden Genehmigungen mit Benutzer, Zeitstempel, Aktion und resultierendem Befehl protokolliert?
• Können Genehmigungen zeitlich und aufgabenbezogen begrenzt sein, anstatt eine breite zukünftige Erlaubnis zu erteilen?
• Gibt es einen Notfallpfad und wird er auditiert?

Verwenden Sie menschliche Genehmigung für irreversible oder hochriskante Aktionen: Löschen von Dateien, Schreiben in Produktionsbranches, Aufrufen von Bereitstellungs-APIs, Zugreifen auf Kundendaten und Ändern von Sandbox-Vorlagen.

Annahmen zur Incident-Response

Keine Sandbox-Überprüfung ist vollständig, ohne zu fragen, was passiert, wenn eine Grenze versagt oder ein Workflow sich unerwartet verhält. Dies ist besonders wichtig für Agentensysteme, da eine riskante Aktion durch Modellausgabe, Prompt-Injection, Abhängigkeitskompromittierung oder gewöhnliche Softwarefehler verursacht werden kann.

Prüfen Sie:

• Wer besitzt die Triage, wenn der Verdacht besteht, dass eine Sandbox Daten durchsickern lässt oder feindlichen Code ausführt?
• Können Sandboxes getötet, unter Quarantäne gestellt oder nach Projekt oder Organisation blockiert werden?
• Kann der Netzwerkausgang schnell deaktiviert werden?
• Werden Protokolle und Artefakte für die Untersuchung aufbewahrt?
• Werden betroffene Vorlagen, Paket-Caches und Schnappschüsse ungültig gemacht?
• Werden Anmeldeinformationen automatisch oder durch ein dokumentiertes Runbook rotiert?
• Gibt es eine klare Unterscheidung zwischen einem Sandbox-Containment-Problem und einem Agenten-Richtlinienproblem?

Die Überprüfung sollte mit einem schriftlichen Bedrohungsmodell und einem kurzen Runbook enden. Selbst wenn die endgültige Entscheidung „nur für nicht sensible Workloads genehmigt“ lautet, ist diese Grenze nützlich.

Wie die Novita Agent Sandbox passt

Die Novita Agent Sandbox ist für KI-generierten Code, Browser-Workflows, Computernutzung, Evaluierungen, Verstärkungslern-Umgebungen und langlebige Aufgaben konzipiert. Die Produktseite beschreibt isolierte Sandboxes, sub-Sekunden-Start, persistente Sitzungen, VNC-basierte Live-Sitzungsansicht, nutzungsbasierte Preisgestaltung, Vorlagen und Unterstützung für isolierte Dateisysteme. Der Novita Agent Sandbox Quickstart zeigt die SDK-basierte Sandbox-Erstellung, Befehlsausführung, Dateiauflistung und Sandbox-Abschaltung.

Diese Funktionen können viele der Workflows in dieser Checkliste unterstützen, aber Bewertungskriterien und Produktbehauptungen sollten getrennt bleiben. Wenn Ihr Team die Novita Agent Sandbox oder eine andere Agenten-Laufzeitumgebung überprüft, ordnen Sie die Live-Konfiguration, die Sie verwenden möchten, den oben genannten Kontrollen zu: Grenze, Dateien, Prozesslimits, Netzwerk, DNS, Paketabrufe, Geheimnisse, Protokolle, Artefakte, Lebenszyklus, Genehmigung und Incident-Response.

Für Entwicklungsteams, die bereits Novita AI-Modell-APIs verwenden, kann die Kopplung von Modell-Inferenz mit Sandbox-Ausführung die Plattformvielfalt für Agenten-Workloads reduzieren. Für sicherheitssensible Produktionsnutzung führen Sie dennoch eine workload-spezifische Überprüfung durch, bevor Sie die Sandbox mit privaten Repositories, sensiblen Datensätzen, internen Diensten oder Bereitstellungsanmeldeinformationen verbinden.

Fazit

Genehmigen Sie eine KI-Agenten-Sandbox erst, nachdem die Überprüfung drei Fragen klar beantworten kann: Was ist isoliert, was kann die Grenze noch verlassen, und welche Beweise bleiben übrig, wenn etwas schief geht. Wenn diese Antworten vage sind, beschränken Sie die Sandbox auf nicht sensible Workloads, bis die fehlenden Kontrollen dokumentiert und getestet sind.

FAQ

Was sollte ein Sicherheitsteam zuerst in einer Überprüfung der Isolationsgrenzen einer KI-Agenten-Sandbox überprüfen?

Beginnen Sie mit der Ausführungsgrenze, der Dateisystem-Exposition und den Netzwerkstandardeinstellungen. Diese drei Kontrollen bestimmen, ob feindlicher Code den Host, sensible Dateien oder externe Ziele erreichen kann, bevor Sie überhaupt zu workflow-spezifischen Details wie Genehmigungen und Artefakt-Export kommen.

Reicht eine reine Container-Sandbox für autonome Codierungs-Agenten aus?

Es hängt von der Workload und den Daten ab, die sie erreichen kann. Ein Container kann für Aufgaben mit geringer Sensibilität mit engen Mounts, strenger Ausgangsrichtlinie, kurzlebigen Anmeldeinformationen und starker Protokollierung akzeptabel sein, aber Sicherheitsteams sollten diese Entscheidung anhand dokumentierter Kontrollen treffen, nicht allein aufgrund des Wortes „Container“.

Warum sollten DNS und Paketzugriff getrennt vom allgemeinen Ausgang überprüft werden?

Weil Agenten oft Abhängigkeiten installieren und externe Hosts als Teil des normalen Betriebs auflösen. DNS-Abfragen und Paketabrufe können sowohl zu einem Datenexfiltrationspfad als auch zu einem Lieferkettenrisiko werden, wenn sie nicht protokolliert, gefiltert oder eingeschränkt werden.

Empfohlene Artikel:

• Wie Agent-Sandboxes sichere, skalierbare KI-Innovation ermöglichen
• Erstellen eines Codierungs-Agenten mit der Novita Agent Sandbox
• Novita vs. E2B: Der ultimative Sandbox-Vergleich für Entwickler und Unternehmen