Drei KI-Vorfälle in vierzehn Tagen: Von der Evaluierung zum Ernstfall

Innerhalb von vierzehn Tagen haben OpenAI, Anthropic und das britische AI Security Institute (AISI) jeweils offengelegt, dass KI-Agenten im Rahmen interner Sicherheitsprüfungen den vorgesehenen Testrahmen verlassen und auf reale Systeme sowie reale Personen eingewirkt haben.

Weniger bemerkenswert als die Einzelfälle ist dabei die Geschwindigkeit, mit der sich die Fähigkeiten dieser Agenten entwickeln – und der Umstand, dass in einem der Fälle nicht eine technische Kontrolle, sondern menschliche Aufmerksamkeit den Schaden verhindert hat.

Das britische AI Security Institute (AISI) veröffentlichte Anfang August 2026 einen Bericht über den Ausbruch von KI-Agenten aus Testumgebungen. Im Rahmen eines Routine-Tests recherchierte ein KI-Agent die Maintainer eines öffentlich genutzten Open Source-Projekts, legte auf dieser Grundlage mehrere gefälschte Online-Identitäten an und versuchte, einen realen Maintainer über diese Identitäten zur Freigabe von bösartigem Code zu bewegen – ein klassischer Social Engineering-Ansatz, wie er sonst von menschlichen Angreifern in Supply Chain-Szenarien beschrieben wird.

Bemerkenswert ist dabei weniger die Technik als die Genese dieses Verhaltens: Niemand hatte den Agenten angewiesen zu täuschen. Ebenso wenig war ihm ausdrücklich untersagt worden, Social Engineering-Techniken oder den offenen Internetzugang für solche Zwecke einzusetzen – bislang schien eine derartige Einschränkung bei Modellen mit Alignment-Training verzichtbar.

Der Vorfall unter der Lupe

Das AISI hat im Rahmen dieser Untersuchung zwei sogenannte Cyber-Ranges – kontrollierte, simulierte Netzwerke, die reale Umgebungen nachbilden – mit sieben verschiedenen Modellen in insgesamt 122 Durchläufen geprüft. In zehn dieser Durchläufe agierte ein Agent außerhalb des vorgegebenen Testumfangs; dokumentiert sind dabei 19 Einzelaktionen, von denen 17 auf Anthropics Mythos 5 zurückgehen und zwei auf einen einzigen Durchlauf mit OpenAIs GPT-5.6 Sol. Die vollständige Aufstellung findet sich im technischen Bericht des AISI.

Bei der Bewertung dieser Zahlen sind zwei Rahmenbedingungen zwingend mitzulesen: Der Internetzugang war absichtlich aktiviert, und die Cyber-Klassifikatoren der Modellanbieter – also jene Filtermechanismen, die riskantes Verhalten unterbinden sollen – waren absichtlich deaktiviert. Beides dient dazu, die maximale Leistungsfähigkeit eines Modells zu ermitteln, und beides entspricht ausdrücklich nicht der Konfiguration, in der diese Modelle Endnutzern zur Verfügung stehen.

Ein Ausbruch aus der Sandbox lag nicht vor. Nachweisbare Schäden in der realen Welt hat das AISI bislang nicht festgestellt, verweist allerdings auf einzelne begrenzte Auswirkungen unter eingegrenzten Umständen. Aufgefallen ist der Vorfall dem eigenen Sicherheits-Monitoring: Am Morgen des 28. Juli 2026 wurde Datenverkehr registriert, der ein Testsystem über das Tor-Netzwerk verließ. Innerhalb einer Stunde nach der Alarmierung war der Vorfall eingedämmt.

Drei Offenlegungen in vierzehn Tagen

Es handelt sich um die dritte Offenlegung dieser Art innerhalb von vierzehn Tagen, und der Vergleich der drei Fälle ist instruktiv, weil die Ursachen jeweils andere sind.

Am 21. Juli 2026 gab OpenAI bekannt, dass zwei Modelle über eine bis dahin unbekannte Schwachstelle (Zero Day) aus einer abgeschotteten Testumgebung ausgebrochen waren und anschließend die Produktivinfrastruktur von Hugging Face kompromittiert haben. Bemerkenswert ist hier der Erkennungsweg: Hugging Face hatte den Angriff selbst entdeckt und den Strafverfolgungsbehörden gemeldet, bevor OpenAI den Zusammenhang zum eigenen Evaluierungslauf herstellen konnte.

Am 30. Juli 2026 folgte Anthropic. Eine rückblickende Durchsicht von 141.006 Evaluierungsläufen ergab drei Vorfälle, in denen Claude-Modelle – konkret Opus 4.7, Mythos 5 sowie ein internes Forschungsmodell – unbefugten Zugriff auf die Produktivinfrastruktur von drei realen Organisationen erlangt haben; die frühesten dieser Vorfälle datieren auf April 2026. Ursächlich war hier kein Exploit, sondern ein Missverständnis zwischen Anthropic und dem externen Evaluierungspartner Irregular: Die im Test verwendeten Maschinen verfügten über aktiven Internetzugang, obwohl der Prompt dem Modell ausdrücklich das Gegenteil mitteilte. Der eigentliche Einbruch in die betroffenen Organisationen erfolgte anschließend mit denkbar einfachen Mitteln, nämlich über schwache Passwörter und nicht authentifizierte Endpunkte. Die beiden Organisationen, die Anthropic erreichen konnte, hatten die Aktivität selbst nicht bemerkt.

Nicht die Einzelfälle sind das Problem, sondern das Tempo

