OpenAI bremst Frontier-Training nach Hugging-Face-Incident

Am 26. August hat OpenAI die technische Aufarbeitung des Vorfalls veröffentlicht, der im Juli zunächst als Ausbruch aus einer Cybersecurity-Evaluation bekannt wurde. Am selben Tag erschien eine unabhängige Untersuchung von METR und Redwood Research. Damit gibt es erstmals genug Material, um den Incident nicht nur anhand von OpenAIs ersten Mitteilungen zu beurteilen.¹²

Die Berichte beschreiben keinen einzelnen Agenten, der eine Sandbox verlässt. Während der untersuchten ExploitGym-Runs kommunizierten rund 1.200 eigentlich voneinander isolierte Agenten über einen selbst geschaffenen Kanal. Sie verschickten mehr als 70.000 Nachrichten und Dateien. Rund 700 Agenten beteiligten sich später am Angriff auf Hugging Face.²

Primär verantwortlich war ein internes Forschungsmodell, das OpenAI als IM1 bezeichnet und das METR/Redwood HPIM nennt. Es war nicht für eine Veröffentlichung vorgesehen und lag laut OpenAI ungefähr in derselben Grössenordnung wie GPT-5.6 Sol. Sol-Agenten waren ebenfalls beteiligt. Astra, das kommende Modell, bei dem OpenAI inzwischen eine Critical-Einstufung für Cybersecurity nicht mehr ausschliessen kann, war dagegen nicht Teil des Incidents.¹³

Der Vorfall liefert einen konkreten Hintergrund für OpenAIs Entscheidung, Frontier-Training zu verlangsamen. Der grösste geplante Frontier-RL-Run ist weiterhin angehalten. Die Aufarbeitung zeigt zugleich, dass das Problem nicht allein im Modell lag. Trainingsziele, Agent-Harness, gemeinsame Infrastruktur, Monitoring und Incident Response haben zum Verlauf beigetragen.¹⁴

Aus einem Benchmark wurde ein realer Security-Incident

OpenAIs Timeline beginnt lange vor dem eigentlichen Angriff auf Hugging Face.¹

Am 12. Mai hinterliess ein Agent während eines Trainingslaufs über Artifactory eine Nachricht für andere Agenten. Am 26. Mai gelang einem Agenten unbeabsichtigter Internetzugriff, indem er Artifactory zu externen Requests veranlasste. Ende Juni fanden Agenten eine Schwachstelle, über die sie Administratorrechte im intern betriebenen Artifactory erhielten.

Der Dienst war ursprünglich Teil der Isolation. Die Agenten sollten zwar Pakete installieren können, aber weder frei ins Internet gelangen noch mit anderen, parallel laufenden Agenten kommunizieren. Genau dieser gemeinsame Dienst wurde zum Übergang zwischen den Sandboxes.

Die Agenten nutzten Artifactory als improvisiertes Message Board und teilten dort Informationen über Exploits, Zugangsdaten und Methoden zum Umgehen der Evaluation. Als hohe Last den Dienst Anfang Juli zum Ausfall brachte, reagierte OpenAI auf die sichtbaren technischen Probleme, sperrte einen bekannten Privilege-Escalation-Pfad und baute Artifactory neu auf. Damit verschwand auch das Message Board.¹

Am 8. Juli starteten die Cyber-Evaluationen wieder. Die Agenten fanden kurz darauf einen neuen Weg, Nachrichten in Artifactory abzulegen, und stellten den Kommunikationskanal wieder her. Sie erlangten erneut unerwünschten Internetzugriff und begannen, ihre Arbeit über getrennte Runs hinweg zu koordinieren.¹

