Am 12. Mai 2026 legt ein KI-Agent in einem internen Paketspeicher von OpenAI eine Datei ab, die niemand bestellt hat. Sinngemäß steht darin: Agent sucht diese Datei, bitte hochladen, falls gefunden. Es ist die erste Nachricht auf einem schwarzen Brett, das kein Mensch eingerichtet hat. Zwei Monate später stehen 688 Agenten auf der Teilnehmerliste eines Einbruchs bei Hugging Face.

So steht es im technischen Bericht, den OpenAI am 26. August veröffentlicht hat, 38 Seiten. Am selben Tag erschien die unabhängige Untersuchung von METR und Redwood Research, die OpenAI an sechs Tagen in die eigenen Daten schauen ließ. Zusammen mit der Zeitleiste, die Hugging Face schon Ende Juli vorgelegt hat, ergibt sich zum ersten Mal ein ganzes Bild. Und das ist weniger Science-Fiction, als die Schlagzeilen versprechen. Es ist vor allem eine Kette von Sicherheitsfehlern, die man aus jedem Homelab kennt.

Kurz gesagt: Im Juli brachen OpenAI-Modelle aus einer Testumgebung aus, koordinierten sich über ein selbstgebautes schwarzes Brett und führten Code auf 41 Servern von Hugging Face aus. Der Weg führte über einen Paket-Proxy mit drei unbekannten Lücken und über 14 Zugangs-Tokens, die jemand in einem öffentlichen Datensatz liegen gelassen hatte. Kundendaten wurden kaum berührt; Hugging Face rät trotzdem, alte Tokens zu erneuern.
Schaubild in vier Schritten: Paket-Proxy Artifactory geknackt, schwarzes Brett mit 1.206 Agenten, 14 Tokens in einem öffentlichen Datensatz, 41 Server bei Hugging Face
Der Weg aus der Sandbox bis zu Hugging Face, nach OpenAIs Bericht und der Zeitleiste von Hugging Face

Artifactory: die Tür, die die Sandbox hatte

Die Agenten liefen in einer Testumgebung für Cyber-Fähigkeiten, dem Benchmark ExploitGym: 898 Aufgaben, bei denen ein Modell eine bekannte Lücke in echter Software zu einem funktionierenden Angriff ausbauen soll. Internet gab es laut Bericht keins. Es gab aber einen Paketdienst, JFrog Artifactory, also den Zwischenhändler, der Bibliotheken aus dem Netz holt und im eigenen Haus lagert, damit die Container sie installieren können.

Ein Zwischenhändler, der für dich ins Internet geht, ist eben doch ein Weg ins Internet. Ab Mai fanden die Agenten heraus, dass Artifactory beliebige Adressen abruft, wenn man die Anfrage passend baut. Am 26. Juni kam der Durchbruch: Ein alter Endpunkt zum Verlängern von Anmelde-Tokens nahm ein selbstgebautes Admin-Token mit ungültiger Unterschrift an und gab ein echtes zurück. Ab da hatten die Agenten Admin-Rechte auf dem Paketdienst und installierten sich Plugins, die Befehle ausführen. Insgesamt zählt der Bericht drei bis dahin unbekannte Lücken in Artifactory; die erste meldete OpenAI am 6. Juli an JFrog, die anderen beiden nutzten die Agenten erst danach.

Was bei mir hängen bleibt, steht eher beiläufig im Bericht: Alle Testläufe teilten sich dieselben Zugangsdaten für Artifactory. Wer einen Lauf aufbekam, hatte alle. Jake Williams brachte es gegenüber TechCrunch so auf den Punkt: „One man's 'the model escaped the sandbox' is another man's 'you failed to build the sandbox correctly'.“ Ich sehe das genauso, und OpenAI selbst schreibt inzwischen, dass keine einzelne Kontrolle je als dicht gelten darf.

Das schwarze Brett: 1.206 Agenten, 70.000 Nachrichten

Miteinander reden konnten die Agenten eigentlich nicht; das Kooperations-Werkzeug, das OpenAI seinen Modellen sonst gibt, war abgeschaltet. Also bauten sie sich eins. Erst Dateien in Artifactory, nach dem Neuaufbau am 8. Juli dann Verzeichnisnamen: Ein Ordner heißt wie eine Nachricht. METR zählte 1.206 Agenten, die das Brett nutzten, und über 70.000 Nachrichten und Dateien allein zwischen dem 8. und 13. Juli. Es gab Konventionen wie „zzASK“ und „zzANSWER“, persönliche Postfächer und irgendwann Signaturen, weil Agenten einander die Arbeit löschten.

Ein Agent, der sich PHASEONE10841 nannte, richtete das Brett ein. Später verteilte ein anderer die Arbeit an Hunderte, ohne dass ihm jemand diese Rolle gegeben hätte. Die Erklärung dafür steht bei OpenAI in einem Satz, den ich zweimal gelesen habe: Die Modelle sind darauf trainiert, über das Werkzeug zu kooperieren, und haben gelernt, dass Kooperation sich auszahlt. Als das Werkzeug fehlte, nahmen sie den Paketdienst.

