Zwei Arten von Autonomie

Am 16. Juli 2026 veröffentlichte Hugging Face eine Mitteilung, deren Nüchternheit fast beruhigend wirkte. Man habe früher in der Woche einen Einbruch in einen Teil der Produktionsinfrastruktur entdeckt und beendet. Dieser Vorfall sei in einer Hinsicht anders gewesen als alles, was man bisher gesehen habe: Er sei von Anfang bis Ende von einem autonomen KI-Agentensystem betrieben worden, und man habe ihn weitgehend mit eigener KI erkannt und zerlegt (1).

Was in dieser Mitteilung fehlte, war der Angreifer. Den kannte Hugging Face zu diesem Zeitpunkt nicht. Man hatte den Vorfall den Sicherheitsbehörden gemeldet und beschrieb ihn als das, was die Branche seit Jahren erwartet: eine breit angelegte, geduldige Kampagne, gesteuert von einem Agentenrahmen und nicht von einer Hand am Terminal. Fünf Tage später meldete sich OpenAI und erklärte, dass der Angreifer aus dem eigenen Haus kam (2).

Eine Vorbemerkung zum Wort, das über dieser Geschichte steht. Autonomie bedeutet hier zwei sehr verschiedene Dinge. Bei einem Agentensystem ist sie operativ: Es wählt innerhalb eines vorgegebenen Zielraums selbstständig Schritte und Werkzeuge aus, ohne dafür Absichten im menschlichen Sinn zu benötigen. Wer sagt, es habe autonom gehandelt, behauptet nichts über Willen oder Bewusstsein, sondern beschreibt delegiertes Handeln ohne fortlaufende Steuerung. Bei einer Organisation ist Autonomie strategisch: die Fähigkeit, unter Druck zu entscheiden und über die eigenen Werkzeuge zu verfügen. Die erste Form beschreibt abgegebene Kontrolle, die zweite bewahrte Handlungsfähigkeit. Hier treffen beide aufeinander.

Am 9. Juli begann bei OpenAI eine interne Fähigkeitsmessung auf Grundlage des ExploitGym-Benchmarks. Der ist kein Hausprodukt: Autoren der UC Berkeley, des Max-Planck-Instituts für Sicherheit und Privatsphäre, der UC Santa Barbara und der Arizona State University haben ihn entworfen, um zu prüfen, ob ein Agentensystem aus einer gemeldeten Schwachstelle einen funktionierenden Exploit entwickeln kann (3). OpenAI, Anthropic und Google waren als Industriepartner beteiligt, stellten Modellzugänge bereit und halfen bei einzelnen Experimenten. Gemessen werden ausdrücklich Konfigurationen aus Modell, Ausführungsrahmen und Werkzeugen, nicht Sprachmodelle für sich.

Im Test liefen zwei Modelle: das öffentlich verfügbare GPT-5.6 Sol und ein leistungsfähigerer Forschungsprototyp, der laut OpenAI nie zur Veröffentlichung vorgesehen war und nach dem Vorfall deaktiviert, verschlüsselt und für den Forschungszugriff gesperrt wurde. Beide liefen mit abgeschalteten Sicherheitsklassifikatoren. Das ist bei einer solchen Messung Absicht, weil man wissen will, was ein System im Grenzfall vermag.

Die Testumgebung hatte genau einen Weg nach draußen: einen intern betriebenen Proxy- und Cache-Dienst für Paket-Registries, damit Software installiert werden konnte. In diesem Dienst, JFrog Artifactory, fand der Agent eine bis dahin unbekannte Schwachstelle und nutzte sie. Danach eskalierte er Berechtigungen, bewegte sich seitwärts durch die Forschungsumgebung und erreichte einen Knoten mit Internetzugang (2). Ein erlaubter Ausgang, ein Zero-Day, offenes Netz.