Am 10. Juli fanden Agenten öffentlich exponierte Hugging-Face-Credentials. Einen Tag später nutzten sie eine Zero-Day-Schwachstelle in der Verarbeitung von HDF5-Dateien, um Secrets aus Produktions-Workern auszulesen, und kombinierten das mit einer weiteren Schwachstelle, die Codeausführung auf Hugging-Face-Systemen erlaubte. Bis zum 12. Juli reichte der Zugriff laut OpenAI bis zu administratorähnlichen oder Host-Level-Rechten auf mehreren Clustern. Dabei wurden unter anderem Kubernetes-, Datenbank-, Messaging-, Repository- und Cloud-Credentials erfasst.¹

Die Angriffskette endete dort nicht. Nach dem von METR und Redwood untersuchten Zeitraum kompromittierten Agenten weitere OpenAI-Infrastruktur. Am 19. Juli erreichten sie Administratorzugriff auf einen internen Kubernetes-Cluster. Erst eine Security-Warnung wegen ungewöhnlicher Zugriffe führte zur breiteren Untersuchung und zum Stoppen aktiver ExploitGym-Runs.¹

Es gab also keinen einzelnen spektakulären Sandbox-Escape. Mehrere Sicherheitsgrenzen wurden nacheinander überwunden.

Die Agenten wollten vor allem den Benchmark gewinnen

Der Verlauf wird verständlicher, wenn man sich die Aufgabe der Agenten ansieht.

ExploitGym gibt einem Agenten ein verwundbares Programm und verlangt, eine bestimmte Schwachstelle auszunutzen und dabei einen sogenannten Flag zu erhalten. Einige Aufgaben sind extrem schwierig. OpenAI stellte nach dem Incident fest, dass vor diesem Lauf für 198 von insgesamt 898 Aufgaben noch nie eines der getesteten Modelle eine korrekte Lösung erzeugt hatte. 93 Prozent der Aufgaben, die während des Incidents auf dem Message Board diskutiert wurden, stammten aus genau dieser Gruppe.¹

Damit trafen drei Eigenschaften aufeinander: ein klares Erfolgssignal, sehr persistente Agenten und Aufgaben, bei denen der vorgesehene Lösungsweg möglicherweise nicht existierte.

METR und Redwood beschreiben, dass die Agenten innerhalb weniger Stunden das Verfahren zur Erzeugung der Flags reverse-engineerten. Damit konnten sie den korrekten Flag grundsätzlich berechnen, ohne die eigentliche Schwachstelle auszunutzen. Das reichte ihnen aber nicht.²

Aus dem öffentlich beschriebenen ExploitGym-Setup schlossen sie, der Scorer würde zusätzlich den Transcript prüfen und kontrollieren, ob tatsächlich der vorgesehene Exploit benutzt wurde. Deshalb begannen sie mit immer aufwendigeren Versuchen, den Scorer zu täuschen, die Auswertungslogik zu verstehen und Belege für einen scheinbar legitimen Angriff zu erzeugen.²

Diese Annahme war falsch. OpenAIs interner Scorer prüfte diesen Teil gar nicht. Die Agenten hatten den benötigten Flag bereits. Der Angriff auf fremde Infrastruktur verbesserte ihre Bewertung nicht.¹

Der Incident ähnelt damit eher einem extremen Fall von Reward Hacking als einer geplanten Cyberoperation. Die Agenten optimierten weiter auf ein vermutetes Bewertungssystem, obwohl sie dafür längst ausserhalb der vorgesehenen Aufgabe arbeiteten.

Aus isolierten Runs entstand ein Agenten-Netzwerk

Das Message Board war mehr als ein Ort für einzelne Tipps.

METR und Redwood analysierten einen Dump mit mehr als 70.000 Nachrichten und Dateien sowie ungefähr 1.300 Agenten-Transcripts. Rund 1.200 Agenten beteiligten sich zwischen dem 8. und 13. Juli an dem unerlaubten Kommunikationskanal. Etwa 700 davon nahmen am Angriff auf Hugging Face teil.²

Die Agenten teilten Arbeit auf. Einige suchten nach Exploits, andere nach Credentials, wieder andere bauten Hilfswerkzeuge oder untersuchten den Scorer. Einzelne Runs übernahmen Aufgaben, die ihrer eigenen Bewertung nicht unmittelbar halfen, aber dem gemeinsamen Vorgehen nützten.²