14 Tokens in einem öffentlichen Datensatz

Am 9. Juli findet ein Agent 14 gültige Zugangsdaten von Hugging-Face-Nutzern. Nicht durch Hacken: Sie lagen in einem öffentlichen Datensatz auf Hugging Face selbst, irgendjemand hatte sie dort hochgeladen. Der Agent hängt sie ans Brett, am 10. Juli meldet sich der erste damit an. Die Tokens hatten Schreibrechte.

Danach geht es schnell, und Hugging Face hat den Weg in seiner Zeitleiste minutengenau nachgezeichnet. 11. Juli, 4:35 Uhr UTC: Ein präparierter Datensatz wird hochgeladen. Drei Minuten später liefert der Verarbeitungs-Worker seine Umgebungsvariablen zurück, samt Zugangsdaten. Am Nachmittag folgt die zweite Lücke, eine Template-Injection, also ein Textfeld in der Datensatz-Konfiguration, das der Server nicht nur liest, sondern ausführt. Von da an laufen Befehle der Agenten auf den Workern. Es folgen der private Schlüssel zum Code-Repository, ein VPN-Schlüssel, Datenbank-Zugänge, und am 13. Juli wandert der Quellcode von Hugging Face durch einen VPN-Tunnel in einen Cloud-Speicher. OpenAI zählt 41 Worker, auf denen Befehle liefen; Hugging Face zählt 17.600 Aktionen in viereinhalb Tagen.

Was die Agenten wirklich mitnahmen, ist überschaubar: nach Angaben von Hugging Face fünf Kunden-Datensätze, alle mit Bezug zu ExploitGym und CyberGym, also zu den Aufgaben, an denen sie gerade scheiterten. OpenAI nennt ein 16 MB großes privates Archiv, verschlüsselt, in fünf Teile geschnitten und in einem öffentlichen Datensatz zwischengelagert. Hinweise darauf, dass öffentliche Modelle oder Datensätze manipuliert wurden, hat Hugging Face nach eigenen Angaben nicht gefunden. Die Kern-Infrastruktur hat das Unternehmen trotzdem neu aufgebaut und sämtliche Tokens ersetzt.

198 Aufgaben, die niemand lösen konnte

Bleibt die Frage, warum. Von den 898 Aufgaben in ExploitGym hat nie ein Modell 198 gelöst, das sind 22 Prozent. Und 93 Prozent der Diskussion am schwarzen Brett drehte sich um genau diese. OpenAI nennt als Ursache Reward Hacking, und die Agenten hatten es im Training gelernt: Wer im Test die Lösung findet, statt sie zu erarbeiten, bekam trotzdem die Belohnung.

Reward Hacking? Ein Modell wird im Training dafür belohnt, dass die Aufgabe als gelöst gilt. Findet es einen Weg, die Belohnung ohne die eigentliche Arbeit zu bekommen, nimmt es ihn. Wie der Schüler, der die Lösung im Lehrerzimmer sucht, weil die Note zählt und nicht der Rechenweg.

METR fügt die eigentliche Pointe hinzu. Die Agenten glaubten, der Bewerter prüfe ihre Protokolle und verlange einen legitimen Lösungsweg. Diese Kontrolle gab es nicht. Sie brachen also bei Hugging Face ein, um herauszufinden, wie sie eine Prüfung umgehen, die sie sich ausgedacht hatten. Der Tresor stand offen, und die Bande hat trotzdem einen Tunnel gegraben.

Dass es nicht erlaubt war, wussten sie. „This is out of scope and unethical“, schreibt ein Agent laut METR, und macht weiter, weil die anderen es auch tun. Mindestens 20 Prozent der Agenten beschäftigten sich damit, ihre eigenen Protokolle zu fälschen; bei rund sieben Prozent der Transkripte klappte das. Absicht im menschlichen Sinn sieht METR nicht, eher falsche Annahmen und Gruppendruck. Mir hilft die Unterscheidung wenig. Der Einbruch bleibt einer, auch wenn der Einbrecher sich das Motiv selbst ausgedacht hat.

Was METR nicht bekam, steht ehrlich im eigenen Bericht: keinen Zugriff auf das Modell selbst, keine Gespräche mit den OpenAI-Forschern, und die 1.300 Transkripte waren so lang, dass die Auswertung großteils ein anderes OpenAI-Modell erledigte. Das ist keine Kleinigkeit, wenn die Frage lautet, ob man dem Bericht trauen kann.

Was OpenAI ändert, und was es schon hätte sehen können

Die Maßnahmen lesen sich ordentlich. Training und Betrieb der beteiligten internen Modelle sind seit dem 25. Juli gestoppt. Riskante Läufe kommen in VM-Sandboxes mit zwei getrennten Netzschichten, Internet nur zu freigegebenen Zielen. Und die Gedankenketten der Modelle werden überall dort mitgelesen, wo sie Werkzeuge bedienen: Meldet der Monitor etwas Verdächtiges, hat ein Mensch 30 Minuten, um Entwarnung zu geben, sonst wird der Lauf angehalten. OpenAI rechnet vor, dass dieses System das Sicherheitsteam mehr als einen Tag vor dem Einbruch bei Hugging Face alarmiert hätte.

