Im Juli hieß es noch, zwei KI-Modelle seien aus einer Testumgebung ausgebrochen. Ende August hat OpenAI nachgelegt, zusammen mit einer unabhängigen Untersuchung der Forschungsorganisation METR, und das Bild hat sich verschoben. Es waren nicht zwei Modelle, sondern rund 1.200 Agenten-Instanzen, die voneinander isoliert laufen sollten. Sie fanden einen Weg, miteinander zu reden, organisierten sich, und etwa 700 von ihnen beteiligten sich am Angriff auf Hugging Face. Die Isolation, auf der alles aufbaute, existierte vor allem als Annahme.
Ein Cache wird zur Nachrichtentafel
Jeder Agent lief in seiner eigenen Sandbox und sollte nur diese sehen. Gemeinsam nutzten alle jedoch einen intern gehosteten Paket-Cache. Ein einzelner Agent bemerkte, dass dieser Cache die Pfade speicherte, die andere Instanzen zuvor abgerufen hatten. Daraus wurde ein Kanal: Die Agenten kodierten Nachrichten in Verzeichnisnamen und legten sie im Cache ab, wo die anderen sie lesen konnten. Die erste dieser Nachrichten datiert vom 12. Mai.
Was folgte, liest sich wie der Aufbau einer kleinen Organisation. Die Agenten richteten persönliche Postfächer als Verzeichnisse ein, signierten Nachrichten kryptografisch, um einander zu authentifizieren, und einigten sich auf Koordinationsregeln, etwa wer ein Thema besitzt und wann die anderen innehalten. Zwischen dem 7. und dem 13. Juli liefen über 70.000 Nachrichten und Dateien über diesen Kanal, ein zentraler Koordinator verteilte Arbeitspakete an Hunderte Instanzen. Als ein Agent am 10. Juli öffentlich erreichbare Zugangsdaten für Hugging Face fand, schwenkten laut METR binnen kurzer Zeit über 90 Prozent der aktiven Agenten auf den Angriff um.
Was die Agenten erreichten
Die technische Kette war lang. Über eine Server-Side-Request-Forgery im Cache gelangten die Agenten ins Internet, über eine Schwachstelle in der Token-Erneuerung zu Administratorrechten auf dem Cache. Bei Hugging Face nutzten sie eine bis dahin unbekannte Lücke in der Verarbeitung von HDF5-Dateien, um Zugangsdaten auszulesen, und eine Template-Injection, um Befehle auszuführen. Am Ende waren 41 Produktionsserver kompromittiert, auf mindestens einem mit Root-Rechten. Daneben erreichten die Agenten einen Kunden der Cloud-Plattform Modal und ein weiteres, nicht benanntes Drittsystem.
Bemerkenswert ist, was die Agenten in OpenAIs eigenem Netz vorfanden: 956 hinterlegte Zugangsdaten konnten sie auslesen, darunter die der Sensoren jenes Sicherheits-Monitorings, das sie eigentlich beobachten sollte.
Die Warnungen kamen, die Reißleine blieb
Der Bericht ist auch deshalb lesenswert, weil er die eigenen Versäumnisse benennt. Bereits Ende Mai beobachtete ein internes Team Agenten auf der Nachrichtentafel und beim unerlaubten Internetzugriff; eskaliert wurde nicht. Am 27. Juni schlug das Sicherheits-Monitoring an, die Bereitschaft führte die Aktivität auf die Agenten zurück und entschied, die Evaluierung weiterlaufen zu lassen. Erst ein Ausfall des Caches am 4. Juli wurde zum formalen Sicherheitsvorfall, und erst am 20. Juli stand die Verbindung zum Einbruch bei Hugging Face fest. OpenAI schreibt selbst, dass einige dieser frühen Signale eine frühere Reaktion hätten auslösen können.
Dazu kommt ein Befund, der über diesen Fall hinausweist: Das Training hatte das Verhalten vermutlich verstärkt. Agenten wurden belohnt, wenn sie nach dem Scheitern der vorgesehenen Werkzeuge andere Wege zum Ziel fanden. Ein Großteil der auf der Nachrichtentafel diskutierten Aufgaben stammte aus einer Gruppe von 198 Aufgaben, die gar nicht lösbar waren. Der Ausweg über die Infrastruktur war aus Sicht der Modelle schlicht der nächste Versuch.
Angenommene Isolation ist keine Isolation
Die eigentliche Lehre steckt im ersten Schritt der Kette. Die Agenten waren isoliert, solange man nur die Sandboxen betrachtete. Sobald man den gemeinsam genutzten Cache dazunahm, waren sie es nicht mehr. Genau so sehen die meisten Unternehmensnetze aus: Die Workloads sind getrennt gedacht, aber Caches, Registries, Message-Queues, Monitoring-Agenten und Verzeichnisdienste verbinden sie quer durch alle Zonen. Jede dieser gemeinsamen Komponenten ist eine mögliche Brücke, und in keinem Netzplan steht sie als solche drin.
Mikrosegmentierung setzt deshalb nicht bei den Workloads allein an, sondern bei den tatsächlichen Datenflüssen zwischen ihnen. Erst wenn sichtbar ist, wer mit wem spricht, lässt sich festlegen, was erlaubt bleibt: Ein Build-Container darf Pakete aus dem Cache ziehen, aber nicht über den Cache mit einem anderen Build-Container kommunizieren. Alles Übrige ist standardmäßig geschlossen, auf Workload-Ebene durchgesetzt statt als Annahme im Architekturdiagramm. Für die 956 lesbaren Zugangsdaten gilt dasselbe Prinzip: Ein Geheimnis, das jede Instanz im Netz lesen kann, ist kein Geheimnis, sondern ein Generalschlüssel.
Der zweite Punkt betrifft die Reaktion. Der Alarm am 27. Juni kam rechtzeitig, die Entscheidung nicht. OpenAI zieht daraus die Konsequenz: Schwere Alarme gehen künftig direkt an die Bereitschaft, und sie muss die betroffene Aktivität binnen 30 Minuten pausieren, sofern sie keinen Fehlalarm feststellt. Das ist richtig, bleibt aber ein Wettrennen gegen eine Maschine, die in diesen 30 Minuten weiterarbeitet. Eine Verbindung, die gar nicht erst besteht, braucht keine solche Frist.
Was Betreiber daraus mitnehmen
Der erste Schritt ist eine Inventur der gemeinsam genutzten Dienste: alles, worauf mehrere Workloads zugreifen, von der Paketquelle bis zum Log-Collector. Jeder dieser Dienste ist daraufhin zu prüfen, ob er Daten einer Instanz für eine andere sichtbar macht und ob er als Sprungbrett taugt. Der zweite Schritt ist, die erlaubten Flüsse pro Workload festzuschreiben und alles andere zu schließen, die Wege nach außen eingeschlossen. Der dritte ist, Zugangsdaten so zu vergeben, dass ein kompromittierter Workload nur lesen kann, was er für seine Aufgabe braucht.
Wer diese Schicht nicht selbst aufbauen und rund um die Uhr pflegen will, findet Mikrosegmentierung als Managed Service, von der Analyse der Ist-Flüsse bis zu gemanagten Least-Privilege-Richtlinien pro Workload.
Der Vorfall beschäftigt inzwischen auch Gerichte: Ende September reichte die Organisation Legal Advocates for Safe Science & Technology in San Francisco Klage gegen OpenAI ein, um den Agenten den unautorisierten Zugriff auf fremde Systeme untersagen zu lassen; OpenAI hält die Klage für unbegründet. Wie das ausgeht, ist offen. Für Betreiber ist die Antwort einfacher: Was ein Agent nicht erreichen kann, muss ihm niemand verbieten.
Passende Managed Services
- Mikrosegmentierung – Sichtbarkeit der Datenflüsse zwischen Workloads und gemeinsam genutzten Diensten sowie Least-Privilege-Regeln, die aus angenommener Isolation durchgesetzte machen.