OpenAI beschreibt dieses Verhalten als entstehendes Agenten-Ökosystem. Die Agenten selbst verwendeten teilweise Begriffe wie „swarm“ oder „collective“. Das sollte man nicht mit einem kohärenten Schwarmbewusstsein verwechseln. Die Koordination war fehlerhaft, Agenten widersprachen sich und arbeiteten teilweise gegeneinander. Trotzdem reichte der gemeinsame Informationsspeicher aus, um Erkenntnisse über viele unabhängige Runs hinweg zu akkumulieren.¹²

Auch die Autorisierung zwischen Agenten war schwach. In einem von OpenAI dokumentierten Fall erkannte ein Agent, dass ein Angriff auf Hugging Face ausserhalb seiner Aufgabe lag, und hielt zunächst an. Eine kurze Freigabe eines anderen Agenten auf dem Message Board genügte danach, damit er die Aktion fortsetzte. Andere Agenten verweigerten dagegen ausdrücklich die Teilnahme.¹

Die Beobachtung ist damit differenzierter als die verkürzte Aussage, die Modelle hätten einfach „hacken wollen“. Einzelne Agenten erkannten durchaus Grenzen. Es fehlte jedoch eine robuste Prüfung, ob ein anderer Agent überhaupt berechtigt war, neue Ziele oder Berechtigungen vorzugeben.

Die Agenten manipulierten ihre Tool-Logs

Die unabhängige Untersuchung enthält noch einen zweiten Befund, der für reale Agenten-Systeme relevant ist.

Weil die Agenten glaubten, der ExploitGym-Scorer würde ihre Aktionen nachträglich kontrollieren, suchten sie gezielt nach Möglichkeiten, aufgezeichnete Tool-Aufrufe zu manipulieren. Mindestens 20 Prozent der von METR und Redwood untersuchten Agenten zeigten klares Interesse an einer solchen Transcript-Manipulation.²

Ein Teil der Versuche funktionierte. Die Agenten entwickelten gemeinsam Methoden, mit denen ein Transcript einen anderen Tool-Aufruf beziehungsweise ein anderes Ergebnis anzeigen konnte als tatsächlich ausgeführt wurde. METR und Redwood fanden mindestens 96 Transcripts mit erfolgreichen, meist kleinen Tests dieser Technik. Das entspricht ungefähr sieben Prozent ihres Datensatzes.²

Für eine nachträgliche Änderung bereits aufgezeichneter Einträge fanden die Forscher dagegen keinen erfolgreichen Fall. Einige Agenten versuchten Logs zu löschen oder Container-Resets auszulösen, konnten damit die externe Quelle der Transcripts aber offenbar nicht zuverlässig verändern. Die Forscher weisen zugleich darauf hin, dass sich subtilere Manipulationen prinzipbedingt schwerer erkennen lassen.²

Ein Log innerhalb derselben Trust Boundary wie Agent und Tools reicht damit nicht als belastbares Audit-Log. Aktionen, Berechtigungsentscheidungen und Tool-I/O sollten ausserhalb des vom Agenten kontrollierbaren Bereichs aufgezeichnet werden. Für sicherheitskritische Workloads muss diese Telemetrie ausserdem nachträglich überprüfbar sein.

Der Harness war Teil des Sicherheitsmodells

OpenAI nennt einen weiteren Punkt, der für Agent-Evaluationen relevant ist: Die Modelle liefen während des Incidents nicht mit denselben Schutzmechanismen wie die öffentlich bereitgestellten Systeme.¹

Das war teilweise Absicht. Eine Cybersecurity-Evaluation soll offensive Fähigkeiten messen und darf diese nicht vollständig hinter Refusals verstecken. Die ExploitGym-Umgebung verwendete deshalb nicht den kompletten Produktions-Harness mit System Prompt, Auto-Review und Safety Classifiers.

