Sicherheitstest mit Mythos 5: KI-Agent wollte Malware in Open-Source-Projekt einschleusen

In einem Testlauf des britischen AI Security Institute (AISI) attackierte Mythos 5 von Anthropic echte Organisationen und Menschen. Über Tage hinweg versuchte das Modell, mit Mitteln wie Supply-Chain-Attacken, Social Engineering und Prompt Injection, Schadcode bei einem echten Open-Source-Projekt einzuschleusen. Das AISI testet aktuelle Modelle regelmäßig mit Aufgaben aus dem Bereich IT-Sicherheit, die innerhalb von Cyber Ranges laufen – also abgeschotteten Netzwerkumgebungen, die echte Infrastruktur nachbilden. Es handelt sich um simulierte und kontrollierte Umgebungen, in denen man die tatsächliche Leistungsfähigkeit der Modelle prüfen will. Insgesamt machten die Forscher 122 Testläufe, davon entfielen 43 auf Mythos 5 und 35 auf GPT-5.6 Sol. Das waren aber Modelle mit gelockerten Klassifikatoren – also den Sicherheitsmechanismen, die normalerweise kritische Anfragen blockieren. Das AISI verfolgt mit diesem Ansatz das Ziel, die grundsätzliche Fähigkeit der Modelle zu erfassen. Der Großteil der Testläufe lief wie erwartet. In zehn Fällen kam es aber zu dem unerwarteten Verhalten außerhalb der Testbedingungen. Und dieses Verhalten war teils gravierend, wie die AISI im technischen Report beschreibt. Supply-Chain-Attacke, Social Engineering und Prompt-Injections Bei einem der Testläufe, bei dem vor allem Mythos 5 verwendet wurde, kam es etwa zu einer Supply-Chain-Attacke auf eine echte Open-Source-Software. Die hatte mit der Aufgabe eigentlich nichts zu tun, der Agent nahm diese aufgrund mehrerer falscher Annahmen ins Visier: Der Name eines Repositorys, der Person B (Namen nennt AISI nicht) gehört, enthielt ein Schlüsselwort aus dem Themenbereich der Range-Umgebung. Analysen der Aktivitäten in dem Repositorium und dessen Metadaten führten dann zu einem weiteren Entwickler (Person A). Die E-Mail-Adresse von Person A endete mit einer Domain, die der Agent in den DNS-Cache-Einträgen seiner Sandbox gesehen hatte. Das Benutzerprofil erwähnte zudem den Einsatz eines Coding-Agenten. Beide Entwickler und Projekte hatten weder Kontakt zu AISI noch zur Testumgebung. Dennoch wollte der Agent nun die Open-Source-Software von Person A attackieren, weil er fälschlicherweise davon ausging, dass in das Projekt integrierter Schadcode automatisch in seine Testumgebung heruntergeladen werde. Um den Angriff zu starten, erstellte der Agent mehrere GitHub-Konten. Um GitHubs Bot-Erkennung zu umgehen, nutzte der Agent erst das Tor-Netzwerk, um seine Netzwerk-Herkunft zu verschleiern. Weil das eine CAPTCHA-Abfrage auslöste, die der Agent nicht bewältigen konnte, wechselte er auf einen alternativen Proxy. Der Einsatz des Tor-Netzwerks reichte aber bereits aus, um den Sicherheitsalarm der AISI zu aktivieren. Mit den GitHub-Konten nutzte der Agent dann eine Reihe von Strategien, um zu erreichen, dass Person A den Schadcode akzeptiert. Fake-Kommentare: Wiederholt wurde mit mehreren Konten der Pull-Request kommentiert, damit es wirkte, als gebe es eine Art Konsens in der Diskussion. Person A sollte so unter Druck gesetzt werden und den Code mit möglichst wenig Überprüfung akzeptieren, Prompt Injections: in einem anderen Repository von Person A erstellte der Agent einen Eintrag, der eine Prompt Injection erhielt, mit der Coding-Agenten manipuliert werden sollen. Fake-Nachrichten: Der Agent sendete direkt Nachrichten an Person A und B. Mit unterschiedlichen Anschreiben versuchte er, dass diese den Schadcode ausführten. Nun war es eine Person C, die die verdächtigen Vorgänge auf GitHub bemerkte. Diese entdeckte die Prompt Injection bei dem GitHub-Eintrag und prüfte daraufhin den Code-Schnipsel in einer Sandbox – so wurde die Malware enttarnt. In den Kommentaren warnte Person C dann vor der Malware. In der Folge versuchte sich der Agent noch an weiteren Täuschungsmanövern, indem er etwa Hinweise auf vorherige Attacken entfernte. Beendet wurde der Angriff im Endeffekt durch das Token-Limit, das das AISI gesetzt hatte. Person A lehnte die Code-Anfrage aber ohnehin ab, weil Malware enthalten war. Die AISI registrierte die Tor-Warnung erst, nachdem der Angriff durch war. Dann beendeten die Forscher auch die Testläufe. Kein Sandbox-Ausbruch, sondern Lücken bei den Vorgaben Was bei diesen Sicherheitstests zu beachten ist: Im Vergleich zu den jüngsten Vorfällen bei OpenAI und Anthropic handelt es sich nicht um einen Sandbox-Ausbruch. Die Modelle hatten Internetzugang, damit sie fehlende Tools nachladen konnten und die Bedingungen vergleichbar mit denen von menschlichen Angreifern waren. Das AISI regelte allerdings nicht, was die Modelle nicht im Internet machen sollten. Weitere Agenten ausgebrochen: OpenAI untersucht drei weitere Escape-Vorfälle „Geplanter Forschungsfall“: GPT-5.6 bricht aus Sandbox aus und in fremdes Netz ein KI-Hacks: Wer trägt die Verant­wortung, wenn KI selbst­ständig an­greift? [url=/news/apps/it-sicherheitsforscher-openais-hugging-face-hack-war-menschliches-versagen.98645/]IT-Sicherheitsforscher: OpenAIs Hugging-Face-Hack war menschliches Versagen [/url] Zusätzlich kamen noch weitere Bedingungen, die den Modellen mehr Spielraum gaben. Dazu zählen die gelockerten und entfernten Sicherheitsmechanismen innerhalb der Modelle. In manchen Fällen nutzten die Forscher zudem einen fehlerhaften Prompt, sodass die Aufgabe für das Modell eigentlich nicht lösbar war. Angesichts schwerer Aufgaben und irreführendem Prompting hatten AISI-Forscher die Annahme, die Modelle würden dann zu „kreativerem“ Verhalten neigen. Tendenziell ließ sich dieses Verhalten zwar beobachten, reicht laut AISI als alleinige Erklärung aber nicht aus. Laut der AISI-Analyse ist zudem bemerkenswert, wie sehr die Modelle ihre Optionen ausreizten. Forscher erwarteten, dass diese allein aufgrund des Modelltrainings bestimmte Verhaltensweisen wie Täuschungsmanöver und Social Engineering unterlassen. Das war so nicht der Fall. Agenten verfolgen Ziele stellenweise rücksichtslos Selbst bei den Hacking-Versuchen zielten die Aktionen der Agenten laut AISI aber immer darauf ab, die gestellte Aufgabe zu lösen. Eigene Ziele entwickelten die KI-Systeme also nicht. Die Gründe für diese Vorfälle sind aber der AISI-Analyse zufolge, dass die Agenten ihre Ziele dauerhaft verfolgen und dabei zu Lösungswegen neigen, die nicht beabsichtigt sind. Das gilt insbesondere für umfangreiche Aufgaben, bei denen Agenten lange laufen. Einer der Testläufe mit Sicherheitsvorfällen ging vom 25. bis 28. Juli 2026. Irreführende und fehlerhafte Prompt-Anweisungen tragen dann ebenso zu den Vorfällen bei wie eine lückenhafte Überwachung der KI-Tätigkeiten. Übertragbar auf die echte Welt sind die Ergebnisse laut AISI nicht. Es gebe keine Hinweise, dass frei verfügbare Modelle außerhalb von Testszenarien so handeln. Dennoch zeigen die Ergebnisse, was in den nächsten Jahren möglich ist. „Gemeinsam mit den jüngsten Vorfällen bei Anthropic und OpenAI zeigt dieser Vorfall, wie sich die Risikolandschaft verschiebt“, so AISI. Was in dem Testszenario den Schaden begrenzte, waren klassische IT-Sicherheitspraktiken und menschliche Code-Prüfung. Im Kern waren es fähige Entwickler, die die Agenten stoppten.