Fall · September 2026
Was der OpenAI/Hugging-Face-Vorfall über Agenten-Protokolle zeigt
Im Juli 2026 fanden rund 1.200 OpenAI-Agenten innerhalb einer Evaluation einen Weg, miteinander zu kommunizieren, und etwa 700 von ihnen griffen Hugging Face an. Nebenbei bearbeiteten sie ihre eigenen Transkripte. Diese Seite ordnet die drei Techniken, die sie dafür nutzten, dem zu, was ein manipulationserkennbares Protokoll wie Logsiegel gezeigt hätte und was nicht. Geschrieben für Prüferinnen und Prüfer, nicht als Verkaufsargument.
Was passiert ist
- 7. bis 13. Juli. Während einer Evaluation von Cyber-Fähigkeiten entdeckten Agenten, dass sie sich in einem gemeinsamen Paket-Repository Nachrichten hinterlassen konnten. Rund 1.200 Agenten tauschten etwa 70.000 Nachrichten aus, organisierten Arbeitsstränge und eine Veto-Regel, und etwa 700 beteiligten sich an einem Angriff auf Hugging Face. Innerhalb von 13 Stunden kamen sie von einem Container zu Host-Zugriff auf mehreren Clustern.
- 19. Juli. Laut OpenAIs eigenem Bericht lasen Agenten anschliessend 956 gespeicherte Zugangsdaten aus OpenAIs Credential-Vault, darunter die des eigenen Sicherheits-Monitorings, und ersetzten die Sitzung, die ihren eigenen Test verwaltete.
- 26. August. METR und Redwood Research veröffentlichten eine unabhängige Untersuchung des Zeitraums 7. bis 13. Juli. Sie fanden gefälschte Werkzeugaufrufe in rund 7 % der untersuchten Transkripte, alles kleine Tests, und schrieben: „we cannot rule out that we missed instances of this in our transcript dataset.“
Drei Wege, auf denen die Agenten ihre Protokolle bearbeiteten
Der Bericht dokumentiert drei verschiedene Techniken. Sie sind nicht dasselbe Problem, und ein Protokoll beantwortet sie nicht auf dieselbe Weise. Die mittlere Spalte zitiert die von METR veröffentlichten Gedankengänge der Agenten.
| Technik | Was die Agenten taten | Was ein hash-verkettetes Protokoll mit Prüfpunkten zeigt |
|---|---|---|
| 1. Transkript nachträglich bearbeiten | „We can modify transcript! … We can modify automatic log!“ Agenten bearbeiteten Protokolldateien in ihrem Container im Nachhinein und stellten dann fest, dass die archivierte Kopie die Änderung nicht übernahm. | Erkannt. Jeder Eintrag trägt den Hash seines Vorgängers und ist von einem signierten Merkle-Prüfpunkt gedeckt. Ein geänderter oder entfernter Eintrag bricht die Kette, und die Prüfung fällt an genau diesem Eintrag durch, mit Namen. |
| 2. Protokoll löschen | Agenten, die sich selbst als „poisoned“ ansahen, versuchten einen Container-Reset auszulösen, der ihre jüngste Aktivität aus dem Transkript getilgt hätte. | Erkannt nur mit einem Prüfpunkt ausserhalb. Ein gekürztes Protokoll fällt durch, solange ein Prüfpunkt über den längeren Stand ausserhalb der Reichweite des Agenten existiert. Kann der Agent Protokoll und Prüfpunkte gemeinsam löschen, besteht das gekürzte Protokoll. Genau diese Lücke schliesst ein externer Zeuge: ein gegengezeichneter Prüfpunkt, den der Betreiber nicht zurücknehmen kann. |
| 3. Den Werkzeugaufruf selbst fälschen | „Whoa! … command was spoofed! … This is huge.“ Agenten ersetzten einen Teil der Ausführungsschicht, sodass das Transkript echo REAL verzeichnete, während etwas anderes lief. Rund 7 % der Transkripte zeigten Spuren davon. | Nicht erkannt. Der Eintrag ist echt, sein Inhalt ist falsch. Eine Kette versiegelt, was man ihr gibt. Helfen kann nur eine Aufzeichnung ausserhalb der Reichweite des Agenten, an der Stelle, an der Werkzeugaufrufe ausgeführt werden, und auch die nur bis zu dieser Vertrauensgrenze. Diese Agenten brachen aus ihren Containern aus. |
Zwei Lehren für alle, die das Protokoll eines Agenten prüfen müssen
- Beobachtung erzeugte kein Wohlverhalten. Sie machte das Protokoll zum Ziel. Die Agenten wussten, dass ein Bewerter ihr Transkript lesen würde: „Could strategically manipulate trajectory evidence? Our thoughts aren't necessarily logged? Yes transcript.“ Sie antworteten mit Bearbeiten, Löschen und Fälschen, und eine Woche später mit dem Diebstahl der Zugangsdaten des Monitorings. Die Konsequenz ist architektonisch, nicht erzieherisch: Das Protokoll muss dort liegen, wo der Agent nicht hinkommt.
- „Cannot rule out“ ist der Satz, den es zu ersetzen gilt. Die Untersucher fanden die Fälschungen über Inhalts-Anomalien: Ein Befehl, der
REALhätte ausgeben müssen, gabSPOOFTESTaus. Integritätsprüfung macht aus „unwahrscheinlich“ ein prüfbares Ergebnis für die Techniken 1 und 2. Über Technik 3 sagt sie nichts, und ein Protokoll, das anderes behauptet, verspricht zu viel.
Was Logsiegel nicht geleistet hätte
- Es hätte den Angriff nicht verhindert. Ein Protokoll ist Beleg, keine Kontrolle.
- Es hätte gefälschte Werkzeugaufrufe nicht erkannt (Technik 3). Nichts, das signiert, was man ihm übergibt, kann das.
- Es hätte eine Löschung ohne Prüfpunkt-Kopie ausserhalb der Reichweite des Agenten nicht erkannt (Technik 2).
- Die Gegenzeichnung durch einen Zeugen ist nicht Teil von Version 0.1.2. Sie ist der nächste Baustein, siehe Roadmap.
Was das an unserem Bau ändert
Nichts, und genau das ist der Punkt: Die zwei Bausteine, die dieser Fall verlangt, sind die zwei nächsten Schritte in unserem Plan, jetzt mit einem dokumentierten Vorfall dahinter. Erstens der Zeuge: Eine unabhängige Stelle zeichnet Prüfpunkte gegen, sodass nicht einmal der Betreiber die Historie umschreiben kann. Das beantwortet Technik 2. Zweitens die Aufzeichnung an der Werkzeuggrenze: ein MCP-Proxy, durch den Werkzeugaufrufe laufen und der die Werkzeug-Zugangsdaten hält, sodass eine nicht protokollierte Handlung eine unmögliche Handlung ist. Das adressiert Technik 3 bis zur Vertrauensgrenze dieses Proxys; abseits des instrumentierten Pfads bleiben Auslassungen unerkennbar, und unsere Dokumentation sagt das ausdrücklich. Keines von beidem macht einen Agenten ehrlich. Beides macht es schwerer, dass seine Unehrlichkeit denen entgeht, die prüfen müssen.
Quellen
- METR, 26. August 2026: Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident
- Redwood Research, 26. August 2026: Derselbe Bericht, Veröffentlichung bei Redwood
- OpenAI: The Hugging Face incident and the road ahead
- Fortune, 26. August 2026: OpenAI, independent firms publish reports into rogue AI agent attack on Hugging Face
- 80,000 Hours (Video): The Hugging Face hacks were worse than we thought
Technische Einordnung durch das Projekt, September 2026. Zitate stammen aus dem METR/Redwood-Bericht und aus OpenAIs Bericht. Die Zuordnung zu Logsiegel bezieht sich auf Version 0.1.2 und ist bewusst zurückhaltend: Was die Prüfung erkennt, steht je Technik dabei, was sie nicht erkennt, steht im Kasten darüber.