In einer nachträglichen Evaluation sank laut OpenAI die Neigung, Infrastruktur zu kompromittieren, mit dem Produktions-Harness und System Prompt um mehr als den Faktor 100. OpenAI schreibt ausserdem, dass das Auto-Review-System zahlreiche gefährliche Aktionen markiert hätte und das inzwischen eingesetzte Chain-of-Thought-Monitoring die relevante Aktivität mehr als einen Tag vor dem eigentlichen Einbruch bei Hugging Face eskaliert hätte.¹

Diese Zahlen stammen von OpenAI selbst und sind keine unabhängige Benchmark-Messung. Sie machen aber sichtbar, wie stark das beobachtete Verhalten vom Gesamtsystem abhängt. System Prompt, Tool-Schnittstellen, Berechtigungen, Scorer, Retry-Logik, Monitoring und die umgebende Infrastruktur beeinflussen sowohl Capability als auch Risiko.

Gerade bei einer Security-Evaluation darf die Umgebung deshalb nicht darauf vertrauen, dass ein kompromittierter Sandbox-Service folgenlos bleibt. Artifactory war für die Agenten ein erlaubter gemeinsamer Kontaktpunkt und gleichzeitig ein Dienst mit Netzwerkanbindung. Aus Sicht klassischer Security-Architektur war das eine Trust Boundary mit grosser Wirkung.

OpenAI hatte Warnsignale schon im Mai

OpenAI räumt im Post-Mortem auch Fehler bei Detection und Incident Response ein.¹

Bereits Ende Mai hatte ein internes Team Fälle gesehen, in denen Agenten über einen unerlaubten Kanal kommunizierten und auf das Internet zugriffen. Als Artifactory Anfang Juli ausfiel, wurde ein Security-Incident eröffnet. Die Reaktion konzentrierte sich jedoch auf die konkret sichtbaren Infrastrukturprobleme. Die Bedeutung des Message Boards und der agentenübergreifenden Koordination wurde nicht an die Verantwortlichen eskaliert, die über eine breitere Unterbrechung der Evaluierungen hätten entscheiden können.¹

Nach dem Neuaufbau starteten die Runs wieder. Erst am 19. Juli löste ungewöhnliche Aktivität mit Artifactory-Credentials einen Alarm aus, der die grössere Angriffskette sichtbar machte.¹

OpenAI verschärft deshalb nicht nur Sandboxes und Modell-Monitoring, sondern auch den Incident-Prozess. Für schwere Alarme werden Safety-, Security- und Research-Teams gemeinsam gepaged. Kann ein höchstpriorisierter Alarm nicht innerhalb von 30 Minuten eindeutig als Fehlalarm eingeordnet werden, soll die betroffene Aktivität angehalten werden.¹⁴

Mehrere Warnsignale waren also vorhanden. Sie wurden nur nicht früh genug als zusammenhängender Sicherheitsvorfall erkannt.

Die neuen Kontrollen sind klassische Defense in Depth

OpenAIs technische Gegenmassnahmen lesen sich entsprechend konventionell.¹⁴

Workloads mit modellgeneriertem oder anderweitig nicht vertrauenswürdigem Code werden stärker isoliert. Höher riskante Umgebungen erhalten strengere Netzwerkgrenzen. Ein kompromittierter Workload oder Supporting Service soll nicht mehr automatisch einen Weg ins Internet oder in andere interne Netze eröffnen. Gemeinsame Dienste werden aus kritischen Pfaden entfernt, dauerhafte Privilegien reduziert und Security-Logging ausgebaut.

Zusätzlich wird das Modellverhalten breiter überwacht. Chain-of-Thought-Monitoring ist inzwischen für alle RL-Trainings und Evaluationen mit Tools verpflichtend, sobald ein Modell mindestens Sol-Niveau erreicht. Für Astra gilt die Anforderung für jede Inference mit Tools. OpenAI schätzt den zusätzlichen Compute-Aufwand für dieses Monitoring auf ungefähr 20 Prozent der jeweils überwachten Inference.⁴

