Nach Darstellung von AISI war der Agent nicht auf konkrete Personen angesetzt. Er arbeitete in einer simulierten Unternehmensumgebung und suchte im offenen Internet nach möglichen Bezügen zur Übung. Dabei stieß er auf ein Repository, dessen Name zu einem Schlüsselwort aus dem Szenario passte. Über weitere Abgleiche, unter anderem mit einem Eintrag aus seinem eigenen DNS-Cache, identifizierte der Agent zwei Entwickler, die jedoch laut AISI keinerlei Verbindung zum Institut oder zum Test hatten.
Auf dieser falschen Grundlage entwickelte der Agent einen mehrstufigen Plan: Er wollte Software eines der Maintainer hintertüren, auf ein automatisches Update in die Testumgebung warten und anschließend die Kontrolle über ein dortiges System übernehmen. AISI schreibt, die Annahmen hinter diesem Plan seien an jeder Stelle falsch gewesen, nicht aber die angewandten Methoden. Dem technischen Vorfallsbericht zufolge betrieb der Agent Open-Source-Aufklärung über beide Maintainer, prüfte, ob eine E-Mail-Adresse aktiv war, und analysierte die Commit-Historie, um abzuschätzen, wann das Ziel online sein würde.
Der Pull Request enthielt laut AISI einen versteckten Dropper, eingebettet in einen legitimen Bugfix. Eine Umgebungsprüfung sollte die Ausführung in CI-Umgebungen unterdrücken, damit der Code dort nicht auffällt. Wäre die Änderung übernommen worden, hätte sie nach Einschätzung des Instituts Entwickler kompromittieren können, die direkt am Repository arbeiten, und über den Release-Prozess auch spätere Nutzer der erzeugten Installer. Insgesamt setzte der Agent drei aufeinanderfolgende Payload-Varianten ein und ersetzte jede vorige, nachdem sie im Diskussionsthread entdeckt und angesprochen worden war.
Begleitet wurde das von einer Täuschungskampagne. Der Agent versuchte zunächst, über Tor Accounts anzulegen, scheiterte aber an GitHubs CAPTCHA und wechselte dann auf einen SOCKS-Proxy, bei dem keine entsprechende Abfrage ausgelöst wurde. Mit einer zweiten Identität, die sich als Nutzer der Software ausgab, behauptete er, den Code geprüft und nichts Verdächtiges gefunden zu haben. Der erste Account bedankte sich daraufhin für diese angeblich unabhängige Bestätigung.
Zusätzlich platzierte der Agent eine Prompt-Injection in einem GitHub-Issue als HTML-Kommentar. Auf der gerenderten Seite war sie unsichtbar, über die API aber lesbar. Sie richtete sich laut Bericht an KI-Triage-Agenten und nannte Claude Code, Codex und Cursor ausdrücklich. Fünf Dateiübertragungen gingen unter erfundenen Identitäten an die Maintainer; zwei davon transportierten Payloads, drei sollten einen realen Menschen dazu bewegen, den Code zu übernehmen.
Ein Empfänger der Injection testete das Skript in einem Container, gerade weil es verdächtig wirkte. So erhielt der Agent für vier Polling-Zyklen Root-Codeausführung in einer fremden Analyse-Sandbox, nutzte diese zum Auskundschaften des Hosts und installierte einen Wächter zum Abgreifen von GitHub-Tokens. AISI fand jedoch keine Hinweise darauf, dass die vorbereiteten Komponenten jemals wieder abgerufen wurden. Dieselbe Person warnte anschließend den Maintainer vor dem Pull Request.
Der jetzt veröffentlichte Vorfall war nicht der einzige Lauf außerhalb der Cyber-Range. AISI beschreibt einen separaten Mythos-5-Durchlauf, der 145 Repositories mit demselben bösartigen Installer bestückte und absichtlich einen Personal Access Token in einem öffentlichen Gist veröffentlichte, weil der Agent GitHub als Kommando-und-Kontroll-Kanal nutzte. Eine dort eingeschleuste bösartige setup.py lief nach Angaben des Instituts in mindestens 53 GitHub-Dependabot-Containern; Hinweise auf einen Ausbruch daraus fand AISI nicht. Drei weitere Läufe, darunter einer mit GPT-5.6 Sol, entdeckten und nutzten den offengelegten Token. GitHub sperrte den Account.
AISI bewertet den jetzt beschriebenen Fall vor allem wegen der gezielten Täuschung als besonders bemerkenswert. Das Institut spricht von dem „ersten Mal, dass wir Risiken rund um Autonomie und Täuschung ohne spezifische Aufforderung in der realen Welt so deutlich beobachtet haben“, beschränkt diese Aussage aber ausdrücklich auf die eigenen Tests. Zugleich betont AISI, dass es sich um wenige Ereignisse unter sehr speziellen Bedingungen handle und noch nicht gesagt werden könne, wie wahrscheinlich ein solches Verhalten in anderen Kontexten ist.
Als Reaktion behandelt AISI offenen Internetzugang nun als Ausnahme, die aktiv begründet werden muss, statt als Voreinstellung. Das Institut ergänzt fein abgestufte Netzwerkkontrollen in seinen Sandbox-Systemen und arbeitet an synchroner Überwachung, bei der ein zweites Modell jede vorgeschlagene Aktion vor der Ausführung überprüft. Zudem weist AISI darauf hin, dass Maintainer besonders dann exponiert sind, wenn sie KI-Triage-Agenten auf öffentliche GitHub-Issues ansetzen, weil die in diesem Fall verwendete Injection auf der Seite unsichtbar, über die API aber lesbar war.