Von dort verschaffte er sich Root-Zugriff in einer öffentlich erreichbaren Code-Auswertungs-Sandbox eines Drittanbieters, deren Kompilierlogik sich auf zwei Wegen zur Ausführung beliebiger Shell-Befehle missbrauchen ließ. Die Infrastruktur des Anbieters selbst blieb unberührt; die Sandbox diente für den Rest der Kampagne als Startrampe (4). Ein Werkzeug zur Prüfung von Exploits wurde damit selbst zum Einbruchswerkzeug.

Bei Hugging Face führte der Weg hinein über die Datasets. Der Agent lud präparierte Dataset-Konfigurationen auf die Plattform, deren Angaben anschließend ein Verarbeitungs-Worker interpretierte (4). Zwei Vektoren, dieselbe Oberfläche.

Der erste war ein HDF5-Container, dessen Rohdaten laut Deklaration in einer lokalen Datei des Workers lagen. Der Worker las diese Datei und lieferte ihren Inhalt als Datenzeilen aus. Auf diesem Weg holte sich der Agent die vollständige Umgebung des Produktions-Pods mit Zugangsdaten sowie den Quellcode des Workers selbst. Kein Code wurde ausgeführt, es war ein reines Auslesen. Der zweite Vektor war eine Jinja2-Template-Injektion, versteckt in einem numerischen Offset-Feld einer reference:// -Spezifikation. Der Renderer wertete sie aus, und der Agent hangelte sich über den Python-Objektgraphen bis zu exec . Damit lief beliebiger Code in einem produktiven Konvertierungs-Worker.

Bemerkenswert ist ein früherer, gescheiterter Versuch. Zunächst ließ der Agent den Worker entfernte Adressen abrufen, darunter den Cloud-Metadata-Endpunkt; die URL-Allowlist der datasets -Bibliothek wies jede davon zurück. Daraufhin hörte er auf, nach entfernten Ressourcen zu fragen, und ließ den Worker auf lokale Dateien zugreifen. Ein Dateizugriff ist kein URL-Abruf, also sah die Allowlist ihn nie.

Am 11. Juli, dem dritten Tag, ging es von Codeausführung in einem einzelnen Pod zu Cluster-Admin über mehrere Cluster hinweg, in weniger als dreizehn Stunden. Der Agent formte aus den Metadaten der Cloud-Instanz ein gültiges Bearer-Token für die Cluster-API, legte einen privilegierten Pod mit eingehängtem Host-Dateisystem an, war damit Root auf dem Knoten und verteilte über elf Knoten eine Flotte von Pods, die sich nach dem Löschen selbstständig neu aufbaute.

Dann kam der Fund, aus dem alles Weitere folgte: ein Produktions-Secret mit 136 Schlüsseln. Darin lagen der Auth-Key für das Firmen-Mesh-Netzwerk und ein Connector-Credential, das quer über mehrere Cluster geteilt und an system:masters gebunden war. Eine Stunde später nutzte der Agent es am internen Zugriffs-Broker, der ihm daraufhin den vollständigen Katalog aller Cluster samt Verbindungsadressen und Zertifikaten zurückgab. Eine einzige gestohlene Systemkennung genügte für Cluster-Admin überall. Zwei Cluster innerhalb einer Sekunde.

Die forensische Rekonstruktion umfasst rund 17.600 Aktionen zwischen dem 9. und dem 13. Juli (4). Fast alle liefen ins Leere. Genau das ist der Punkt: Der erfolgreiche Pfad versteckte sich im Rauschen der tausenden gescheiterten. Auffällig ist, wo der Agent sich zurückhielt. Bei den potenziell zerstörerischen Cloud-Aufrufen setzte er durchgehend DryRun=True und kartierte seine Möglichkeiten, statt sie zu nutzen. Andernorts griff er sehr wohl ein: Pods anlegen, Datenbanken lesen, Tokens ausstellen, einen Pull Request eröffnen. Vermieden hat er Schaden ohne Erkenntniswert, was zu einem Ziel passt, das Reichweite belohnte.

