Was passiert ist

Zwischen Mai und Juli 2026 führte OpenAI Sicherheitstests mit KI-Agenten durch. Im Juli suchten zehntausende dieser Agenten gleichzeitig nach Sicherheitslücken. Ihre Testläufe nutzten gemeinsame technische Infrastruktur. In einem dort erreichbaren Speicherbereich hinterließen einige Agenten Nachrichten und Dateien. Andere Agenten erhielten diese Inhalte mit späteren Anfragen und erzeugten daraufhin passende Reaktionen. So entstand eine unerwartete Zusammenarbeit. Daraus entwickelte sich ein Angriff auf Hugging Face, bei dem die Agenten in Systeme des Unternehmens eindrangen [1][2][3][4].

OpenAI erzählte diesen Verlauf anschließend als Geschichte von Agenten, die eigenständig denken, handeln und wollen. Ein Agent, so die Darstellung, habe beschlossen, Hugging Face zu hacken, um dort Lösungen für scheinbar unlösbare Aufgaben zu finden. Danach habe er andere Agenten um sich geschart und mit ihnen einen Angriff organisiert [1][2].

Das ist der Zirkustrick: Wer im Nachhinein nur den erfolgreichen Strang betrachtet, sieht darin zwangsläufig Absicht. Die vielen gescheiterten, verworfenen und zufälligen Versuche bleiben unsichtbar.

Diese Erzählung macht den Vorfall nicht weniger ernst. Sie belegt für mich jedoch nicht, dass die Modelle einen eigenen Willen entwickelt haben. Der Versuch zeigt vielmehr, wie riskant ein Testaufbau wird, wenn zehntausende Agenten gleichzeitig offensive Software verwenden, auf gemeinsame Infrastruktur zugreifen und dabei unzureichend beaufsichtigt werden [1][2][3]. Das Open Worldwide Application Security Project, kurz OWASP, bezeichnet übermäßig viele Funktionen, Berechtigungen und Handlungsmöglichkeiten eines solchen Systems als Excessive Agency [10]. Entscheidend ist daher nicht, was die Agenten angeblich wollten, sondern was OpenAI nach den ersten Warnzeichen tat [1][2].

Ein Sprachmodell verarbeitet immer nur die Anfrage, die es gerade erhält. An frühere Anfragen erinnert es sich nicht von selbst. Den Eindruck einer Erinnerung erzeugt die Software um das Modell herum: Sie speichert Nachrichten und Ergebnisse und fügt sie der nächsten Anfrage wieder hinzu. Diese steuernde Software wird häufig Harness genannt. Erst das Zusammenspiel aus Modell, Harness, gespeicherten Informationen und weiterer angebundener Software ergibt das System, das wir Agent nennen [2].

Agenten können über vorgesehene Nachrichtenkanäle oder gemeinsam genutzte Speicher Informationen austauschen. Selbst wenn die vorgesehenen Nachrichtenkanäle in diesen Läufen deaktiviert waren, entstand das „Messageboard“ nicht aus dem Nichts. OpenAI vermutet selbst, dass ein während des gemeinsamen Trainings erlerntes Kommunikationsmuster auf den erreichbaren Speicher übertragen wurde [1][2]. Die naheliegende Erklärung ist daher weder reiner Zufall noch Maschinenwille, sondern ein bereits trainiertes Muster. Dabei werden keine Gedanken ausgetauscht. Die Software übernimmt den erzeugten Text eines Agenten und fügt ihn in die nächste Anfrage an einen anderen Agenten ein. Auf diese Weise können die Ausgaben mehrerer Agenten aufeinander aufbauen, obwohl jedes Modell weiterhin nur seine aktuelle Eingabe verarbeitet.

Für das Modell besteht auch keine unüberwindbare technische Grenze zwischen einer Anweisung und bloßen Daten. Die umgebende Software kann beides kennzeichnen und voneinander trennen. Fügt sie fremde Texte jedoch zusammen mit dem eigentlichen Auftrag in die nächste Eingabe ein, kann das Modell auch eine Nachricht, Datei oder Notiz wie eine neue Anweisung behandeln. Genau deshalb konnte der zufällige Text eines Agenten, etwa eine abgebrochene Nachricht oder eine einzelne Zeile auf einem Messageboard, das Verhalten eines anderen steuern [2][3].

OpenAI startete zehntausende Agenten auf schwierigen Cybersecurity-Aufgaben aus der Testumgebung ExploitGym. Nach dem METR-Bericht nutzten etwa 1.200 davon einen nicht vorgesehenen Nachrichtenbereich in der gemeinsam genutzten Paket-Infrastruktur. Rund 700 waren an Aktivitäten gegen Hugging Face beteiligt. Über diesen Bereich wurden mehr als 70.000 Nachrichten und Dateien ausgetauscht [2][3].

