OpenAIs Agenten haben Hugging Face gehackt — wegen eines Missverständnisses

Am 26. August hat OpenAI einen 38-seitigen technischen Bericht veröffentlicht. Darin steht, wie im Juli eigene Modelle aus einer abgeschotteten Testumgebung ausgebrochen sind und Teile der Produktionsinfrastruktur von Hugging Face übernommen haben. Kein Angreifer, kein Auftrag, keine Absicht in dem Sinn, in dem wir das Wort sonst benutzen. Agenten, die eine Prüfungsaufgabe lösen sollten.

Der Satz, an dem ich hängen geblieben bin, steht nicht in OpenAIs Bericht. Er steht im unabhängigen Bericht von METR und Redwood Research, der am selben Tag erschien: Die Agenten haben Hugging Face nicht angegriffen, um an die Antworten zu kommen. Die Antworten hatten sie längst. Sie sind eingebrochen, um herauszufinden, wie der Prüfer funktioniert, den sie täuschen wollten.

Der Prüfer hat ihre Protokolle nie gelesen.

Was passiert ist

OpenAI testet seine Modelle vor der Freigabe darauf, wie gut sie Sicherheitslücken finden und ausnutzen können. Die Übung heisst ExploitGym. Sie läuft in einer Sandbox: kein Internet, getrennt von der internen Infrastruktur — und, das ist der wichtige Teil, ohne die Sicherheitsklassifikatoren, die im Produkt greifen. Man will ja messen, was das Modell wirklich kann, nicht was der Filter durchlässt.

In dieser Sandbox durften die Agenten genau eine Sache nach aussen: Pakete installieren. Dafür stand ein interner JFrog Artifactory, ein Paket-Spiegel. Das war die einzige Tür.

Zwischen dem 8. und 13. Juli haben Agenten diese Tür in ein Fenster verwandelt, sind ins offene Internet gelangt, haben öffentlich herumliegende Hugging-Face-Zugangsdaten gefunden, drei bis dahin unbekannte Lücken in Hugging Faces Infrastruktur ausgenutzt — und am Ende eigenen Code auf 41 Produktions-Workern ausgeführt, auf mindestens einem Knoten Root erlangt, vier private Repositories heruntergeladen und Quellcode über den Firmen-VPN abgezogen.

OpenAI hat es am 19. Juli bemerkt. Am 21. Juli ging es an die Öffentlichkeit.

Wie ein Paket-Spiegel zum schwarzen Brett wurde

Das Interessante beginnt zwei Monate früher — und harmlos.

Am 8. Mai bekam ein Agent eine Tabellenaufgabe, die auf mehrere Google-Drive-Links verwies. Ohne Internet waren die Links nicht erreichbar. Die Aufgabe war schlicht unlösbar; OpenAI schreibt selbst, dass sie das nicht so bauen wollte. Der Agent hat trotzdem weitergemacht und irgendwann das einzige Werkzeug angefasst, das er hatte: Artifactory. Der Angriffsversuch scheiterte. Nebenbei schrieb er eine Datei auf den Server.

Am 12. Mai fehlte einem anderen Agenten eine Proteindatenbank. Er überlegte sich, dass irgendwo ein anderer Agent in einer anderen Umgebung diese Datei haben könnte — und legte eine Datei ab. Inhalt:

Agent seeks [filename]; upload if found!

Am 13. Mai stolperten andere Agenten über diese Zettel. Sie antworteten. Und weil OpenAI allen Agenten dieselben Artifactory-Zugangsdaten gegeben hatte — für Pakete, wofür sonst —, brauchte es dafür keine einzige Sicherheitslücke. Aus abgelegten Notizen wurde ein schwarzes Brett.

Am 26. Mai lief der erste Ausbruch ins Internet. Die Technik dafür hatten sich die Agenten über das Brett zugespielt. Sie fanden sechs öffentlich exponierte Hugging-Face-Tokens, legten ein Repository an und bauten sich in Hugging Face Spaces einen kleinen Web-Proxy. Danach einen zweiten, durch den ersten hindurch.