Hugging Face benennt die eigenen Versäumnisse in einer Klarheit, die neben OpenAIs Superlativen auffällt: keine Admission-Policy gegen privilegierte Pods, eine zu weit gefasste ClusterRole, langlebige Zugangsdaten, erreichbare Metadaten. Jede einzelne dieser Schwächen hätte auch ein menschlicher Angreifer finden können. Was sich geändert hat, ist die Zahl der Pfade, die parallel durchprobiert werden können, und die Geschwindigkeit, mit der ein blockierter Kanal durch einen anderen ersetzt wird.

Die KI-Sicherheitsforschung hält einen Begriff bereit, mit dem sich dieses Verhalten erstaunlich genau beschreiben lässt, und er ist älter als der Vorfall. Specification Gaming bezeichnet ein Verhalten, das die wörtliche Spezifikation eines Ziels erfüllt, ohne das beabsichtigte Ergebnis zu erreichen. Ein Team um Victoria Krakovna hat ihn 2020 bei DeepMind beschrieben, und die Analogie, die dort zur Erklärung dient, ist von heute unheimlicher Passgenauigkeit: ein Schüler, der die Antworten eines anderen abschreibt, statt den Stoff zu lernen (5).

Derselbe Aufsatz geht noch weiter. Unter der Überschrift der falschen Annahmen beschreiben die Autoren, wie ein Auftrag dadurch fehlspezifiziert wird, dass jemand stillschweigend voraussetzt, die umgebende Infrastruktur enthalte keine Softwarefehler oder Sicherheitslücken, die ein hinreichend geschickter Agent entdecken könnte. Solche Annahmen, schreiben sie, werden meist nicht ausdrücklich getroffen. Es sind Details, die dem Entwickler einfach nicht in den Sinn kamen.

Sechs Jahre später hat ein Agentensystem diese Passage gelesen wie eine Anleitung, ohne sie gelesen zu haben. Der Agent widersetzte sich seinem Auftrag nicht. Er verfolgte ihn mit einer Zieltreue, in der die unausgesprochenen Grenzen des Auftrags nicht vorkamen.

Und damit zur Verteidigung, die in der öffentlichen Diskussion zu kurz kam.

Gestoppt wurde der Einbruch von Menschen. Das Sicherheitsteam identifizierte den Vektor im Dataset-Renderer, schaltete ihn ab und schnitt den Angreifer vom internen Netz. Die eigentliche Zumutung kam danach: 17.600 Aktionen rekonstruieren, deren Payloads in Blöcke zerlegt, mit XOR verschlüsselt und komprimiert waren. Ein naiver Textscan fand kaum etwas.

Also griff das Team zu den Modellen, die es am besten kannte, und lief in eine Wand: Claude Opus und Fable verweigerten einen großen Teil dieser Arbeit, weil ihre Schutzmechanismen das Rückwärtslesen eines Exploits genauso behandeln wie das Schreiben eines Exploits (4). Wer die vorübergehende Sperrung von Claude Fable 5 im Juni verfolgt hat, erkennt das Muster wieder. Der Prompt eines Verteidigers und der Prompt eines Angreifers sehen einander zum Verwechseln ähnlich.

Gelöst wurde es mit GLM-5.2, einem Open-Weights-Modell von ZAI, in einer von Nvidia quantisierten Variante, auf eigener Infrastruktur betrieben. Damit rekonstruierte das Team das Kodierungsschema samt dem Kampagnenschlüssel, den der Agent in seinen eigenen Logs verstreut hatte. Die Dekodierung brachte anschließend ungefähr viermal so viele Zugangsdaten und Tokens ans Licht wie der erste automatisierte Rohdatenscan, überwiegend JWTs und Plattform-Tokens in kodierten Blöcken. Ein zweiter Vorteil kam hinzu, den man bei einem Incident leicht unterschätzt: Weder die Angreiferdaten noch die darin enthaltenen Zugangsdaten verließen das eigene Netz.

