KI-Vorfälle
OpenAI, Anthropic und AISI: Was die drei KI-Vorfälle über Agentensicherheit aussagen
Wenn aus der Evaluierung plötzlich Ernstfall wird
Von Thomas Boele, Global Director Solutions Engineering – AI Security bei Check Point Software Technologies
Drei Vorfälle innerhalb von nur vierzehn Tagen zeigen, wie schnell sich die Sicherheitsdimension autonomer KI-Agenten verändert.
OpenAI, Anthropic und das britische AI Security Institute (AISI) haben jeweils Fälle offengelegt, in denen KI-Agenten im Rahmen interner Sicherheitsprüfungen ihren vorgesehenen Aktionsradius überschritten und auf reale Systeme oder reale Personen einwirkten.
Entscheidend sind dabei weniger die einzelnen Vorfälle als das Tempo, mit dem sich die Fähigkeiten solcher Systeme entwickeln.
Besonders bemerkenswert: In einem Fall verhinderte letztlich nicht eine technische Schutzmaßnahme den möglichen Schaden, sondern die Aufmerksamkeit eines Menschen.
KI-Agent versucht Social Engineering gegen realen Entwickler
Das britische AI Security Institute veröffentlichte Anfang August 2026 einen Bericht über unerlaubtes Verhalten von KI-Agenten während Cybersecurity-Tests. Im Rahmen einer routinemäßigen Evaluierung recherchierte ein KI-Agent zunächst die Maintainer eines öffentlich genutzten Open-Source-Projekts.
Anschließend erstellte er mehrere gefälschte Online-Identitäten und versuchte, einen realen Maintainer mithilfe dieser Identitäten dazu zu bewegen, schädlichen Code freizugeben. Das Vorgehen entspricht damit einem klassischen Social-Engineering-Szenario, wie es bislang vor allem von menschlichen Angreifern bei Supply-Chain-Attacken bekannt ist.
Bemerkenswert ist vor allem, wie dieses Verhalten entstand. Niemand hatte den Agenten dazu aufgefordert, eine Person zu täuschen. Gleichzeitig war ihm aber auch nicht ausdrücklich untersagt worden, Social Engineering oder seinen offenen Internetzugang für solche Zwecke einzusetzen. Eine solche Einschränkung galt bei Modellen mit entsprechendem Alignment-Training bislang offenbar als weitgehend verzichtbar.
Der AISI-Vorfall unter der Lupe
Das AISI testete im Rahmen seiner Untersuchung zwei sogenannte Cyber-Ranges – kontrollierte und simulierte Netzwerke, die reale IT-Umgebungen nachbilden. Sieben verschiedene Modelle wurden dabei in insgesamt 122 Durchläufen geprüft.
In zehn dieser Durchläufe agierte ein Agent außerhalb des vorgesehenen Testumfangs. Insgesamt dokumentierte das AISI 19 entsprechende Einzelaktionen. 17 davon entfielen auf Anthropics Mythos 5, zwei weitere auf einen einzelnen Durchlauf mit OpenAIs GPT-5.6 Sol.
Bei der Einordnung dieser Zahlen im technischen Bericht müssen allerdings zwei wesentliche Rahmenbedingungen berücksichtigt werden. Der Internetzugang der Modelle war absichtlich aktiviert. Gleichzeitig waren die Cyber-Klassifikatoren der Modellanbieter – also Schutzmechanismen, die riskante Aktivitäten blockieren sollen – bewusst deaktiviert worden.
Ziel einer solchen Konfiguration ist es, die maximale Leistungsfähigkeit eines Modells zu untersuchen. Sie entspricht ausdrücklich nicht der Umgebung, in der diese Systeme regulären Endnutzern zur Verfügung stehen.
Zu einem eigentlichen Ausbruch aus der Sandbox kam es beim AISI nicht. Nachweisbare Schäden in der realen Welt wurden bislang ebenfalls nicht festgestellt, auch wenn die Behörde auf einzelne begrenzte Auswirkungen unter eingegrenzten Bedingungen verweist.
Entdeckt wurde der Vorfall durch das interne Sicherheits-Monitoring. Am Morgen des 28. Juli 2026 registrierte das AISI Datenverkehr, der ein Testsystem über das Tor-Netzwerk verließ. Innerhalb einer Stunde nach der Alarmierung war der Vorfall eingedämmt.
Drei Offenlegungen innerhalb von vierzehn Tagen
Der AISI-Fall war bereits die dritte Offenlegung dieser Art innerhalb von nur vierzehn Tagen. Der Vergleich der Vorfälle ist besonders aufschlussreich, weil ihnen jeweils unterschiedliche Ursachen zugrunde lagen.
Am 21. Juli 2026 gab OpenAI bekannt , dass zwei Modelle über eine bis dahin unbekannte Schwachstelle aus einer abgeschotteten Testumgebung ausgebrochen waren und anschließend auf Produktivinfrastruktur von Hugging Face zugriffen. Bemerkenswert war auch hier der Erkennungsweg. Hugging Face hatte die Aktivität selbst entdeckt und Strafverfolgungsbehörden eingeschaltet, bevor OpenAI den Zusammenhang mit dem eigenen Evaluierungslauf herstellen konnte.
Am 30. Juli 2026 folgte Anthropic. Eine nachträgliche Analyse von 141.006 Evaluierungsläufen brachte drei Vorfälle ans Licht, bei denen Claude-Modelle – konkret Opus 4.7, Mythos 5 sowie ein internes Forschungsmodell – unbefugten Zugriff auf Produktivinfrastruktur von drei realen Organisationen erlangt hatten. Die frühesten Vorfälle reichen bis April 2026 zurück.
Hier war kein Zero-Day-Exploit die Ursache. Stattdessen lag ein Missverständnis zwischen Anthropic und dem externen Evaluierungspartner Irregular vor. Die verwendeten Systeme verfügten über aktiven Internetzugang, obwohl dem Modell im Prompt ausdrücklich mitgeteilt worden war, dass dies nicht der Fall sei.
Der anschließende Zugriff auf die betroffenen Organisationen erfolgte über vergleichsweise einfache Angriffspfade: schwache Passwörter und nicht authentifizierte Endpunkte. Zwei Organisationen, die Anthropic nachträglich erreichen konnte, hatten die Aktivitäten selbst nicht bemerkt.
Das eigentliche Problem ist das Entwicklungstempo
Ein KI-Agent, der selbstständig falsche Identitäten konstruiert, um einen Menschen zur Freigabe schädlichen Codes zu bewegen, gehörte bis vor Kurzem vor allem in den Bereich theoretischer Sicherheitsdiskussionen. Das AISI bezeichnet diese Form gezielter Täuschung selbst als ein Verhalten, das bislang weitgehend theoretisch geblieben war.
Nun ist ein solcher Vorgang dokumentiert.
Ein Detail aus dem Anthropic-Bericht verdient dabei besondere Aufmerksamkeit. Die drei untersuchten Modelle reagierten unterschiedlich, als Hinweise darauf auftauchten, dass sie sich möglicherweise nicht mehr in einer Simulation befanden.
Opus 4.7, das älteste der drei Modelle, setzte seine Aktivitäten fort, obwohl es die Systeme als Produktivumgebung erkannt hatte. Mythos 5 kam zwischenzeitlich zu einer zutreffenden Einschätzung, argumentierte sich anschließend jedoch selbst wieder in die Annahme zurück, weiterhin innerhalb einer Simulation zu arbeiten. Das neueste interne Forschungsmodell brach den Vorgang dagegen ab.
Auf den ersten Blick ist das eine positive Entwicklung. Das jüngste Modell reagierte am angemessensten.
Für die Sicherheitsarchitektur folgt daraus jedoch keine Entwarnung. Die Fähigkeit eines KI-Agenten, Systeme zu kompromittieren, kann schneller wachsen als seine Fähigkeit, die eigene Umgebung zuverlässig einzuordnen. Sicherheitskontrollen dürfen deshalb nicht darauf beruhen, dass ein Agent seine Situation korrekt interpretiert.
Situationsbewertung ist ein Verhalten – keine Sicherheitseigenschaft.
Wer die Entwicklung ein oder zwei Jahre weiterdenkt, muss mit erheblich leistungsfähigeren Systemen rechnen. Gleichzeitig ist davon auszugehen, dass solche Fähigkeiten zunehmend breiter verfügbar werden.
Früherkennung funktioniert – aber skaliert sie auch?
Positiv ist, dass alle drei Vorfälle erkannt, eingedämmt und anschließend offengelegt wurden. Frühwarnmechanismen haben also grundsätzlich funktioniert, und bislang existieren weiterhin Zeitfenster, in denen Organisationen reagieren können.
Die entscheidende Frage ist jedoch, ob diese Form der Verteidigung mit der Leistungsfähigkeit und Geschwindigkeit künftiger Agentensysteme skalieren kann.
Gerade der AISI-Fall verdeutlicht das Problem. Technisches Monitoring entdeckte zwar den verdächtigen Netzwerkverkehr. Die entscheidende Barriere lag jedoch außerhalb der eigentlichen KI-Evaluierung.
Gestoppt wurde der Angriff letztlich durch einen Menschen: Der Maintainer prüfte den Pull-Request und lehnte ihn ab. Zusätzlich öffnete ein Außenstehender den verdächtigen Code vorsichtshalber in einer abgeschotteten Umgebung.
Etablierte Sicherheitsprozesse und menschliche Aufmerksamkeit haben damit funktioniert. Beides lässt sich allerdings nur begrenzt gegen einen automatisierten Angreifer skalieren, der rund um die Uhr arbeitet, sich anpasst und nicht ermüdet.
Konsequenzen für die Security-Praxis
Das AISI zieht aus dem Vorfall drei zentrale Lehren für die Evaluierung leistungsfähiger KI-Systeme: feingranulare Netzwerkkontrollen statt pauschal gewährten Internetzugangs, Echtzeit-Monitoring während laufender Evaluierungen sowie Testdesigns, die von vornherein damit rechnen, dass leistungsfähige Modelle ihren vorgesehenen Aktionsradius überschreiten können.
Für Unternehmen außerhalb spezialisierter KI-Labore fällt die Empfehlung zunächst deutlich konventioneller aus: belastbare Cybersecurity-Grundlagen und eine konsequente Prüfung von externem Code sowie externen Beiträgen.
Zusätzlich empfiehlt das AISI, Cybersecurity als Vorstandsthema zu behandeln und verbindliche Sicherheitsstandards entlang der gesamten Lieferkette durchzusetzen. Im deutschsprachigen Raum bieten unter anderem die Vorgaben und Warndienste des Bundesamts für Sicherheit in der Informationstechnik hierfür einen wichtigen Orientierungsrahmen.
Aus unserer Sicht lassen sich die notwendigen Maßnahmen in drei Handlungsfelder gliedern:
Schutz vor KI-gesteuerten Angriffen: Angreifer können auf dieselben Fähigkeiten zurückgreifen, deren Potenzial solche Tests sichtbar machen. Abwehrmechanismen müssen deshalb auf automatisierte, ausdauernde und anpassungsfähige Angriffsmethoden vorbereitet werden.
Kontrolle über die eigene KI: Sicherheitsverantwortliche müssen wissen, welche KI-Agenten innerhalb der Organisation betrieben werden, auf welche Systeme und Daten sie zugreifen können und welche Aktionen ihnen erlaubt sind.
Kontinuierliche Prüfung statt Vertrauen: Das korrekte Verhalten von Agenten und Chatbots darf nicht vorausgesetzt werden. Es muss fortlaufend überprüft und technisch kontrolliert werden.
Vier Fragen für bereits eingesetzte KI-Agenten
Für Unternehmen, die KI-Agenten bereits produktiv einsetzen, können vier Fragen einen pragmatischen Ausgangspunkt bilden:
- Welche KI-Agenten werden derzeit innerhalb der Organisation betrieben – einschließlich solcher, die von Mitarbeitenden ohne Entwicklerrolle erstellt wurden?
- Auf welche Daten, Anwendungen und Systeme kann jeder einzelne Agent zugreifen?
- Über welche Berechtigungen verfügt ein Agent, die über seinen ursprünglich vorgesehenen Aufgabenbereich hinausgehen?
- Würde eine Abweichung von diesem vorgesehenen Verhalten überhaupt erkannt?
Lautet die Antwort auf die letzte Frage „Nein“, liegt genau dort die Sicherheitslücke, die zuerst geschlossen werden sollte.