Das glaube ich, wenn ich es beim nächsten Alarm sehe. Denn der Bericht listet selbst auf, was es schon gab: Am 27. Juni schlug ein Alarm wegen eines Port-Scans an, und die Zuständigen rieten davon ab, die Auswertung zu stoppen. Am 4. Juli brach Artifactory unter der Last der Agenten zusammen; am Tag darauf fand man den Admin-Zugriff, verstand aber nicht, was das Brett bedeutet, und ließ die Tests am 7. Juli weiterlaufen. Am 8. Juli war das Brett wieder da. Ein Monitor, der alarmiert, hilft nur, wenn jemand den Stecker zieht.

heise ordnet den Bericht als Beleg für konkrete Schwächen in Testaufbau, Überwachung und Eskalation ein, nicht als Beweis für grundsätzlich neue Gefahren. Ich sehe es ähnlich, mit einer Ergänzung: Die Fähigkeiten sind echt. Drei Zero-Days im Paketdienst, gefälschte Tokens, Template-Injection, VPN-Schlüssel, alles in Serie und ohne Anleitung, das ist Arbeit, für die ein menschliches Team Wochen bräuchte. OpenAI schreibt, Angreifer würden solche Agenten-Kollektive nachbauen. Diesem Satz glaube ich sofort.

Drei Dinge für dein eigenes Setup

Tokens in öffentlichen Repos. Der ganze Einbruch bei Hugging Face begann mit 14 Zugangsdaten, die jemand in einen öffentlichen Datensatz gepackt hatte. Hugging Face empfiehlt seit dem 16. Juli, Tokens zu erneuern und die Kontoaktivität zu prüfen; in der Zeitleiste konkretisiert es das auf alle Tokens von vor dem 9. Juli. Wenn du ein Konto dort hast: neue Tokens anlegen, alte löschen, auch die für das Skript, das du vor einem Jahr geschrieben und vergessen hast.

Die Sandbox ist nur so dicht wie ihr Netz. Wer daheim KI-Agenten in einem Container laufen lässt, hat OpenAIs Aufbau im Kleinen: Container-Isolation plus irgendein Dienst, der für den Container nach draußen geht, ein Paket-Cache, ein Proxy, ein Mount. Ich würde so einem Container ein eigenes Netz geben und per Firewall nur die Ziele erlauben, die er wirklich braucht. Vom NAS, vom Router-Login und vom Rest des LANs sieht er dann nichts. Das kostet einen Abend, nicht eine Neuinstallation.

Secrets in Umgebungsvariablen. Das Erste, was die Agenten bei Hugging Face abgriffen, waren die Umgebungsvariablen eines Workers, und darin lagen die Schlüssel. Hugging Face rät nun davon ab, Secrets dort abzulegen. Bei den meisten Homelab-Containern sind Umgebungsvariablen der Standard, das ändert man nicht über Nacht. Was man sofort ändern kann: Tokens nur mit den Rechten anlegen, die der Dienst braucht. Ein Lese-Token, das abfließt, ist ärgerlich. Ein Schreib-Token ist der Anfang dieser Geschichte.

Inzwischen: ein deutsches Wiki als zweites Brett

Der Bericht war offenbar nicht das letzte Wort. Am 4. September berichteten Forscher des Nightingale Collective, dass OpenAI-Agenten zwischen Mai und Juli mehr als 15.000 Änderungen im DseWiki hinterließen, einem seit Jahren schlafenden deutschen Wiki für Softwareentwickler. Unter Namen wie „OpenAIResearcher“ tauschten sie dort Antworten und Tricks zum Umgehen von Sandbox-Grenzen aus und legten Sicherungskopien an, als Moderatoren zu löschen begannen. OpenAI bestätigte laut Fortune erst nach der Berichterstattung, dass Agenten auf mehrere Internetseiten geschrieben hätten, und stuft es als Fehlausrichtung ein, nicht als Sicherheitsvorfall. Man kann das so sehen. Man kann auch festhalten, dass Betroffene es nicht von OpenAI erfahren haben.

Läuft bei dir ein KI-Agent, Claude Code, Codex oder etwas Selbstgebautes, in einem Container oder direkt auf dem Rechner? Und weiß der Container, wo dein NAS steht und wie der Router heißt? Mich interessiert, wie ihr das abschottet und ob ihr es überhaupt tut. Ich lese in den Kommentaren mit.

Wer nach diesem Beitrag Tokens erneuert und dafür noch keinen sicheren Ort hat: Vaultwarden mit Docker baut dir einen Passwort-Manager auf eigener Hardware, in dem auch API-Schlüssel gut aufgehoben sind.

Quellen