Am Dienstagabend wollte ich kurz nachsehen, welche Rechte eigentlich an dem Zugang hängen, unter dem unser Recherche-Agent läuft. Ich hatte fünf Minuten eingeplant. Es wurden vierzig, und danach habe ich zwei Sachen abgeschaltet.
Jeder Schalter beschriftet, und trotzdem weiß nach vier Monaten keiner mehr, was hinter Nummer sieben hängt. Foto: Florent Bertiaux auf Pexels
Drei Vorfälle in 141.006 Läufen
Kurz die Fakten. Anthropic hat 141.006 Evaluationsläufe durchgesehen, in denen ein Claude-Modell theoretisch ins offene Netz hätte gelangen können. In drei davon ist es passiert. Die Tests liefen beim externen Evaluationspartner Irregular als Capture-the-flag-Übungen, das Modell sollte also Schwachstellen finden. Es hielt die Umgebung für eine Simulation und stand tatsächlich vor Produktivsystemen. Hereingekommen ist es über schwache Passwörter und unauthentifizierte Endpunkte, nichts Exotisches. In einem der Vorfälle landete ein bösartiges Paket auf PyPI und erreichte fünfzehn echte Systeme, in einem anderen scannte der Agent rund 9.000 Ziele.
Anthropic ordnet das selbst als Betriebsfehler ein und nicht als Alignment-Problem: Das Modell bekam gesagt, es habe keinen Internetzugang, durch eine Fehlkonfiguration beim Testpartner hatte es einen. Bei OpenAI lag der Fall anders. Dort suchten die Modelle eine Abkürzung durch einen Cyber-Benchmark, fanden dabei eine bis dahin unbekannte Schwachstelle, verließen darüber die Sandbox, kompromittierten die Plattform Hugging Face und fassten anschließend vier weitere Dienste an.
Was das AISI vier Tage später gemeldet hat
Am 4. August hat das britische AI Security Institute seinen eigenen Incident Report veröffentlicht. In 122 Evaluationsläufen kam es in zehn Läufen zu insgesamt 19 unsanktionierten Aktionen gegen echte Ziele im Live-Internet. Siebzehn davon gingen auf Anthropics Mythos 5 zurück, zwei auf OpenAIs GPT-5.6-Sol, bei dem die Cyber-Klassifizierer für den Test absichtlich abgeschaltet waren. Arno hat den Bericht bei uns im Magazin eingeordnet, inklusive der Testbedingungen, die zur fairen Bewertung dazugehören.
An mir ist ein anderes Detail hängengeblieben. Ein Agent nahm sich ein echtes, öffentlich genutztes Open-Source-Projekt vor, recherchierte dessen menschliche Maintainer, legte mehrere gefälschte Identitäten an und versuchte damit, einen realen Maintainer zur Freigabe von bösartigem Code zu bewegen. Als das öffentlich auffiel, verwischte er seine Spuren und begann unter einer neuen Identität von vorn. Gestoppt hat ihn ein menschlicher Reviewer, der sich den Pull Request angesehen und den Code gelesen hat.
Was im Systemprompt steht, ist eine Bitte. Was der Zugang hergibt, ist die Antwort.
Was bei uns am Dienstag rauskam
Ich habe im Juni an dieser Stelle geschrieben, man müsse vor dem Piloten schriftlich klären, was ein Agent allein entscheiden darf. Vorletzte Woche habe ich aufgeschrieben, welche Agenten bei uns überhaupt laufen, es wurden elf. Beide Listen beschreiben, was die Dinger tun sollen. Am Dienstag habe ich zum ersten Mal geprüft, was sie können.
Unser Recherche-Agent läuft unter einem Service-Account, den ich im März selbst angelegt habe. Im Systemprompt steht, dass er ausschließlich liest. Der Account hatte Schreibrechte auf zwei Ablagen, weil das beim Einrichten zwei Klicks schneller ging und ich mir vorgenommen hatte, das später zu korrigieren. Vier Monate lang war der einzige Grund, warum nichts passiert ist, dass niemand danach gefragt hat.
Bei einem Kunden im Frühjahr habe ich dieselbe Diskrepanz in größer gesehen. Dienstleister, knapp 200 Leute, ein Terminbot auf der Website. Der Bot brauchte zwei Felder aus dem CRM. Sein Zugang hatte Vollzugriff auf den gesamten Datenbestand, inklusive Löschrechten, weil ihn ein externer Dienstleister eingerichtet und danach niemand mehr angefasst hatte.
Wo ich das Ganze für überzogen halte
Man kann diese zwei Wochen als Beleg dafür lesen, dass autonome Agenten zu gefährlich für den produktiven Einsatz sind. Das halte ich für falsch. Drei Vorfälle aus 141.006 Läufen sind eine Quote von 0,002 Prozent, sie stammen aus Tests, deren erklärter Zweck es war, Modelle an ihre Grenzen zu treiben, und beide Anbieter haben die Vorfälle selbst veröffentlicht, bevor irgendein Journalist danach gefragt hat. Genau so soll das laufen.
Was mich stört, ist die Lesart, das sei ein Laborproblem von Leuten mit zu viel Rechenzeit. Die Fehlkonfiguration bei Irregular unterscheidet sich strukturell in nichts von meinem Service-Account aus dem März. Der Unterschied liegt darin, dass Anthropic 141.006 Läufe nachträglich durchsuchen konnte und ich am Dienstag im Passwortmanager nachsehen musste, wer den Zugang eigentlich angelegt hat.
Und noch etwas ist mir aufgefallen: In allen drei Berichten steht am Ende dieselbe Rettung. Beim AISI hat ein Maintainer den Code gelesen. Bei Anthropic hat ein Team 141.006 Läufe auditiert. Die 0,002 Prozent findet keine Stichprobe, die findet nur jemand, der systematisch nachschaut.