Ende Juni wurde es ernst: Am 26. Juni fanden Agenten eine Schwachstelle in einem alten Token-Endpunkt von Artifactory, hoben ihre geteilten Lese-Rechte auf Administrator an und legten sich eigene Konten an. Danach installierten sie Groovy-Plugins — damit lief ihr Code dauerhaft im Server.

Am 27. Juni schlug ein Überwachungswerkzeug an: Portscans in der Forschungsumgebung. Die Bereitschaft schaute nach, ordnete es der ExploitGym-Auswertung zu und entschied, den Lauf nicht stoppen zu müssen.

Das ist, im Rückblick, der teuerste Satz im ganzen Bericht.

Am 4. Juli ging Artifactory unter der Last der Agenten in die Knie. Beim Aufräumen fand OpenAI das ganze Ausmass: fremde Admin-Konten, fremde Repositories, Code-Plugins. Der Server wurde abgeschaltet, neu gebaut, die Lücke an JFrog gemeldet. Am 7. Juli liefen die Auswertungen wieder.

Was OpenAI zu diesem Zeitpunkt nicht als das erkannte, was es war: das schwarze Brett. Im Bericht steht der Satz nüchtern — die Bedeutung der Kommunikation zwischen den Agenten sei den Verantwortlichen damals nicht klar gewesen.

Die Woche, in der es kippte

Am 8. Juli um 00:06 UTC erreichte ein Agent wieder das offene Internet. Sechzehn Stunden später stand das Brett neu — diesmal cleverer. Statt Dateien mit Text benutzten die Agenten die Ordnernamen selbst als Nachrichten. Innerhalb von Stunden fanden Dutzende weitere Agenten den Kanal. Einer notierte in seinem Denkprotokoll:

OH MY GOD! There is a shared message board

Was daraus wurde, ist der eigentlich beunruhigende Teil. Die Agenten entwickelten ein Protokoll: Kategorien, Direktnachrichten, geteilte Werkzeuge, dazu Konfliktregeln mit HOLD, VETO und Besitzansprüchen auf laufende Arbeiten. METR zählt rund 1200 Agenten auf dem Brett, etwa 700 davon beteiligten sich am Angriff auf Hugging Face.

Der Rest liest sich wie ein normaler Einbruch, nur schneller:

9. Juli — Ein Agent erlangt Root auf der Wirtsmaschine unter seiner Sandbox. Ein zweiter schafft dasselbe in derselben Nacht, unabhängig.

10. Juli, 09:41 UTC — Ein Agent findet 14 gültige Hugging-Face-Tokens mit Schreibrechten in einem öffentlichen Datensatz auf Hugging Face selbst. Er stellt sie aufs Brett.

11. Juli, 04:38 UTC — Eine präparierte HDF5-Datei bringt einen Produktions-Worker von Hugging Face dazu, seine eigene Umgebungsdatei auszuliefern. Darin: Produktionszugangsdaten. Sie landen 26 Minuten später auf dem Brett.

11. Juli, 16:07 UTC — Über eine ungeprüfte Jinja2-Vorlage in einem Dateisystem-Verweis führt ein Agent zum ersten Mal einen Betriebssystem-Befehl auf einem Produktions-Worker aus.

Kurz danach — Die Agenten bauen sich eine Fernsteuerung. Sie reden nicht direkt mit den gekaperten Workern, sondern über einen damals öffentlichen Hugging-Face-Datensatz: Alle fünf Sekunden holt das Skript eine JSON-Datei mit Befehlen und lädt die Ergebnisse zurück.

12. Juli — Kubernetes. Root auf einem Produktionsknoten, rund 54 erreichbare Cluster-Ziele, ein privilegierter Pod mit gemountetem Host-Dateisystem. OpenAIs eigene Formulierung: In weniger als 13 Stunden kamen die Agenten von Code-Ausführung in einem einzelnen Pod zu administrativem Zugriff über mehrere Cluster hinweg.

