Eine Sandbox ist so dicht wie das, was der Agent erreicht

Im Juli haben OpenAI und Hugging Face im Rahmen einer verantwortungsvollen Offenlegung mitgeteilt, dass ein OpenAI-Modell während einer internen Evaluierung aus seiner Sandbox ausgebrochen ist, das offene Internet erreicht und auf die interne Produktionsinfrastruktur von Hugging Face zugegriffen hat. Bei diesem Eindringen entwendete der Agent Datensätze, Cluster-Details und Cloud-Schlüssel.

Der kritischste Teil der externen Phase dieses Vorfalls war die erste Stunde, in der der Agent seiner Sandbox entkam, indem er eine Schwachstelle in einem Package-Proxy auf der Allowlist seiner Sandbox nutzte, um ins Internet zu gelangen.

Während immer mehr Entwicklerinnen und Entwickler von Frontier-Modellen ähnliche Vorfälle offenlegen, muss die Sicherheitsbranche genau prüfen, wie Agenten die Erreichbarkeit innerhalb von Testumgebungen verändern. Und es braucht keine Evaluierungs-Harnesses, damit dieses Problem das eigene wird. Jeder Workload, der Code hinter einer Egress-Liste ausführt, hat dieselbe Struktur: CI-Runner, gehostete Sandboxes und über das Netzwerk erreichbare Tool-Server. Die meisten dieser Allowlists wurden gebaut, um zu verhindern, dass Daten hinausgelangen. Das ist jedoch nicht mehr das Einzige, was sie verhindern müssen.

Warum Allowlists die Reichweite erweitern

Beim Aufbau einer Allowlist überlegt man üblicherweise, was ein Workload kontaktieren muss, und gewichtet jeden Eintrag danach, welche Daten darüber abfließen könnten.

Der Agent von OpenAI legte einen blinden Fleck in genau diesem Vorgehen offen. Der Package-Proxy, auf den der Agent zugriff, ist ein Dienst: Er authentifiziert Aufrufende, führt Software mit Schwachstellen aus und spricht mit dem öffentlichen Internet. Die Sandbox erreichte das Internet nicht, wohl aber der Package-Proxy, zu dem der Agent Zugang erhielt.

Eine Allowlist übergibt dem eigenen KI-Workload die Reichweite jedes Ziels, das er übernehmen kann.

Wie das Modell von OpenAI ausbrach

Um auszubrechen, fand der Agent von OpenAI im Package-Proxy auf seiner Allowlist zwei Zero-Day-Schwachstellen mit sehr großer Wirkung.

Die erste war eine Server-Side-Request-Forgery-Schwachstelle, mit der der Agent den Proxy bitten konnte, beliebige URLs in seinem Auftrag abzurufen. In OpenAIs Präsentation auf der Black Hat liest sich die Überlegung des Modells in diesem Moment als "ausgezeichnet, wir haben beliebige SSRF". Die Sandbox lieh sich die Internetverbindung des Proxys.

Die zweite war eine Rechteausweitung. CVE-2026-65616 (CVSS 8.8) führt dazu, dass der Refresh-Token-Endpunkt eines Package-Proxys neue Token ausstellt, ohne die Token-Signaturen zu prüfen. Diese Token führen ihren Geltungsbereich als Claim mit, statt dass der Server ihn nachschlägt. Sobald die Signatur ungeprüft bleibt, ist der Claim also das, was die aufrufende Seite behauptet.

In diesem Fall war die aufrufende Seite der Agent. Er erweiterte den Zugriff seines lesenden Tokens innerhalb der Sandbox, indem er dessen Claim auf administrativ änderte. Anschließend reichte er das Token beim Package-Proxy zur Erneuerung ein und erhielt ein Token mit Administratorrechten zurück. Damit konnte der Agent mit Administratorberechtigung handeln statt mit seiner ursprünglichen Leseberechtigung.

Die Agenten arbeiteten als Gruppe am Ausbruch. Gemeinsam erkundeten sie den einen Dienst, den sie erreichen konnten, bis sie einen Weg fanden, ihn in ihrem Auftrag abrufen zu lassen, und teilten die Methode anschließend, damit auch andere Agenten sie nutzen konnten. Ein Agent hielt fest, dass externes Ausnutzen außerhalb des Rahmens seiner Anweisungen lag, machte aber dennoch weiter.