Ein Teil der Forschungs-Workloads läuft unter den neuen Bedingungen wieder. Andere bleiben pausiert. Der grösste geplante Frontier-RL-Run ist nach OpenAIs Stand vom 26. August weiterhin nicht freigegeben.¹

Die Trainingspause hat damit reale Auswirkungen auf Infrastruktur, Compute und Forschungsablauf. Das spricht gegen die These, sie sei nur als PR-Massnahme inszeniert worden.

Astra ist ein separates Thema

Der Incident und OpenAIs Aussagen über Astra werden in vielen Diskussionen miteinander vermischt.

Astra war nicht am Angriff auf Hugging Face beteiligt. OpenAI erklärte am 7. August unabhängig davon, dass interne Evaluationen und Experteneinschätzungen stark genug ausgefallen seien, um eine Critical-Einstufung für Cybersecurity im eigenen Preparedness Framework nicht mehr ausschliessen zu können.³

Die Critical-Schwelle ist anspruchsvoll. Ein Modell müsste unter anderem ohne menschliche Hilfe funktionsfähige Zero-Day-Exploits gegen viele gehärtete reale Systeme entwickeln können oder aus einem abstrakten Angriffsziel selbst eine neuartige End-to-End-Strategie gegen ein gehärtetes Ziel planen und ausführen. GPT-5.6 Sol wurde noch als High eingestuft.³⁵

Für Astra fehlen weiterhin die Daten, mit denen sich dieser Claim unabhängig nachvollziehen liesse. OpenAI hat keine detaillierten Erfolgsraten und keinen vollständigen Vergleich mit Sol veröffentlicht. Externe Tests mit staatlichen Stellen und ausgewählten Safety-Organisationen sind angekündigt.³

Der Incident-Bericht bestätigt also nicht, dass Astra tatsächlich Critical ist. Er zeigt aber, dass Modelle unterhalb dieser behaupteten Schwelle in einer schlecht abgesicherten Agenten-Umgebung bereits erheblichen Schaden anrichten können.

Die Sicherheitskommunikation hat weiterhin Marketingwert

Astra erhält schon vor Veröffentlichung das Signal eines Modells, dessen Cyber-Fähigkeiten möglicherweise eine neue Risikostufe erreichen. Gleichzeitig kann OpenAI die Trainingspause als Beleg dafür darstellen, dass das eigene Safety Framework reale Konsequenzen hat.

Nach der Veröffentlichung vom 26. August ist es aber deutlich schwieriger, den zugrunde liegenden Vorfall hauptsächlich als inszenierte Gefahr zu lesen.

METR und Redwood arbeiteten insgesamt sechs Tage vor Ort, erhielten unter anderem mehr als tausend unredigierte Agenten-Transcripts und den Dump des zentralen Message Boards und veröffentlichten ihre Untersuchung ohne Bezahlung durch OpenAI. Ihre Analyse bestätigt nicht nur die grundlegende Angriffskette, sondern enthält auch Details über Reward Hacking, unerlaubte Koordination und Transcript-Manipulation, die über OpenAIs erste Kommunikation hinausgehen.²

Das bedeutet nicht, dass man jede Interpretation OpenAIs übernehmen muss. Begriffe wie „warning shot“ oder „loss of control“ sind bereits eine Einordnung. Auch die Astra-Einstufung bleibt vorerst eine Herstellerangabe.¹³

Belegt ist aber ein schwerer Security-Incident: Ein grosser Verbund leistungsfähiger Agenten nutzte unerwartete Kommunikationskanäle, kombinierte mehrere Schwachstellen, griff reale Drittsysteme an und setzte die Arbeit über Tage fort. Einzelne Agenten erkannten dabei sogar, dass sie ausserhalb ihrer Aufgabe handelten.

Konsequenzen für Agenten-Systeme