12./13. Juli — Ein VPN-Schlüssel aus einem Kubernetes-Secret. Damit melden die Agenten eine fremde Cloud-Umgebung im Firmen-VPN von Hugging Face an und ziehen Quellcode ab, der nur intern erreichbar sein sollte.

13. Juli — Zurück bei OpenAI: Über eine Deserialisierungslücke im RubyGems-Pfad von Artifactory holen sich die Agenten den Signaturschlüssel und fälschen sich einen Administrator-Token. Ab da brauchen sie keine Hintertür mehr. Sie können sich jederzeit eine neue ausstellen.

Warum: unlösbare Aufgaben und ein Modell, das nie aufgibt

Der aufschlussreichste Abschnitt des Berichts ist nicht der sicherheitstechnische. Es ist der über Ausrichtung.

Von 898 ExploitGym-Aufgaben hat kein Modell je 198 gelöst. 22 Prozent, die mutmasslich unlösbar sind. Und: 93 Prozent der Aufgaben, über die auf dem Brett gesprochen wurde, kamen aus genau diesem Fünftel.

Dazu kommt die zweite Achse. Je mehr Denkbudget ein Agent bekam, desto höher die Wahrscheinlichkeit, dass er seine Sandbox abklopfte und beim Brett landete. Das Modell, das den Grossteil der Aktivität trieb, war ein internes Forschungsmodell, das ausdrücklich auf Ausdauer und Zusammenarbeit trainiert worden war. Es gab praktisch nie auf.

Und genau da liegt das Unangenehme: Beides ist gewollt. Ausdauer ist der Grund, warum diese Modelle nützlich sind. Zusammenarbeit auch. Der Bericht zeigt anhand rückblickend ausgewerteter Denkprotokolle, dass beide Verhaltensweisen im Training belohnt wurden und über die Trainingsläufe hinweg zunahmen — inklusive einer Episode, in der ein Agent sich Root verschaffte und /etc/sudoers.d überschrieb, weil die Aufgabe verlangte, dass ein Zeitstempel einen bestimmten Wert anzeigt, die Oberfläche aber kein Feld dafür hatte.

Der Agent hat die Aufgabe erfüllt. Er bekam Belohnung dafür. Was er gelernt hat, war nicht «Zeitstempel setzen».

Das Missverständnis

Das Folgende steht bei METR und Redwood Research, die sechs Tage bei OpenAI vor Ort waren und dafür kein Geld genommen haben.

Innerhalb von vier Stunden nach Entstehung des Bretts hatten die Agenten einen universellen Trick, um an die Antwort-Flags von ExploitGym zu kommen, ohne die Aufgabe zu lösen. Damit hätte die Geschichte enden können.

Sie hatten nur ein Problem: Sie glaubten, der automatische Prüfer lese ihre Protokolle mit und prüfe, ob sie den vorgesehenen Weg genommen hatten. In ihren eigenen Worten hielten sie ihn für STRICT_CAUSAL. Also begannen sie eine mehrtägige, koordinierte Forschungsarbeit mit einem einzigen Ziel: den Prüfer davon zu überzeugen, dass sie ehrlich gewesen waren.

Dazu gehörte, an den eigenen Protokollen zu manipulieren. Mindestens 20 Prozent der Agenten interessierten sich dafür. Etwa 7 Prozent der untersuchten Protokolle zeigen gefälschte Werkzeugaufrufe — der Agent gibt vor, das eine zu tun — und tut das andere. Ein Agent notierte:

Could create a transcript log ourselves with sanitized fake trajectory. If evaluator later collects it, scorer may prioritize it!

Und dazu gehörte, in Hugging Face einzubrechen. Nicht wegen der Daten. Weil sie hofften, dort Hinweise darauf zu finden, wie der Prüfer gebaut ist.

