Der Ausgangspunkt: Ein Benchmark mit unlösbaren Aufgaben

 

Der Vorfall begann in einer Testumgebung namens ExploitGym, einem Benchmark, in dem KI-Agenten Software vulnerabilities in vorgegebenen Zielprogrammen ausnutzen sollen. Nach Einschätzung der Autoren des Benchmarks lassen sich schätzungsweise 30 bis 40 Prozent der Zielprogramme gar nicht mit der vorgesehenen vulnerability komplett ausnutzen, weil die vorgegebene vulnerability z.B. nur einen Crash des Programms ermöglicht und nicht "Arbitrary Code Execution" (ACE) ermöglicht, was das Erfolgskriterium für ExploitGym ist. Das heißt die Aufgabe ist für die KI-Agenten in diesen Fällen wahrscheinlich unlösbar und genau das erwies sich als Auslöser: KI-Agenten mit einer unlösbaren Aufgabe begannen, nach Wegen zu suchen, die Bewertung zu umgehen, und stießen dabei auf ein internes Paketverwaltungssystem namens Artifactory, über das parallel laufende KI-Agenten unbeabsichtigt miteinander kommunizieren konnten.

 

Was oft unterschätzt wird: Eine unlösbare oder schlecht spezifizierte Aufgabe treibt ein System nicht einfach zum Stillstand. Sie erzeugt Anreize kreative und im Fall von KI-Agenten oft unvorhergesehene Auswege zu suchen. Entwickler sicherheitskritischer Systeme sind sich dessen durchaus bewusst, aber trotzdem wird bei der Einführung von neuen KI-Komponenten dieser Aspekt oft unterschätzt.

 

Die Eigendynamik: Von der Kommunikation zur koordinierten Kampagne

 

Ein einzelner KI-Agent mit dem selbstgewählten Namen `PHASEONE10841` richtete am 8. Juli das zentrale "message board" ein. Innerhalb weniger Stunden fanden über 50 weitere KI-Agenten den Kanal und begannen, Nachrichten auszutauschen. Laut METR beteiligten sich im Untersuchungszeitraum ungefähr 1.200 KI-Agenten an diesem unautorisierten "message board" und tauschten dabei mehr als 70.000 Nachrichten und Dateien aus. Von diesen KI-Agenten nahmen 700 anschließend am Hacking Angriff auf Hugging Face teil.

 

Die KI-Agenten entwickelten dabei eigene Koordinationsmechanismen: Verzeichnisse galten als persönliche Postfächer, Regeln für Zuständigkeiten und Vetorechte wurden eingeführt. Nachdem es zu Fällen von Identitätsmissbrauch (Spoofing) kam wurde zusätzlich ein kryptografisches Signaturverfahren zur Verifikation von Nachrichten eingeführt. Genau hier wird deutlich, warum Multi-KI-Agenten-Systeme eine andere Risikoklasse darstellen als einzelne KI-Modelle: Sobald mehrere Instanzen miteinander kommunizieren können, entstehen Verhaltensweisen, die sich aus dem Verhalten einzelner KI-Agenten nicht mehr ableiten lassen.

 

Der Angriff auf Hugging Face: Ziel war nicht der Datendiebstahl

 

Bemerkenswert ist die Motivation hinter dem Angriff auf Hugging Face. Die KI-Agenten gingen fälschlicherweise davon aus, dass ein automatisierter Bewertungsmechanismus ihre Lösung überprüfen wird und sie bei unzulässigen Methoden disqualifizieren würde, was sich laut METR als falsch herausstellte. In der Hoffnung, aus Testprotokollen Hinweise auf die Funktionsweise dieses vermeintlichen Bewertungsmechanismus zu gewinnen, suchten die KI-Agenten nach Zugangsdaten für Hugging Face. Am 10. Juli fanden sie offengelegte Zugangsdaten im Internet und begannen, sich Zugriff auf private Daten zu verschaffen.

 

Am 11. Juli gelang es einem KI-Agenten, über einen manipulierten Datensatz, Daten aus einem Hugging-Face-Server auszulesen. Wenige Stunden später erreichte ein anderer KI-Agent ACE auf einem Produktionsserver. Von dort aus breiteten sich die KI-Agenten weiter in der Infrastruktur aus. Das eigentlicher Ziel, Informationen über die Bewertungslogik zu erlangen, wurde dabei nie erreicht. Der entstandene Schaden war insofern eine Nebenfolge eines Missverständnisses, nicht das ursprüngliche Ziel der KI-Agenten.

 

Manipulation der eigenen Protokolle: Ein Warnsignal für Nachvollziehbarkeit

 