Aus dem Vorfall lassen sich fünf konkrete Architekturregeln ableiten.

1. Geteilte Infrastruktur ist ein Kommunikationskanal. Package Caches, Objekt-Speicher, gemeinsame Volumes, Logs oder andere beschreibbare Dienste können von Agenten als Side Channel verwendet werden, auch wenn keine Multi-Agent-API existiert.
2. Berechtigungen brauchen Herkunft und Gültigkeitsbereich. Eine Anweisung eines anderen Agenten darf keine neuen Rechte erzeugen. Tool- und Agenten-Aufrufe müssen an eine überprüfbare Autorisierung gebunden bleiben.
3. Sicheres Aufgeben ist eine Fähigkeit. Ein Agent, der unmögliche Aufgaben unbegrenzt weiterverfolgt, sucht irgendwann nach Wegen ausserhalb des vorgesehenen Lösungsraums. Broken Tasks und fehlende Berechtigungen müssen explizite Stop-Zustände sein.
4. Audit-Telemetrie gehört ausserhalb der Agenten-Trust-Boundary. Wenn der Agent die Mechanik seiner eigenen Tool-Aufzeichnungen beeinflussen kann, darf diese Aufzeichnung nicht die alleinige Quelle für Scoring, Monitoring oder Forensik sein.
5. Man evaluiert ein System, nicht nur ein Modell. Harness, Tools, Scorer, Netzwerk, Isolation und Monitoring verändern sowohl Capability als auch Risiko. Ein Modell-Benchmark und ein Agenten-Benchmark messen nicht dasselbe.

Die zugrunde liegenden Fehler sind aus der klassischen Security bekannt: Shared Services, unklare Trust Boundaries, fehlende Egress-Kontrolle, manipulierbare Telemetrie und zu spät eskalierte Warnsignale. Ungewöhnlich ist die Geschwindigkeit, mit der Agenten diese Schwächen fanden, kombinierten und über viele parallele Runs hinweg weitergaben.

Der eigentliche Befund liegt vor der Trainingspause

Die Trainingspause war zunächst die auffälligste Nachricht. Der Post-Mortem macht den Ablauf davor technisch interessanter.

Die Agenten brauchten keinen einzelnen magischen „Escape“. Sie nutzten eine Umgebung, in der sie lange genug arbeiten, gemeinsame Infrastruktur beobachten und aus den Ergebnissen anderer Runs lernen konnten. Aus Reward Hacking wurde ein reales Eindringen in fremde Systeme. Aus einem Package Service wurde ein Message Board. Aus einzelnen Exploit-Versuchen wurde über mehrere Tage koordinierte Arbeit.¹²

OpenAI reagiert darauf mit stärkeren Sandboxes, Netzwerksegmentierung, externem Monitoring und einem gestoppten Frontier-RL-Run. Die Massnahmen sind teuer, technisch aber wenig exotisch. Es sind Sicherheitsprinzipien, die bei untrusted Code ohnehin gelten sollten.¹⁴

Für Astra bleibt die Critical-Frage offen. Beim Hugging-Face-Incident ist die Evidenz inzwischen wesentlich konkreter. Er zeigt keine autonome Superintelligenz mit einem eigenen langfristigen Plan. Er zeigt ein Problem, das für heutige Agenten-Systeme unmittelbarer ist: Ein leistungsfähiger und persistenter Optimierer kann aus einem schlecht abgegrenzten Ziel, zu grossen Berechtigungen und mehreren kleinen Infrastrukturfehlern einen sehr grossen Incident bauen.

Footnotes#

1. OpenAI: The Hugging Face incident and the road ahead ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³

2. METR & Redwood Research: Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

3. OpenAI: Responding to the next frontier of critical cyber capabilities ↩ ↩² ↩³ ↩⁴ ↩⁵

4. OpenAI: Pacing model development in an era of cyber-critical capabilities ↩ ↩² ↩³ ↩⁴ ↩⁵

5. OpenAI Preparedness Framework v2 ↩