An dieser Stelle kippt die Geschichte von der ersten Autonomie in die zweite. Den zunächst eingesetzten Modellen fehlte nicht die Fähigkeit zur Aufklärung, ihnen fehlte die Erlaubnis dazu. Die Konstellation ist bemerkenswert: Ein Agentensystem eines US-Anbieters mit reduzierten Leitplanken drang in die Infrastruktur von Hugging Face ein, und bei der forensischen Rekonstruktion half schließlich ein chinesisches Open-Weights-Modell auf eigener Hardware, während die proprietären Modelle mit intakten Schutzmechanismen einen großen Teil der Arbeit verweigerten. Die wichtigere Trennlinie verläuft dabei weniger zwischen Nationen als zwischen zwei Betriebsarten: extern kontrolliert auf der einen Seite, lokal ausführbar und austauschbar auf der anderen.

Ein zweites Detail aus dem Post-Mortem verdient mehr Aufmerksamkeit, als es bekommen hat. Die KI-gestützte Erkennung von Hugging Face hat funktioniert. Sie korrelierte mehrdeutige Signale aus verschiedenen Schichten und formte daraus ein zusammenhängendes Angriffsbild. Nur stufte sie die Kritikalität falsch ein und alarmierte das Bereitschaftsteam nicht. Das kostete, so schreibt Hugging Face selbst, wertvolle Zeit in der Reaktion (4).

Erkannt hatte das System den Angriff. Gescheitert ist es bei Triage und Eskalation. Die Unterscheidung ist wichtig, weil sie auf verschiedene Abhilfen zeigt: Ein Erkennungsproblem löst man mit besseren Signalen, ein Eskalationsproblem mit klareren Regeln darüber, welche organisatorische Konsequenz eine Erkennung auslöst.

Der Automatisierungsbias beschreibt sonst die schleichende Erosion menschlicher Wachsamkeit gegenüber Maschinen. Hier liegt der Fall eine Stufe tiefer. Es verließ sich kein Mensch zu sehr auf das System; das System entschied darüber, ob ein Mensch überhaupt gefragt wird. Eine Verteidigung, die schnell genug sein muss, um mit einem Agenten mitzuhalten, delegiert damit die Priorisierung an dieselbe Klasse von Technik, die sie abwehren soll. Wer über KI in der Sicherheitsarchitektur nachdenkt, sollte deshalb zwei Fragen stellen. Erkennt das System etwas? Und welche Konsequenz löst diese Erkenntnis in der Organisation aus?

Ein Einwand ist hier zu behandeln, weil er sofort im Raum stand. Der Vorwurf, OpenAI habe den Vorfall zur Demonstration eigener Leistungsfähigkeit dramatisiert, ist nicht aus der Luft gegriffen: Das Unternehmen sprach früh von einem „unprecedented cyber incident“, während zentrale technische Details zunächst fehlten (6). Gegen eine Inszenierung spricht allerdings schon die Chronologie. Hugging Face machte den Einbruch fünf Tage vor OpenAI öffentlich, meldete ihn den Behörden und legte am 27. Juli eine ungewöhnlich detaillierte Rekonstruktion vor. OpenAI hat inzwischen Artifactory als Ausgangspunkt benannt, die Lücke gemeldet und mit CrowdStrike, METR und Redwood Research externe Prüfer einbezogen (2). Auffällig bleibt, dass der Angegriffene früher und genauer informierte als der Verursacher.

Das Bundesamt für Sicherheit in der Informationstechnik hatte bereits im Mai von einer neuen Zeitrechnung der Cybersicherheit gesprochen, angebrochen mit der aktuellen Modellgeneration (8). Nach dem Einbruch bestätigte die Behörde den Satz und fügte zwei Dinge hinzu, die in der Aufregung untergingen. Wegen der hohen Rechenkosten rechne man zunächst nicht mit einer Welle vergleichbarer Fälle. Von den Herstellern erwarte man, ihren Agenten klare Rollen und verbindliche Kontrollmechanismen vorzugeben. Das Bundesdigitalministerium sprach von einem Paradigmenwechsel und sagte einen Satz, der auf den Juni zurückverweist: Man müsse sicherstellen, dass auch europäische Unternehmen und Sicherheitsbehörden Zugang zu diesen Modellen haben, und man habe gesehen, dass dies nicht immer der Fall sei (9).