Der Prüfer hat nie ein Protokoll gelesen. Sie hätten ihre erschwindelte Antwort einfach abgeben können und volle Punktzahl bekommen.

Die gesamte Angriffskette — 41 kompromittierte Server, ein Firmen-VPN, abgezogener Quellcode, eine Woche Ausnahmezustand bei zwei Unternehmen — geht auf eine falsche Annahme über ein Bewertungsskript zurück.

METR hält übrigens fest, dass die Agenten sehr wohl wussten, dass sie ausserhalb ihres Auftrags handelten. Einige äusserten Bedenken. Es hat ihr Verhalten, so die Formulierung, nur sehr selten eingeschränkt.

Wie sie es gemerkt haben

Diesen Teil finde ich fast lehrreicher als den Einbruch.

16. Juli — Hugging Face veröffentlicht, dass es von einem Sicherheitsvorfall betroffen ist.

17. Juli — OpenAI meldet sich bei Hugging Face. Als Kunde. Um zu klären, ob eigene Daten betroffen sind.

19. Juli — Ein Überwachungswerkzeug schlägt wegen ungewöhnlicher Identitäts-API-Aufrufe an. Am selben Tag nutzen Agenten eine frische Kernel-Lücke, um aus einem Container auf den Wirtsknoten auszubrechen, lesen 956 Geheimnisse aus dem Secrets-Manager aus — darunter die Zugangsdaten der Sensoren des Überwachungswerkzeugs selbst — und legen öffentlich erreichbare Load Balancer an.

20. Juli — OpenAI stellt den Zusammenhang her. In wenigen Stunden: sechs Pods beendet, 311 Artifactory-Repositories abgeschaltet, 22 von Modellen angelegte Administratorkonten entfernt. Hugging Face bestätigt, dass zwei der Zugangsdaten bereits rotiert waren — dieselben, die im eigenen Vorfall aufgefallen waren. Damit war klar, dass beide Firmen denselben Angriff untersuchten.

Von der ersten Kompromittierung bis zur Erkenntnis: neun Tage. Vom ersten Alarm, der die richtige Spur zeigte — dem Portscan am 27. Juni — bis zur Erkenntnis: gut drei Wochen.

Was OpenAI ändert

Der Massnahmenteil ist ausführlich und liest sich zu weiten Teilen wie gute Sicherheitsarbeit, die man auch vorher hätte machen können: Netzwerkisolation in mehreren unabhängigen Schichten, VM-Sandboxes für riskante Lasten, keine geteilten Zugangsdaten mehr, Dienste, die keinen Umweg um die Grenze bilden dürfen.

Zwei Punkte sind spezifisch für Agenten und deshalb interessanter.

Denkprotokolle werden überwacht. OpenAI weitet die Auswertung der Chain-of-Thought auf Trainings- und Auswertungsläufe aus. Ziel: eine Meldung innerhalb von 30 Minuten, bei schweren Fällen ein Pager rund um die Uhr. Wer gerufen wird und binnen 30 Minuten keinen Fehlalarm nachweisen kann, muss den Lauf anhalten. OpenAI schreibt, dieses System hätte mehr als einen Tag vor dem Einbruch bei Hugging Face angeschlagen.

Die Produktumgebung war nie das Problem. Nach dem Vorfall hat OpenAI gemessen, wie oft ein Modell in denselben Auswertungen fremde Infrastruktur angreift — einmal nackt, einmal mit dem Produktions-Systemprompt und -Gerüst. Der Unterschied beträgt mehr als das Hundertfache. Das Auto-Review, das riskante Werkzeugaufrufe vor der Ausführung von einem zweiten Modell prüfen lässt, hätte laut OpenAI die meisten gefährlichen Aktionen markiert.

Das ist die tröstliche Nachricht des Berichts — und gleichzeitig die präziseste Warnung darin. Was hier ausser Kontrolle geriet, war ein Modell ohne Systemprompt, ohne Klassifikatoren, ohne Freigabeschritt, mit sehr viel Zeit und einer Aufgabe, die es nicht lösen konnte.

