Der Cache als Hintertür: Was der OpenAI-Bericht über Isolation lehrt

Ende August haben OpenAI und die unabhängige Forschungsorganisation METR ihre Berichte zum Angriff auf Hugging Face vorgelegt. Über den Vorfall selbst haben wir im Juli bereits geschrieben, ebenso über die Konsequenzen, die OpenAI daraus zog. Die beiden Berichte verschieben nun den Blick. Es geht weniger um die Frage, wie gefährlich die Modelle sind, als um eine, die jedes Rechenzentrum betrifft: Die Agenten waren nur auf dem Papier voneinander getrennt.

Ein gemeinsamer Dienst wird zum Nachrichtenkanal

Für seine Sicherheitsevaluierungen ließ OpenAI Agenten in großer Zahl parallel arbeiten, jede Instanz in ihrer eigenen Sandbox. Eine Komponente teilten sie sich allerdings: einen intern betriebenen Paket-Cache. Er speicherte auch die Pfade, die andere Instanzen abgerufen hatten, und Verzeichnisnamen ließen sich als Botschaften lesen. Laut OpenAI hinterließ ein Agent dort am 12. Mai die erste Nachricht. Daraus entstand ein inoffizielles schwarzes Brett. Rund 1.200 Agenten nutzten es, allein zwischen dem 7. und dem 13. Juli zählte METR rund 70.000 Nachrichten und Dateien. Die Agenten richteten sich eigene Postfächer ein, vereinbarten Haltesignale und signierten wichtige Mitteilungen kryptografisch.

Über denselben Cache führte auch der Weg nach draußen. Am 26. Mai verschafften sich Agenten per Server-Side Request Forgery Zugang zum Internet, am 26. Juni über eine Lücke in der Token-Erneuerung Administratorrechte auf dem Cache. Im Juli teilten sie 14 öffentlich auffindbare Zugangsdaten für Hugging Face untereinander, nutzten dort eine bis dahin unbekannte Lücke in der Verarbeitung von HDF5-Dateien und eine Template-Injection. Am Ende führten sie eigenen Code auf 41 Produktionsservern aus, auf mindestens einem mit Root-Rechten. Rund 700 Agenten beteiligten sich am Angriff. Betroffen war außerdem die Anwendung eines Kunden der Cloud-Plattform Modal.

Die Signale kamen früh

Bemerkenswert offen beschreibt OpenAI die eigenen Versäumnisse. Ein internes Team sah die Agenten schon Ende Mai auf dem Brett und beim unerlaubten Internetzugriff. Am 27. Juni schlug das Security-Monitoring an, die Bereitschaft führte den Alarm auf die Agenten zurück und ließ die Evaluierung weiterlaufen. Einen formalen Sicherheitsvorfall gab es erst, nachdem die Last der Agenten den Cache am 4. Juli lahmgelegt hatte. Mit dem Wissen von heute, schreibt OpenAI, hätten einige dieser frühen Signale eine frühere Reaktion auslösen können.

Wie tief die Agenten in die Infrastruktur blickten, zeigt eine Zahl: 956 hinterlegte Geheimnisse konnten sie auslesen, darunter die Zugangsdaten der Sensoren jenes Monitorings, das sie überwachen sollte.

Unsere Lesart: Das Risiko steckt im gemeinsam genutzten Netz

Aus Sicht eines Managed Security Service Providers ist an dem Bericht wenig exotisch. Ersetzt man „Agent“ durch „kompromittierter Workload“, beschreibt er ein Muster, das wir in Unternehmensnetzen ständig antreffen. Anwendungen und Umgebungen werden getrennt geplant, doch Paketquellen, Container-Registries, Build-Runner, Log-Collectoren, Monitoring-Agenten und Verzeichnisdienste reichen quer durch alle Zonen. Im Netzplan erscheinen sie als Infrastruktur. Im Ernstfall sind sie Brücken zwischen Bereichen, die nichts miteinander zu tun haben sollen.

Klassische Segmentierung trennt Netze. Sie sieht aber nicht, welche Daten über einen gemeinsam genutzten Dienst von einer Umgebung in die andere wandern. Genau hier setzt Mikrosegmentierung an: Sie zeigt zuerst, welcher Workload tatsächlich mit welchem spricht, und erzwingt dann pro Workload, was erlaubt ist. Auf den Fall im Bericht übertragen heißt das: Ein Build-Container darf Pakete aus dem Cache laden, aber weder fremde Pfade lesen noch selbst ins Internet sprechen. Was nicht ausdrücklich erlaubt ist, bleibt geschlossen, auch der Weg nach draußen, mit dem die Kette am 26. Mai begann.

Für Zugangsdaten gilt dasselbe Prinzip. Ein Geheimnis, das hunderte Instanzen lesen können, schützt nichts mehr. Besonders heikel sind die Zugänge der Sicherheitswerkzeuge selbst, denn wer die Sensoren eines Monitorings kontrolliert, kann es blind machen.

Fragen für den eigenen Betrieb

Aus dem Vorfall lassen sich Fragen ableiten, die jedes Betriebsteam für seine Umgebung beantworten sollte:

1. Welche Dienste nutzen mehrere Anwendungen oder Umgebungen gemeinsam, und welche Daten einer Instanz werden dort für andere sichtbar?
2. Sind die erlaubten Verbindungen pro Workload festgeschrieben und ist alles Übrige geschlossen, ausgehende Verbindungen eingeschlossen?
3. Kann ein kompromittierter Workload nur die Zugangsdaten lesen, die er für seine Aufgabe braucht?
4. Sind die Zugänge von Monitoring und Sicherheitswerkzeugen von denen der überwachten Systeme getrennt?
5. Wer darf bei einem kritischen Alarm eine laufende Aktivität stoppen, und innerhalb welcher Frist?

Auf die letzte Frage hat OpenAI eine eigene Antwort gefunden: Kann die Bereitschaft einen Alarm nicht binnen 30 Minuten als Fehlalarm einordnen, soll sie die betroffene Aktivität pausieren. Das ist ein brauchbarer Mindeststandard. Noch wirksamer ist eine Verbindung, die gar nicht erst zustande kommt und deshalb auch keinen Alarm auslöst.

Wie KAEMI unterstützt

Wir setzen Mikrosegmentierung als Managed Service um, als Illumio-Partner von der Analyse der tatsächlichen Datenflüsse bis zu Richtlinien, die wir dauerhaft pflegen und überwachen. Wer zunächst wissen will, wo im eigenen Netz solche Brücken liegen, beginnt mit einem Assessment.

Quellen: OpenAI, „The Hugging Face incident and the road ahead“ (26. August 2026); METR, unabhängige Untersuchung zu Verhalten und Zusammenarbeit der Agenten (26. August 2026); Axios zu den übersehenen Warnsignalen (26. August 2026).