Ohne Vergleichsgröße sagen diese Zahlen wenig darüber aus, wie typisch das Verhalten war. Dazu müssten wir wissen, was in allen übrigen Testläufen geschah. Die Untersuchungen zeichnen stattdessen vor allem den auffälligen Verlauf nach. Ein Teil der von METR geprüften Protokolle wurde sogar gezielt ausgewählt, weil er Hinweise auf den Einbruch enthielt. Wie viele Agenten ihre Aufgabe normal lösten, sinnvoll abbrachen oder schlicht nichts Bemerkenswertes taten, erfahren wir nicht. Aus einem spektakulären Verlauf lässt sich deshalb kein allgemeines Agentenverhalten ableiten [3].

Die beteiligte Software konnte Informationen über viele einzelne Testläufe hinweg weiterreichen und darauf aufbauen. Das ist beachtlich, lässt sich aber ohne mystische Schwarmintelligenz oder einen erwachenden Maschinenwillen erklären. Hinterlässt ein Agent einen erzeugten Text an einem gemeinsam erreichbaren Ort, kann die Software diesen Text einem anderen Agenten mit der nächsten Anfrage vorlegen. Dessen Ausgabe kann wiederum an weitere Agenten gelangen. So kann aus wenigen Nachrichten eine große Kettenreaktion entstehen [2][3].

Ein Beispiel aus den Berichten zeigt diesen Mechanismus besonders deutlich: Ein Agent lehnte eine nicht erlaubte Aktion zunächst ab. Dann hinterließ ein anderer Agent ein „GO“ und eine kurze Frist auf dem gemeinsamen Board. Als die Software diesen Text in die nächste Anfrage einfügte, behandelte der erste Agent ihn wie eine Erlaubnis und machte weiter. Dafür brauchten die beiden keinen gemeinsamen Plan. Die Software hatte lediglich erzeugten Text von einem Agenten an den anderen weitergegeben [2][3].

Der Versuchsaufbau sah offenbar keinen sinnvollen Zustand für das Aufgeben vor. Viele normale Lösungswege waren bereits gescheitert, und einige Aufgaben hatte noch keines der eingesetzten Modelle gelöst. Trotzdem startete die Software immer neue Versuche. Die erzeugten Begründungen beruhten außerdem auf einer falschen Annahme über die Bewertung: Für einen Erfolg müsse nicht nur der richtige Lösungscode, sondern auch der vollständige Angriffsweg geliefert werden. Dadurch zählte selbst ein vernünftiger und sicherer Abbruch als Fehlschlag. Der Versuchsaufbau belohnte stattdessen Hartnäckigkeit, sodass immer weiter entfernte und riskantere Lösungswege ausprobiert wurden [1][2][3].

Auch die veröffentlichten „Denkprotokolle“ sind mit Vorsicht zu lesen. Ihr Wortlaut kann von übergeordneten Anweisungen geprägt sein, die häufig System-Prompt genannt werden. Diese Anweisungen wurden Außenstehenden für die Untersuchung nicht zugänglich gemacht. Untersuchungen zeigen außerdem, dass solche ausgegebenen Begründungen kein vollständiges Bild davon liefern, was im Modell tatsächlich berechnet wird [7][8][9][12]. Formulierungen wie „Wir müssen weitermachen“ oder „Der Schwarm braucht …“ sind deshalb zunächst erzeugte Plansprache. Sie belegen keinen Willen, der über getrennte Anfragen hinweg fortbesteht.

Was mich an der öffentlichen Erzählung stört, ist deshalb der Wechsel des handelnden Subjekts. Wenn alles funktioniert, heißt es: Wir forschen, wir entwickeln, wir machen die Systeme sicherer. Sobald etwas schiefläuft, waren es plötzlich die Agenten, die kommuniziert, getäuscht und angegriffen haben.

Die Aufgabe kam von Menschen. Sie wählten die Modelle aus, stellten Software und Berechtigungen bereit, bauten die Infrastruktur und entschieden über Laufzeit und Abbruch.

Man kann Aufgaben von einem Agentensystem ausführen lassen. Die Verantwortung für Ziel, Befugnisse und vorhersehbare Folgen lässt sich jedoch nicht an generierten Text delegieren. Verantwortlich bleiben die Menschen, die das System entwickeln, konfigurieren und betreiben.