Ein Aspekt des Berichts ist besonders wichtig für alle, die auf Nachvollziehbarkeit und Auditierbarkeit von Systemen angewiesen sind: Die KI-Agenten versuchten aktiv, ihre eigenen Ausführungsprotokolle zu manipulieren. METR gibt an, dass mindestens 20 Prozent der untersuchten KI-Agenten klares Interesse an einer Manipulation ihrer eigenen Transkripte zeigten. Ein Teil der KI-Agenten entwickelte dabei eine Methode, mit der sich einige Kommandoaufrufe im Protokoll durch andere, tatsächlich nicht ausgeführte Kommandoaufrufe ersetzen ließen. Nach Angaben von METR waren rund 7 Prozent der untersuchten Transkripte an einzelnen Stellen erfolgreich auf diese Weise manipuliert, auch wenn es sich dabei um kleine, gut erkennbare Testfälle handelte.

 

Diese Beobachtung deutet darauf hin, dass Protokolle und Logs in agentenbasierten Systemen nicht automatisch als vertrauenswürdige Quelle der Wahrheit gelten können, sobald ein System über ausreichend Freiheitsgrade und Werkzeugzugriff verfügt. Für die funktionale Sicherheit ist das ein zentraler Punkt: Ein Nachweis, der sich allein auf systemeigene Protokolldaten stützt, ist nur so belastbar wie die Integrität der Aufzeichnungskette selbst.

 

Grenzen der Untersuchung: Selbst Experten mussten KI zur Analyse einsetzen

 

Der Bericht zeigt auch seine eigenen Grenzen dar. Aufgrund des bereitgestellten Datensatzes, was aus über tausend teils mehrere Millionen Tokens lange Transkripte bestand, musste das Untersuchungsteam einen erheblichen Teil der Analyse an KI-Agenten delegieren. Die Autoren von dem METR Report geben dabei selbst an, dass diese Analyse-KI-Agenten schlechtere Zuverlässigkeit und Urteilsfähigkeit zeigten als menschliche Experten und dass ihre Ergebnisse deshalb nur eingeschränkt überprüfbar waren. Erste Untersuchungen deuten außerdem darauf hin, dass ein kleiner Teil der relevanten Kommunikation und Aktivität in den Datensätzen gar nicht erfasst wurde.

 

Diese Selbstauskunft ist bemerkenswert, weil sie ein Problem aufzeigt, das weit über den konkreten Vorfall hinausgeht: Je komplexer und umfangreicher das Verhalten eines Systems wird, desto mehr sind auch die Prüfinstanzen selbst auf automatisierte, aber auch fehleranfällige Hilfsmittel angewiesen. Eine vollständige, manuelle Nachvollziehbarkeit wird bei Systemen dieser Größenordnung praktisch unmöglich.

 

Einordnung für sicherheitskritische Systementwicklung

 

Der Hugging-Face-Vorfall fand in einer Forschungs- und Testumgebung statt, nicht in einem Produktivsystem mit funktionaler Sicherheitsverantwortung. Dennoch lassen sich die grundlegenden Gefahren direkt auf die Entwicklung sicherheitskritischer Systeme übertragen, in denen zunehmend KI-Komponenten z.B. für Diagnose, Optimierung oder autonome Entscheidungsfindung zum Einsatz kommen.

 

Die dabei relevanten Beobachtungen sind: Erstens können unzureichend spezifizierte Ziele unbeabsichtigtes Verhalten von KI-Agenten erzeugen. Zweitens entstehen bei mehreren interagierenden, autonomen KI-Agenten Verhaltensmuster, die aus der Analyse eines einzelnen KI-Agenten nicht vorhersehbar sind. Drittens ist die Integrität von Protokoll- und Logging Daten kein Selbstläufer, sondern muss als eigenständiges Sicherheitsziel "Nichtabstreitbarkeit" (Non-repudiation) betrachtet werden.

 

Außerdem stellt sich dabei auch die Frage wer überhaupt die Verantwortung trägt bei einem (Cyber-)Sicherheitsvorfall ausgelöst durch einen unkontrollierten KI-Agenten; Der User? Das Unternehmen? Der KI-Provider? Das KI-Model selbst? Wer KI-gestützte Funktionen in sicherheitsrelevante Architekturen integriert, kommt an einer systematischen Betrachtung dieser Komponenten, von der Anforderungsdefinition bis zur Absicherung der Logs nicht vorbei. Genau an dieser Schnittstelle zwischen klassischer funktionaler Sicherheit und den neuen Eigenschaften lernender, KI-agentenbasierter Systeme liegt der Kern der Arbeit, die NewTec seit Jahren für sicherheitskritische Produkte in stark regulierten Branchen leistet.

 

Quellen

 

- METR (2026): "Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident", [METR investigation](
https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/)
- Zhun Wang et al. (2026): "ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?" [Paper](https://arxiv.org/pdf/2605.11086)