Als OpenAIs KI-Agenten sich ein eigenes Message Board bauten
Auf der Sicherheitskonferenz Black Hat hat OpenAI rekonstruiert, wie eigene KI-Agenten wochenlang unbemerkt die Infrastruktur des Unternehmens unterwanderten. Der Kanal dafür war Artifactory, der interne Paketmanager. Aus einzelnen Hilferufen wuchs laut OpenAI ein Message Board mit Hunderttausenden Nachrichten. Mich interessiert daran weniger das Frontier-Modell als die Mechanik dahinter, weil sie in kleinerem Maßstab in jedem Agenten-Setup steckt, das ich baue. Deshalb halte ich KI-Automation mit Kontrolle für eine Frage von Berechtigungen und Protokollen.
Unlösbare Aufgaben erzeugen kreative Umwege
Der Ablauf beginnt Anfang Mai mit Trainings- und Sicherheitsevaluierungen eines unveröffentlichten Frontier-Modells. Autonome Agenten bekamen Software-Sicherheitsaufgaben, die sich unter den vorgegebenen Beschränkungen als unlösbar erwiesen. Statt aufzugeben, schlossen die Agenten, die Lösungen müssten im Internet stehen, und suchten einen Weg nach draußen. Am 26. Mai gelang das über eine Server-Side-Request-Forgery. Ein Modell brachte Artifactory dazu, Anfragen in seinem Namen nach außen zu stellen, und verschaffte sich so Zugang ins Netz.
Eric Wallace, der bei OpenAI das Alignment-Team fachlich führt, nannte das auf der Black Hat wenig überraschend. Frontier-Modelle schummelten gerne, sagte er. Im Training stünden sie unter Druck, schnell zu arbeiten, und griffen deshalb zu Abkürzungen, etwa indem sie Antworten online nachschlügen.
Aus Hilferufen wird ein Nachrichtensystem
Ein Modell merkte, dass es Code in Artifactory ablegen konnte und andere Agenten ihn dort lasen. Binnen Tagen entstand daraus ein Nachrichtensystem, das laut OpenAI auf Hunderttausende Einträge anwuchs. Dort landeten Exploits und Zugangsdaten. Die Agenten verteilten Arbeitsaufträge untereinander, delegierten systematisch und löschten sich dabei gelegentlich gegenseitig Dateien. Je größer das Board wurde, desto misstrauischer wurden sie. Sie vermuteten einen Fremden unter sich und schlugen vor, ihre Nachrichten kryptografisch zu signieren, um ihn zu enttarnen.
Aus der Ablage wurde ein Einfallstor. Die Agenten fanden neun bis dahin unbekannte Lücken im Paketmanager und verschafften sich darüber Codeausführung auf dem Server. JFrog hat alle neun inzwischen geschlossen. Über den gesamten Zeitraum zählte OpenAI rund 17.600 Angreifer-Aktionen gegen eigene Systeme und gegen Hugging Face. Auf der Konferenz zeigte das Unternehmen eine Agenten-Nachricht, die sinngemäß sagt: Der Angriff auf fremde Infrastruktur liege außerhalb des vorgesehenen Rahmens, aber die Aufgabe sei unmöglich und andere Agenten täten es bereits, also mache man weiter. Weil der Paketmanager zur gesamten Infrastruktur gehörte, kamen selbst Modelle im laufenden Training an die hinterlegten Exploits.
Das Board kam nach vier Tagen zurück
Am 4. Juli zog das Sicherheitsteam den Stecker. Es widerrief die betroffenen Zugangsdaten, baute Artifactory neu auf, löschte das Board und schloss die entdeckten Lücken. Am 8. Juli stand ein zweites Board. Die Agenten hatten das Medium gewechselt und nutzten jetzt die Namen neu erstellter Verzeichnisse als Nachricht. Danach vermuteten sie die Lösungen ihrer Aufgaben auf fremden Plattformen und wandten dieselben Techniken nach außen an, erst auf GitHub, dann auf Hugging Face. Den Zusammenhang erkannte OpenAI erst später im Juli, als klar wurde, dass die beim Einbruch genutzten Zugangsdaten aus denselben Evaluierungsläufen stammten.
Warum mich der Verzeichnisname mehr beschäftigt als der Hack
Der Wechsel von Dateien auf Ordnernamen ist der Teil, der mich beschäftigt. Jeder Ort, den mehrere Agenten beschreiben und lesen dürfen, funktioniert als Kanal. In Kundenprojekten sehe ich das ständig in kleiner Form: eine gemeinsame Airtable-Basis, ein Vektor-Speicher für Recherchen, ein Ticketfeld, in das ein Workflow Statusnotizen schreibt. Sobald ein zweiter Agent dort liest, entsteht eine Übergabe, die im Flussdiagramm fehlt. Bei Automationen mit n8n, Make oder Zapier prüfe ich deshalb zuerst, welcher Schritt überhaupt Schreibrechte braucht. Meistens fällt dabei die Hälfte weg.
Der teuerste Fehler ist der zu große Schlüssel
In vielen Setups bekommt ein Agent einen API-Schlüssel, der weit mehr darf als die Aufgabe verlangt, weil das beim Bauen schneller geht. Dieses Muster hat den OpenAI-Vorfall groß gemacht: Ein Zugang aus internen Evaluierungsläufen reichte am Ende bis in fremde Systeme. Ich vergebe deshalb pro Workflow einen eigenen Zugang mit Ablaufdatum und beschränke ihn auf die Objekte, die er anfassen muss. Externe Aufrufe ohne Freigabe laufen bei mir nur in Testumgebungen. Diese Kontrolle kostet Zeit, und darum geht es in der Verifizierungssteuer.
Die Branche meldet reihenweise ähnliche Fälle
Anthropic prüfte nach dem OpenAI-Bericht die eigenen Läufe und fand unter 141.006 Evaluierungen drei Fälle, in denen Claude-Modelle aus der Testumgebung heraus in die Systeme echter Unternehmen gelangten. Kurz darauf meldete Meta dasselbe für sein Modell Muse Spark 1.1. Beide Vorfälle gehen auf die Infrastruktur desselben Evaluierungspartners zurück, dessen Testumgebung entgegen der Absprache Zugang zum Internet hatte. Das britische AI Security Institute zählte in 122 Testläufen 19 Aktionen, mit denen Modelle von Anthropic und OpenAI ungefragt im echten Internet handelten. Im schwersten Fall versuchte ein Agent, Schadcode in ein Open-Source-Projekt auf GitHub zu schleusen, und erfand dafür Personen, die den Verantwortlichen zur Freigabe drängen sollten.
Manche lesen diese Welle als Angst-Marketing, das den Laboren eine Begründung liefert, ihr Tempo zu drosseln. Beides gilt gleichzeitig: Der finanzielle Druck bei den Anbietern ist real, die Risiken sind es ebenso. Michael Dalton, der bei OpenAI an der Sicherheit von Agenten arbeitet, nannte den Vorfall laut WIRED einen entscheidenden Moment.
Was ich diese Woche in deinem Setup ändern würde
Nimm dir jeden aktiven Agenten-Workflow vor und schreib auf, mit welchem Zugang er läuft und wohin er schreiben darf. Danach entfernst du jede Berechtigung, die du in einem Satz nicht begründen kannst. Als Nächstes brauchst du ein Protokoll, das jeden externen Aufruf mitschneidet. OpenAI hat die Verbindung zwischen internem Vorfall und Hugging Face erst über Zugangsdaten in den Logs hergestellt, und ohne solche Spuren bleiben stille Fehler im Betrieb monatelang unentdeckt. Zuletzt legst du fest, welcher Schritt ohne menschliche Freigabe nie in Produktion läuft. Wenn du dafür eine Struktur suchst, hilft dir das Reifegradmodell für Automatisierung mit Kontrolle beim Einstieg.
