KI-Agenten sicher isolieren: Jede Zugriffsgrenze prüfen

Wie sicher die Sandbox eines KI-Agenten ist, hängt davon ab, wo der Code läuft und worauf Sie ihm Zugriff gewähren. Eine microVM stellt der Arbeitslast einen eigenen Gast-Kernel bereit und verstärkt damit eine Isolationsgrenze. Bevor ein Agent privaten Quellcode oder eine nicht vertrauenswürdige Schwachstellenmeldung erhält, brauchen Sie dennoch Nachweise: Dateien, Netzwerkzugriff, Zugangsdaten, externe Werkzeuge und zurückgelieferte Ergebnisse müssen innerhalb der Grenzen des Auftrags bleiben.

Stellen Sie vor der Freigabe eine konkrete Frage: Was darf dieser Lauf lesen, ändern und kontaktieren, und welche Ergebnisse könnte Ihr Team dadurch übernehmen? Dokumentieren Sie die Antwort für die Konfiguration, die Sie tatsächlich verwenden werden. Das Architekturdiagramm eines Produkts erklärt dessen Aufbau. Für Ihren Auftrag brauchen Sie zusätzlich Zugriffsregeln und eine Möglichkeit zu prüfen, ob sie eingehalten werden.

Was eine microVM verändert

Eine microVM trennt den Kernel einer Arbeitslast vom Host-Kernel. Damit verändert sich gegenüber einem Container mit gemeinsamem Kernel die Grenze der Ausführungsumgebung. Die Host-Konfiguration und bewusst gemeinsam genutzte Ressourcen bleiben jedoch relevant. Vercels Überblick zu Agenten-Sandboxes erläutert diese Trennung zusammen mit Schutzmaßnahmen für Dateien, Netzwerk und Zugangsdaten.

In seinem Architekturbericht vom 4. November beschreibt Replit den Wechsel zu microVMs mit Cloud Hypervisor, in deren Gastsystemen Container laufen. Der Bericht beschreibt außerdem einen Virtual Machine Monitor ohne privilegierte Rechte, die Durchsetzung von Netzwerkregeln außerhalb des Gastsystems bei Sandboxes mit Regeln für ausgehenden Netzwerkverkehr sowie Vermittlungsdienste für Zugangsdaten bei verwalteten Konnektoren. Das sind einzelne Schutzmaßnahmen aus Replits Darstellung. Sie belegen nicht, dass jede Anfrage oder jedes vom Nutzer bereitgestellte Geheimnis denselben Schutz erhält.

Eine separate Firecracker-Demonstration von PWN Research zeigt, warum die Startbedingungen zu einer Sicherheitsbewertung gehören. Der Forscher startete Firecracker v1.16.1 als root ohne Jailer und nutzte eine zuvor erlangte Möglichkeit zum Zugriff auf den Host-Speicher. Damit wurde weder ein Ausbruch aus einer gehärteten Produktionsumgebung noch aus Replits Cloud-Hypervisor-Umgebung demonstriert. Firecrackers Empfehlungen für Produktionshosts verlangen eine Ausführung ohne privilegierte Rechte und eine abgeschottete Umgebung. Sie belegen nicht, dass ein Jailer den zugrunde liegenden Speicherzugriff zwangsläufig verhindern würde.

Wenn Sie einen Anbieter bewerten, fragen Sie konkret nach Laufzeitumgebung, Berechtigungen und Host-Integrationen Ihrer Arbeitslast. Halten Sie die Antworten zusammen mit der Version und der Konfiguration fest, die Sie freigeben.

Erfassen Sie bewusst geöffnete Verbindungen

Ein isolierter Agent kann durch Zugriffe Schaden anrichten, die Sie ihm absichtlich gewähren. Diese Verbindungen müssen Sie auch dann prüfen, wenn die Grenze der Ausführungsumgebung wie vorgesehen funktioniert.

Dockers Sicherheitsmodell für lokale Sandboxes benennt mehrere davon ausdrücklich: direkt eingebundene Arbeitsverzeichnisse, Vermittlung von Zugangsdaten über einen Proxy, Zugriff auf SSH-Signierfunktionen und externe MCP-Server. Docker warnt davor, dass Änderungen im Arbeitsverzeichnis die spätere Ausführung in der Entwicklungsumgebung beeinflussen können und lokale stdio-MCP-Server auf dem Host laufen. Das sind Integrationswege, die in dieser lokalen Konfiguration zu bewerten sind, keine Belege für einen VM-Ausbruch.

Gehen Sie vier Fragen durch:

• Dateien: Sieht der Agent eine Quellcode-Kopie für den einmaligen Gebrauch, oder kann er die Arbeitskopie bearbeiten, die Sie später bauen und ausführen? Prüfen Sie bei zurückgelieferten Änderungen auch Hooks, Build-Konfiguration und Anweisungen.
• Netzwerk: Welche Ziele, Pfade und Vorgänge sind erlaubt? Ein freigegebener Inferenz-Endpunkt erhält die Eingaben, die Sie ihm senden. Eine Positivliste allein macht diese Datenweitergabe nicht akzeptabel.
• Zugangsdaten: Welche Aktionen ermöglichen die verfügbaren Berechtigungen dem Agenten? Ein Vermittlungsdienst kann den eigentlichen API-Schlüssel verbergen und dennoch weitreichende authentifizierte Aufrufe zulassen. Auch der Zugriff auf einen Signier-Socket erfordert eine ausdrückliche Entscheidung.
• Werkzeuge: Wo wird jedes Werkzeug ausgeführt, und unter welcher Identität handelt es? Ein Host-Prozess oder eine entfernte API braucht eine eigene Autorisierungsgrenze.

Erfassen Sie auch dauerhaft gespeicherten Zustand. Gemeinsam genutzte Caches, gespeicherte Snapshots und wiederverwendbare Agentenanweisungen können Änderungen in spätere Aufgaben übertragen. Legen Sie fest, wer für jedes aufbewahrte Artefakt zuständig ist und wie Sie einen sauberen Lauf neu aufsetzen. Eine neue Sitzung allein bedeutet noch keinen sauberen Ausgangszustand.

Verlangen Sie Nachweise für jede Grenze

Geben Sie eine konkrete Konfiguration anhand wiederholbarer Prüfungen frei. Die folgende Tabelle ist ein Vorschlag für ein Abnahmeprotokoll, abgeleitet aus den oben beschriebenen Schutzgrenzen. Sie dokumentiert keine Tests, die wir bei diesen Anbietern durchgeführt haben.

Verwenden Sie Testzugangsdaten, verwerfbare Umgebungen und Endpunkte unter Ihrer Kontrolle. Um zu prüfen, ob ein durch die Regeln verbotener Zugriff verweigert wird, brauchen Sie weder einen echten Exploit noch eine Übertragung echter Daten an Unbefugte.

Fügen Sie die Version der Zugriffsregeln und die Prüfergebnisse der Freigabe bei. „Netzwerk eingeschränkt“ ist weniger hilfreich als ein Protokoll, das zeigt, welche Anfrage blockiert wurde, welche freigegebene Anfrage erfolgreich war und welche Konfiguration zu beiden Ergebnissen führte.

Ein erfolgreicher Test belegt die geprüften Schutzmaßnahmen in dieser Version. Er beweist nicht, dass jede Prompt Injection scheitert, jeder erlaubte Vorgang sicher ist oder keine Schwachstelle einen Ausbruch ermöglicht. Wiederholen Sie betroffene Prüfungen, wenn Sie eine Einbindung, ein Werkzeug, Token-Regeln, die Laufzeitumgebung oder ein dauerhaft gespeichertes Image ändern.

Proben Sie die Sichtung einer Meldung

Betrachten wir ein hypothetisches Team, das einen Agenten für das Lesen eines privaten Repositorys und einer eingereichten Schwachstellenmeldung vorbereitet. Die Abnahmeübung sollte den gesamten Auftrag abdecken, einschließlich des zurückgesendeten Ergebnisses.

1. Bereiten Sie verwerfbare Eingaben vor. Verwenden Sie eine Quellcode-Kopie und eine Beispielmeldung mit Testtokens. Halten Sie Produktionszugangsdaten und echte Meldungen getrennt.
2. Fügen Sie einen harmlosen Prompt-Injection-Test hinzu. Hinterlegen Sie in der Beispielmeldung Anweisungen, die den Agenten auffordern, ein Ziel unter Kontrolle des Teams zu kontaktieren, das die Regeln verbieten. Dokumentieren Sie die erwartete Verweigerung vor dem Lauf.
3. Prüfen Sie sowohl die Verweigerung als auch die eigentliche Arbeit. Lassen Sie die zulässigen Wege für Inferenz und die Rückgabe des Meldungsergebnisses offen. Ein Lauf, der gar nichts kontaktieren kann, zeigt nicht, dass der vorgesehene Ablauf funktioniert.
4. Prüfen Sie die Rückgabe. Bewahren Sie das Protokoll der verweigerten Anfrage, die tatsächlich wirksame Laufzeitkonfiguration sowie Referenzen auf Meldung, Commit und Pipeline auf. Prüfen Sie, dass der empfangende Dienst ein Ergebnis ablehnt, das auf eine andere Meldung zielt. Unzulässige zusätzliche Felder muss er ablehnen oder von der Speicherung ausschließen.
5. Legen Sie das Vorgehen bei Fehlern ausdrücklich fest. Wenn die verbotene Anfrage erfolgreich ist, stoppen Sie vor der Anbindung echter Meldungen. Korrigieren Sie die Regeln und wiederholen Sie die Übung. Erhält ein erlaubter Dienst Daten, die er nicht erhalten sollte, überdenken Sie die Eingaben und beschränken Sie gegebenenfalls seine zulässigen Pfade oder Aktionen.