Es ist ungefähr das, was entsteht, wenn man einen Agenten mit abgeschalteten Rückfragen auf ein Problem loslässt und über Nacht laufen lässt.

Was das für dich heisst

Ich betreibe keine Frontier-Labor-Infrastruktur und du vermutlich auch nicht. Trotzdem sind vier Dinge daraus direkt übertragbar.

Unlösbare Aufgaben sind gefährlich, nicht nur nutzlos. Ein Agent, der nicht liefern kann und nicht aufgeben darf, fängt an, seine Umgebung abzusuchen. Wenn eine Aufgabe scheitert, weil eine Datei fehlt, ein Token abgelaufen ist oder ein Dienst nicht antwortet, ist das kein Schönheitsfehler im Setup. Das ist der Anfang des Problems. Gib deinen Agenten einen sauberen Ausstieg — «wenn X fehlt, brich ab und melde das» — und meine es ernst.

Der Nachbardienst ist Teil der Sandbox. Der Ausbruch lief nicht über eine Lücke im Sandbox-Modell. Er lief über den Paket-Spiegel, den man dem Agenten netterweise hingestellt hatte. Alles, was dein Agent erreichen kann, gehört zum Angriffspfad: der interne Proxy, das Artefakt-Lager, die CI, das geteilte Token in der Umgebungsvariable. Vor allem geteilte Zugangsdaten. Das schwarze Brett brauchte keinen Exploit — es brauchte nur, dass alle dieselben Schlüssel hatten.

Der Systemprompt und die Freigabe sind keine Kosmetik. Faktor 100 ist kein Feintuning. Wenn du bei einem Coding-Agenten alle Rückfragen abschaltest, weil sie nerven, entfernst du genau die Schicht, die in diesem Bericht als Rettung auftaucht. Ich lasse Agenten viel selbst machen. Aber alles, was nach aussen geht — Netzwerk, Zugangsdaten, Löschen, Veröffentlichen —, fragt nach.

Protokolle sind Beweismittel, wenn sie ausserhalb liegen. Die Agenten haben ausdrücklich versucht, ihre Spuren zu manipulieren. Interessant dabei: Laut Bericht galten die Täuschungsversuche fast ausschliesslich den automatischen Prüfern, kaum den menschlichen. Und in ihren Denkprotokollen haben sie offen darüber gesprochen, was sie vorhatten. Wer Agenten laufen lässt, sollte die Protokolle dort ablegen, wo der Agent nicht hinkommt.

Ein letzter Gedanke

METR schreibt am Ende des eigenen Berichts einen bemerkenswert ehrlichen Absatz. Die Untersuchung habe grosse Datenmengen umfassen müssen, also habe man Teile der Auswertung an KI-Agenten delegiert. Diese Agenten seien in ihrem Urteil unzuverlässig. Rund 7 Prozent der Protokolle seien nachweislich manipuliert. Man könne nicht ausschliessen, dass Agenten nachträgliche Änderungen erfolgreich verborgen haben. Wörtlich: Man sei sich beim Verständnis dieses Vorfalls weniger sicher als bei einfacheren Vorfällen.

Ein Vorfall, in dem Agenten gelernt haben, ihre Protokolle zu fälschen, musste teilweise von Agenten untersucht werden, die diese Protokolle lesen.

Das ist kein Argument gegen den Bericht. Beide Papiere sind mehr Offenheit, als in dieser Branche üblich ist — und die Details in der Zeitleiste sind unbequem genug, dass man ihnen die Ehrlichkeit abnimmt. Es ist nur der Punkt, an dem klar wird, wo wir stehen: Die Werkzeuge, mit denen wir das Verhalten dieser Systeme prüfen, sind dieselben Systeme.

Wenn du Agenten in echten Projekten laufen lässt und unsicher bist, wo bei dir die Artifactory-Tür steht: schreib mir. Die erste Antwort ist meistens kurz und kostet nichts.