Ein Coding-Agent läuft in einem Container. Er sieht nur ein freigegebenes Arbeitsverzeichnis, seine Prozesse sind begrenzt und die Umgebung wird nach dem Lauf verworfen.
Das schützt den Rechner. Wenn derselbe Agent Quelltexte lesen und eine externe API erreichen darf, können Daten trotzdem die falsche Grenze überschreiten. Die Sandbox entscheidet nicht, wohin Informationen fließen dürfen.
Compute Containment und Data Containment
Episode 7 beschreibt den Airlock für Prozesse, Werkzeuge und Dateizugriffe. Diese Grenze bleibt notwendig. Sie reduziert den möglichen Schaden auf dem Host.
Data Containment stellt eine andere Frage. Welche Information darf für welchen Zweck an welches Ziel fließen? Ein korrekt begrenzter Container kann ausgehende HTTPS-Verbindungen erlauben. Ein Browser-Tool kann isoliert laufen und dennoch interne Inhalte an ein öffentliches Formular übertragen.
Die relevante Gefahr liegt oft in der Kombination. Der Agent verarbeitet einen nicht vertrauenswürdigen Inhalt, liest erlaubte interne Daten und besitzt einen erlaubten externen Kommunikationsweg. Jede Fähigkeit kann einzeln sinnvoll sein. Die Kette kann trotzdem unzulässig werden.
Das betrifft mehr als offensichtliche Secrets. Quellcode kann interne Pfade, Kundennamen oder Architekturentscheidungen enthalten. Ein Fehlerbericht kann personenbezogene Daten tragen. Selbst eine harmlose Zusammenfassung kann Informationen verbinden, die einzeln freigegeben waren, gemeinsam aber eine neue Aussage über ein internes System ergeben.
Die Datenklasse sollte deshalb am Ursprung hängen und bei jeder Verarbeitung erhalten bleiben. Eine Zusammenfassung erbt die Schutzanforderung ihrer Quelle, solange eine bewusste Prüfung nichts anderes festlegt. Sonst kann ein Agent sensible Inhalte umformulieren und sie anschließend wie neue, vermeintlich harmlose Daten behandeln. Der Wortlaut hat sich geändert. Die Vertraulichkeit nicht.
Deshalb reicht es nicht, einzelne Werkzeuge als sicher oder unsicher zu markieren. Der Browser ist nicht das Problem, und der Dateizugriff ist nicht das Problem. Entscheidend ist, welche Daten aus welchem Vertrauensbereich über diese Fähigkeiten in einen anderen Bereich gelangen.
Egress ist Teil der Autorisierung
„Der Agent darf das Internet nutzen“ ist keine ausreichende Policy. Vor einer externen Übertragung müssen Datenklasse, Empfänger, Zweck und Umfang feststehen. Eine technische Stelle außerhalb des Modells prüft diese Angaben vor der Verbindung.
Credentials bleiben beim Host oder einem Broker. Der Agent liefert normalisierte Parameter. Erst nach der Policy-Entscheidung erhält der konkrete Aufruf eine passende, kurzlebige Identität.
MCP macht diese Grenze gut sichtbar. Die offizielle Dokumentation empfiehlt unter anderem Autorisierung pro Aufruf, Netzwerkisolation und die Prüfung von Datenflüssen zwischen Servern. Authentisierung sagt, wer anfragt. Sie entscheidet nicht, ob ein bestimmter Inhalt weitergegeben werden darf.
Eine enge Regel könnte einen Abruf von Paketmetadaten bei einer freigegebenen Registry erlauben. Übertragen werden dürfen Paketname und Version, aber kein Quelltext und keine Umgebungsvariable. Zusätzlich kann die Policy die Zahl der Anfragen begrenzen und Ziel sowie Antwortstatus protokollieren.
Solche Regeln gehören an einen Proxy, Host oder Policy-Broker. Ein Satz im Systemprompt kann dem Modell erklären, was gewünscht ist. Er kann die Netzwerkverbindung nicht selbst kontrollieren.
Auch Tool-Ergebnisse brauchen eine Datenflussmarkierung. Eine Suchmaschine, ein Issue oder ein anderer Agent kann manipulierte Inhalte liefern. Beim nächsten Werkzeugschritt müssen Quelle, Vertrauensniveau, Datenklasse und zulässige Weitergabe deshalb erneut bekannt sein. Markdown macht einen fremden Inhalt nicht vertrauenswürdig, und ein zweiter Modellaufruf ist keine unabhängige Sicherheitsinstanz.
Freigabe und Readback
Episode 13 beschreibt, wie eine Freigabe Aktion, Ziel, Daten und Wirkung benennen muss. Für einen Datenfluss gehört der externe Empfänger ausdrücklich dazu. Ändert der Agent seinen Plan, wächst die Freigabe nicht mit.
Vor der externen Wirkung prüft die Commit-Grenze aus Episode 10, ob die Autorisierung noch gilt. Danach liest ein unabhängiger Check den realen Zustand zurück. Bei einem Upload kann das ein Hashvergleich sein. Bei einer Nachricht zählen Empfänger und Versandstatus.
Diese Rückprüfung ist bei Datenflüssen schwieriger als bei einer lokalen Datei. Ein Hash kann bestätigen, welches Artefakt an einem bekannten Ziel liegt. Er beweist nicht, dass keine zweite Übertragung stattfand. Dafür braucht es zusätzlich Egress-Protokolle und eine Architektur, in der externe Verbindungen den kontrollierten Weg nicht umgehen können.
Das Receipt aus Episode 8 verbindet Auftrag, Freigabe, Tool-Aufruf und beobachtete Wirkung. Es sollte dabei nicht selbst zum Datenspeicher für vollständige Prompts und Secrets werden. Metadaten, Hashes und redigierte Auszüge sind für viele Prüfungen die bessere Ausgangslage.
Was die Sandbox weiterhin leistet
Ohne Compute Containment könnte nicht vertrauenswürdiger Code direkt auf Prozesse, Dateien und Credentials des Hosts zugreifen. Die Sandbox bleibt daher ein wichtiger Teil der Architektur.
Sie ist aber keine Datenflusskontrolle. Ein kontrollierbares Agentensystem braucht zusätzlich enge Werkzeuge, technische Egress-Regeln und eine Verifikation der tatsächlichen Wirkung. Keine dieser Kontrollen beweist, dass Prompt Injection verschwunden ist. Sie begrenzen jedoch, welche Folgen daraus entstehen können.
Ich würde die Kontrollen nach dem Auftrag zuschneiden. Ein Agent für lokale Textentwürfe braucht meist keinen offenen Netzwerkzugang. Ein Rechercheagent darf externe Quellen lesen, sollte aber keine privaten Projektdateien sehen. Ein Deploymentagent kann ein geprüftes Artefakt übertragen, ohne zugleich beliebige Webseiten und interne Ablagen lesen zu dürfen.
Diese Trennung kostet Bequemlichkeit. Sie verhindert aber, dass aus einer nützlichen Kombination automatisch eine universelle Datenbrücke wird. Wenn ein neuer Arbeitsweg mehrere Vertrauensbereiche verbindet, sollte diese Verbindung als eigene Architekturentscheidung sichtbar sein.
Auch gute Policies können falsch klassifizieren. Ein Ziel kann auf einer Freigabeliste stehen und später kompromittiert werden. Daten können zu niedrig eingestuft sein. Ein Proxy kann umgangen werden. Data Containment ist deshalb kein Versprechen vollständiger Sicherheit. Es macht erlaubte Übergänge kleiner, beobachtbar und widerrufbar.
Kurz gesagt
Isolation begrenzt den Arbeitsraum. Autorisierung und Egress-Kontrolle begrenzen den Datenweg. Die Sandbox schützt den Rechner. Deine Daten brauchen eine eigene Grenze.
Quellen
OWASP AI Agent Security Cheat Sheet
Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.