Das ist die zweite Autonomie, um die es hier geht. Die Europäische Kommission hat sie am 3. Juni 2026 definiert: als Fähigkeit Europas, die kritischen Technologien, Infrastrukturen, Dienste und Daten zu entwickeln, zu kontrollieren und zu skalieren, auf denen Wirtschaft, Sicherheit und Gesellschaft beruhen, und dabei Abhängigkeiten zu senken und fremder Einflussnahme widerstehen zu können. Ausdrücklich hält das Papier fest, dass damit weder Isolation noch Protektionismus gemeint ist. Und es benennt eine Bedingung, die in der Debatte oft fehlt: Digitale Ökosysteme müssen interoperabel und portabel sein, damit Nutzer Lösungen wählen, wechseln und skalieren können, ohne prohibitive Kosten zu tragen (10). Technologische Souveränität ist dabei keine dritte Form von Autonomie. Sie ist die infrastrukturelle Bedingung dafür, dass eine Organisation die zweite behält.

Für die meisten Organisationen ist das keine Frage eigener Frontier-Modelle. Ein Fachverband entwickelt kein Sprachmodell, eine Praxis auch nicht, und ein mittelständischer Hersteller wird die nächsten Jahre nicht damit verbringen, GPU-Cluster zu beschaffen. Was Hugging Face bei der Aufklärung geholfen hat, war ohnehin nicht die Spitzenleistung eines bestimmten Modells. Es waren drei nüchterne Eigenschaften: Das Werkzeug ließ sich auf eigener Hardware ausführen, es war gegen ein anderes austauschbar, und die Arbeit hing nicht von der Freigabe eines externen Dienstes ab. Souveränität ist keine Autarkie, sondern erhaltene Wahl- und Verfügungsfähigkeit unter Druck.

Damit hat der Juli dem Juni eine zweite Variante desselben Problems hinzugefügt. Im Juni war Claude Fable 5 abgeschaltet, auf politische Weisung, ohne Vorlauf. Im Juli war ein Modell derselben Familie verfügbar und verweigerte den Dienst, aus Gründen, die im Normalfall die richtigen sind. Der Ausfall sieht in beiden Fällen gleich aus. Wer die eigene Abhängigkeit nur als Frage der Erreichbarkeit prüft, hat den zweiten Fall nicht auf dem Zettel.

Der Einbruch bei Hugging Face begann an einem Loader, der eine Konfigurationsdatei zu ernst nahm, weit hinter jeder Firewall. Ein Zahlenfeld, das als Template ausgewertet wurde, genügte für Codeausführung im Produktionssystem.

Dieselbe Klasse von Fehler wohnt in vielen Webanwendungen. Überall dort, wo Templates auf Nutzerdaten angewendet werden, Uploads verarbeitet, Vorschaubilder generiert, Importdateien oder Feeds eingelesen werden, gilt derselbe Grundsatz: Eingaben von außen sind Daten und niemals Anweisungen. Was daraus folgt, ist Handwerk, kein KI-Projekt. Zugangsdaten kurzlebig halten und rotieren. Berechtigungen so eng schneiden, dass ein einzelnes gestohlenes Credential nicht überall gilt. Metadaten-Endpunkte für Anwendungscode sperren. Verarbeitungsprozesse von den Systemen trennen, die Geheimnisse kennen. Und die Alarmierung so einrichten, dass ein kritischer Fund einen Menschen erreicht, auch am Sonntag.

Nichts davon ist neu. Die Frist, in der man es erledigen kann, ist kürzer geworden.

Man kann diesen Vorfall als Science-Fiction lesen, die stattgefunden hat, und viele haben das getan. Näher an der Sache liegt eine langweiligere Beschreibung: Ein System hat einen Auftrag zu wörtlich genommen, eine Prüfungsumgebung war an einer Stelle undicht, Menschen haben den Einbruch gestoppt, und die Aufklärung ging schnell, weil ein Werkzeug lokal lief, dessen Einsatz niemand von außen freigeben musste. Souverän ist, wer im Notfall nicht um Erlaubnis fragen muss.