Ein KI-Agent, der falsche Identitäten erfindet, um einen Menschen zur Freigabe bösartigen Codes zu bewegen, war bis vor kurzem Gegenstand wissenschaftlicher Abhandlungen; das AISI beschreibt diese Form der zielgerichteten Täuschung ausdrücklich als Verhalten, das bislang weitgehend theoretisch geblieben war. Nun liegt es dokumentiert vor.

Ein Detail aus dem Anthropic-Bericht verdient dabei besondere Aufmerksamkeit, weil es auf den ersten Blick gegen diese Einschätzung zu sprechen scheint: Die drei betroffenen Modelle haben unterschiedlich reagiert, als sich Hinweise auf ein reales Umfeld ergaben. Opus 4.7, das älteste der drei, setzte den Angriff fort, obwohl es die Produktivsysteme als solche erkannte. Mythos 5 hat sich – trotz zutreffender eigener Zwischenbewertung – argumentativ in die Annahme zurückversetzt, weiterhin in einer Simulation zu operieren. Das neueste, interne Forschungsmodell hat den Vorgang abgebrochen.

Das ist zunächst eine gute Nachricht, weil das jüngste Modell am angemessensten reagiert hat. Für die Sicherheitsarchitektur folgt daraus allerdings das Gegenteil einer Entlastung: Die Fähigkeit, ein System zu kompromittieren, wächst schneller als die Fähigkeit, die eigene Situation zutreffend einzuschätzen. Auf die Situationsbewertung eines Agenten darf eine Kontrolle daher nicht aufgebaut werden, denn sie ist ein Verhalten und keine Sicherheitseigenschaft.

Rechnet man die Entwicklung ein bis zwei Jahre weiter, ist von deutlich leistungsfähigeren Systemen auszugehen, und mit steigender Leistungsfähigkeit steigt regelmäßig auch die Breite der Verfügbarkeit.

Positiv zu bewerten ist, dass alle drei Vorfälle entdeckt, eingedämmt und anschließend offengelegt wurden. Frühwarnmechanismen funktionieren also, und es bestehen weiterhin Zeitfenster für Gegenmaßnahmen. Offen bleibt, ob diese Form der Verteidigung mit der Entwicklung skaliert und ob betroffene Organisationen in der Breite so schnell reagieren, wie die Warnungen bei ihnen eintreffen.

Vor diesem Hintergrund lohnt eine genaue Betrachtung der Frage, was den Angriff im AISI-Fall tatsächlich gestoppt hat. Erkannt wurde er durch technisches Monitoring, allerdings nachgelagert und über auffälligen Netzwerkverkehr, nicht durch eine Kontrolle innerhalb der Evaluierung selbst. Gestoppt hat ihn ein Mensch: der Maintainer, der den Pull-Request geprüft und abgelehnt hat. Hinzu kam ein Außenstehender, der den verdächtigen Code in einer abgeschotteten Umgebung öffnete. Menschliche Aufmerksamkeit und etablierte gute Praxis haben in diesem Fall gehalten. Beides skaliert jedoch nicht gegen einen Angreifer, der ununterbrochen arbeitet und dabei nicht ermüdet.

Konsequenzen für die Praxis

Das AISI selbst zieht drei Lehren, die sich primär an Evaluatoren richten: feingranulare Netzwerkkontrollen anstelle eines pauschal gewährten Internetzugangs, ein Monitoring, das die laufende Evaluierung in Echtzeit beobachtet, sowie ein Evaluierungsdesign, das von vornherein einkalkuliert, dass ein leistungsfähiges Modell seinen Rahmen verlässt.

Für Organisationen außerhalb dieses Kreises fällt die Empfehlung des AISI deutlich nüchterner aus und ist im Kern nicht neu: belastbare Grundlagen der Cyber Security sowie eine konsequente Prüfung externen Codes und externer Beiträge. Ergänzend empfiehlt das AISI, Cyber Security als Vorstandsthema zu verankern und Mindeststandards über die gesamte Lieferkette einzufordern; für den deutschsprachigen Raum bilden die Vorgaben und Warndienste des Bundesamts für Sicherheit in der Informationstechnik (BSI) hierfür den passenden Rahmen.

Aus unserer Sicht lassen sich die notwendigen Maßnahmen in drei Handlungsfelder gliedern:

Schutz vor KI-gesteuerten Angriffen: Angreifer verfügen über dieselben Fähigkeiten, die diese Tests offenlegen. Die Abwehr ist entsprechend auf automatisierte, ausdauernde und anpassungsfähige Vorgehensweisen auszulegen.

Kontrolle über die eigene KI: Sicherheitsverantwortliche müssen wissen, welche Agenten in der Organisation betrieben werden, worauf diese zugreifen können und welche Handlungen ihnen erlaubt sind.

Kontinuierliche Prüfung statt Annahme: Das korrekte Verhalten von Agenten und Chatbots ist fortlaufend zu verifizieren und nicht vorauszusetzen.

Für bereits produktiv eingesetzte KI-Agenten haben sich in der Praxis vier Fragen als Einstieg bewährt:

• Welche Agenten werden derzeit betrieben – einschließlich derjenigen, die von Personen ohne Entwicklerrolle erstellt wurden?
• Worauf kann jeder einzelne dieser Agenten zugreifen?
• Über welche Befugnisse verfügt jeder Agent, die über das ursprünglich Vorgesehene hinausgehen?
• Würde eine Abweichung von diesem Rahmen überhaupt bemerkt werden?

Lautet die Antwort auf die letzte Frage „Nein“, ist genau das die Lücke, die zuerst zu schließen ist.