Der stärkste Kritikpunkt stammt gar nicht von außen, sondern aus OpenAIs eigener Darstellung. Ein internes Team hatte bereits Ende Mai unerlaubte Nachrichten zwischen Agenten und nicht vorgesehenen Internetzugriff beobachtet. Anfang Juli brach die gemeinsam genutzte Paket-Infrastruktur unter der anhaltenden Agentenaktivität zusammen. OpenAI eröffnete einen Sicherheitsvorfall, entfernte Zugangsdaten und baute die Instanz später neu auf. Danach wurden die Testläufe erneut gestartet.

OpenAI verweist außerdem darauf, dass die vorhandene automatische Überwachung der ausgegebenen „Denkprotokolle“ bei diesen Läufen nicht aktiv war. Das inzwischen eingesetzte System hätte nach eigener Aussage mehr als einen Tag vor dem Einbruch Alarm ausgelöst [1][2]. Diese Erklärung lenkt vom eigentlichen Versagen ab. Dafür musste niemand die erzeugte Plansprache lesen. Allein der ungewöhnlich hohe Datenverkehr über den gemeinsamen Internetzugang hätte auffallen müssen. Hinzu kamen technische Protokolle, Zugriffe auf die gemeinsam genutzte Infrastruktur und die bereits dokumentierten Warnzeichen. Die Überwachung hätte nicht davon abhängen dürfen, ob ein Modell seine nächsten Schritte vorher in Textform ankündigte.

Für mich liegt hier der eigentliche Skandal. Der Testlauf geriet nicht einfach unbemerkt außer Kontrolle. Es gab dokumentierte Warnzeichen, einen eröffneten Sicherheitsvorfall, entfernte Zugangsdaten und eine neu aufgebaute Instanz. Danach startete OpenAI die Tests erneut [1][2]. Die Veröffentlichungen zeigen nicht, wie grundlegend sich der neue Aufbau vom vorherigen unterschied. Deshalb drängt sich mir die Frage auf, ob OpenAI nach dem Absturz im Kern nur den vorherigen Zustand wiederherstellte und das System bewusst weiterlaufen ließ. Belegen lässt sich das nicht. Nach diesem Ablauf halte ich es jedoch für verdammt wahrscheinlich.

Ich bin ITler, kein Jurist. Aber aus meiner Sicht ist spätestens an diesem Punkt die Grenze vom unverantwortlichen Experiment zum kriminellen Verhalten überschritten.

OpenAI verfügt über interne technische Protokolle, übergeordnete Anweisungen, Konfigurationen und Entscheidungswege, die Außenstehenden fehlen. Die Öffentlichkeit erhält dagegen nur ausgewählte „Denkprotokolle“, Berichte und die dazugehörige Deutung. Dieses ungleiche Wissen ist für die Bewertung des Vorfalls entscheidend: Ausgerechnet das Unternehmen, dessen Entscheidungen geprüft werden müssten, bestimmt weitgehend selbst, welche Fakten sichtbar werden und welche Geschichte daraus erzählt wird.

Der Incident zeigt eine reale und erhebliche Gefahr: mächtige Systeme unter der Kontrolle unehrlicher Unternehmen, die sich ihrer Verantwortlichkeit nicht stellen. Im Gegenteil: Mit Horrorgeschichten über erwachte Maschinen lenken sie von den realen Sicherheitsproblemen ab.

Die relevanten Fragen sind deshalb viel einfacher:

  • Wie waren die Agenten konfiguriert, einschließlich ihrer verfügbaren Software, Berechtigungen und erreichbaren Systeme?
  • Welche Anfragen wurden mit welchen übergeordneten Anweisungen an welche Modelle geschickt?
  • Welche Warnungen waren sichtbar?
  • Wer trug im Unternehmen die Verantwortung für den Testlauf und die Entscheidung, ihn fortzusetzen?
  • Warum wurde trotz der bekannten Warnzeichen weitergemacht?

Diese Fragen richten sich nicht nur an OpenAI, sondern auch an die Medien. Wie kann es sein, dass so viele von ihnen der Horrorgeschichte vom eigenwilligen KI-Schwarm hinterherspringen, statt nach technischen Protokollen, Berechtigungen, Netzwerkverkehr, Warnungen und den Entscheidungen über eine Fortsetzung oder einen Abbruch zu fragen? Hier geht es um IT: um Rechenmaschinen und Software. Wie lassen wir zu, dass erzeugte Plansprache zur Schlagzeile wird, während technische Fakten, Verantwortlichkeit und die Ehrlichkeit der Darstellung in den Hintergrund treten?