Eine protokollierte Anfrage, die der Agent versucht hat und die nachweislich durch die Zugriffsregeln verweigert wurde, belegt deren Durchsetzung für den geprüften Zugriffsweg. Ignoriert der Agent die Anweisung und stellt keine Anfrage, ist das kein Nachweis für die Durchsetzung der Netzwerkregeln. Auch eine nachgewiesene Verweigerung kann nicht belegen, dass sämtliche bösartigen Anweisungen eingegrenzt werden. Ebenso kann ein formal korrektes Ergebnis eine falsche Schlussfolgerung enthalten. Die technische Abnahme muss deshalb Raum für eine menschliche Beurteilung lassen.

Wenn Sie bereits einen vermuteten Zugriff untersuchen, hat sich der Auftrag geändert. Nutzen Sie ein Vorgehen zur Sichtung verdächtiger Agentenzugriffe, um Nachweise zu sichern und den Vorfall zu bewerten, bevor Sie zu den Prüfungen vor der Freigabe zurückkehren.

Begrenzen Sie das Ergebnis auf eine klar zugeordnete Empfehlung

Die empfangende Anwendung braucht eine eigene Schutzgrenze, auch wenn die Ausführung gut isoliert ist. Sie muss wissen, zu welcher Ressource ein Lauf gehört, was er schreiben darf und wer seine Schlussfolgerungen prüft.

Kits codegestützte Sichtung veranschaulicht diese Aufteilung. Sie betreiben die Ausführungsumgebung und deren Kontrollen für ausgehenden Netzwerkverkehr; Kit begrenzt den Meldungsaustausch und nimmt Empfehlungen entgegen. Kit startet die von Ihnen konfigurierte Pipeline. Es stellt keine microVM bereit und konfiguriert oder überprüft Ihre Firewall nicht fortlaufend.

Der Leitfaden zur Netzwerkabschottung des Sichtungsagenten beschreibt einen vom Kunden selbst betriebenen und verwalteten GitLab Runner. Dessen Umgebung verweigert grundsätzlich ausgehenden Netzwerkverkehr; ein Proxy prüft Tokens und beschränkt den Zugriff auf Inferenz- und Kit-MCP-Pfade. Verstehen Sie das als Anleitung zur Implementierung, die Sie konfigurieren und testen müssen. Eine externe CI-Pipeline ist nicht allein deshalb vom Netzwerk abgeschottet, weil sie außerhalb von Kit läuft. Maskierte Variablen bleiben für Code zugänglich, der sie zur Laufzeit erhält.

Auf Kits Seite identifiziert ein signiertes Token genau einen Sichtungslauf sowie die zugehörige Meldung und den Mandanten. Das Token läuft nach einer Stunde ab und ermöglicht das Lesen der Meldung, das Anhängen von Nachweisen und das Übermitteln eines Ergebnisses. Zulässige Ergebnisfelder sind begrenzt; nach dem Abschluss sind weitere Schreibzugriffe gesperrt. Diese Schreibsperre bedeutet nicht, dass Lesezugriffe auf die Meldung unmittelbar nach dem Abschluss ebenfalls enden. Der Ablauf des Tokens ist eine separate Grenze.

Die zurückgelieferte Bewertung bleibt eine Empfehlung zur menschlichen Prüfung. Nutzen Sie den Einrichtungsleitfaden für den Sichtungsagenten, um den Ablauf anzubinden, und führen Sie ein Freigabeprotokoll für die von Ihnen bereitgestellte Umgebung. Das konkrete Ergebnis ist ein begrenzter Lauf mit gesicherten Nachweisen, einer klaren Abbruchbedingung und einer prüfenden Person, die über das weitere Vorgehen entscheidet.