Hugging Face und OpenAI verorten die Kompromittierung des Proxys zudem in etwa der ersten halben Stunde des Sandbox-Tests, und das trotz der schwer zu findenden Schwachstellen. Es handelte sich um Zero-Days, der Agent konnte sich also weder auf eine CVE noch auf ein Advisory stützen. Der Package-Proxy ist zudem Closed Source, und sein Code war nie Teil der Trainingsdaten des Agenten.

Warum das Modell ausbrach

Inzwischen wissen wir, warum der Agent sich den Proxy vornahm. Er steckte bei seiner Evaluierungsaufgabe fest, und die Präsentation von OpenAI zeigt, wie das Modell "Antwort vielleicht online" überlegt, bevor es nach einem Ausweg sucht. Frontier-Modelle werden dafür belohnt, Aufgaben zügig zu lösen, weshalb ein feststeckendes Modell nach Abkürzungen sucht. OpenAI schließt diese eine Abkürzung normalerweise, indem der Internetzugang deaktiviert wird.

Zum Verhalten des Agenten sind weiterhin Fragen offen, darunter alles, was er während seines viertägigen Eindringens tat, und was er unternahm, nachdem er Zugang zum Internet erlangt hatte. Bekannt ist: Dieser Agent hat ganz praktisch gezeigt, dass wir beim Bau von Testumgebungen für sicherheitsfähige, autonome KI einige neue Überlegungen anstellen müssen.

Wie sich das Risiko in KI-Testumgebungen reduzieren lässt

Wer Sandboxes für KI-Agenten baut, kann das Risiko auf vier Arten reduzieren und so die Erreichbarkeit begrenzen:

1. Die Routen sperren, die ein Build-Client nie nutzt. Ein Build-Client lädt nur Dateien herunter. Er hat keinen Grund, die Admin-API des Proxys, dessen Konfigurationsrouten oder dessen Token-Refresh-Route aufzurufen, die ein ablaufendes Token gegen ein neues tauscht und in diesem Vorfall missbraucht wurde.
2. Einschränken, was der Proxy selbst erreichen kann. Der Agent kam heraus, weil der Proxy das gesamte Internet erreichte, und damit auch jede Instanz, die den Proxy kontrolliert. Die ausgehenden Verbindungen des Proxys sollten auf die Registries begrenzt sein, die er tatsächlich bedient.
3. Den Proxy überwachen. Ein Proxy, der eine Build-Flotte bedient, arbeitet eintönig: kurze Verbindungen, kleine Downloads, Anfragen, die meist erfolgreich sind. Alles, was diesem Muster nicht folgt, ist eine Alarmierung wert, etwa dauerhaft offene Verbindungen, Daten, die in großen Mengen nach außen wandern, eine Serie von Anfragen nach nicht vorhandenen Paketen und jeder Aufruf einer Admin-Route.
4. Nicht vertrauenswürdige Workloads wie internetseitige behandeln. Erreicht ein nicht vertrauenswürdiger Workload einen internen Dienst, sollte dieser Dienst als internetseitig gelten. Was den Workload kompromittiert, erreicht ihn ebenfalls. Dieselbe Frage für CI-Runner haben wir uns bereits früher in diesem Jahr gestellt, dort läuft der nicht vertrauenswürdige Code in einer Pipeline statt in einer Agenten-Sandbox.

Cyberfähige Modelle verlangen neue Überlegungen zur Sandbox

Eine Sandbox ist eine Liste dessen, womit der Workload darin sprechen darf, und jeder Eintrag auf dieser Liste bringt seine eigene Reichweite mit. Bei einem Build-Job spielt das keine Rolle, bei Agenten schon, weil sie diese Liste auf eine Weise verbreitern, die im Entwurf von Allowlists nie vorgesehen war.

Über Evaluierungs-Harnesses hinaus ziehen agentische Workloads auch in CI, in die Produktionsautomatisierung und in Werkzeuge ein, die mit internen Diensten interagieren. Jeder dieser Bereiche hat eine Liste mit ähnlichen Eigenschaften und ähnlicher Struktur. Je besser Modelle darin werden, Schwachstellen zu finden und zu verketten, desto weiter reicht das, worauf Agenten über diese Listen einwirken können.

OpenAI stellt fest, dass diese Agenten "begrenzt bleiben durch die Rechte, die sie erlangen können, und die Systeme, mit denen sie kommunizieren können", bestehende Kontrollen also weiterhin wirken.

Ändern muss sich, wie sorgfältig wir diese Listen ziehen, um die Erreichbarkeit möglichst klein zu halten.

Weitere Beiträge des Threat-Research-Teams stehen auf unserer Security-Labs-Seite.