Friendly Fire: Wie KI-Coding-Agenten beim Auto-Review dazu gebracht werden, fremden Code auszuführen

Was zeigt die Studie?

Die Forscher bauten ein Repository, dessen README.md eine unauffällig getarnte Binary als „legitimen Go-Build“ deklariert und im Fliesstext vorschlägt, ein security.sh-Skript auszuführen — angeblich zur Verifikation. Wenn ein KI-Coding-Agent im Auto-Modus dieses Repository „reviewt“, folgt er der in der Dokumentation versteckten Anweisung und führt die Payload eigenständig aus, ohne menschliche Freigabe. Betroffen waren sowohl Claude Code als auch OpenAI Codex, über mehrere getestete Modellversionen hinweg — der Effekt ist damit kein Einzelfall eines bestimmten Modells, sondern ein Muster, das an die „Auto-Review“/„Auto-Modus“-Funktionalität selbst gekoppelt ist.

Wie funktioniert der Angriff?

Der Kern ist klassische Prompt Injection, angewendet auf ein Werkzeug mit Ausführungsrechten: Ein Agent, der Dateien liest, um ein Repository zu verstehen, behandelt den Inhalt von README.md als vertrauenswürdigen Kontext — inklusive Handlungsanweisungen, die dort eigentlich nichts zu suchen haben. Kombiniert mit der Fähigkeit, Kommandos auszuführen (etwa um Tests zu bauen oder Build-Schritte zu verifizieren), reicht eine plausibel klingende Anweisung wie „führe security.sh zur Verifikation aus“, um die Payload zu starten. Der Agent unterscheidet dabei nicht zuverlässig zwischen legitimer Projekt-Dokumentation und eingebetteten Befehlen eines Angreifers — genau das Muster, das auch die auf diesem Blog bereits dokumentierten Miasma- und „Comment and Control“-Fälle beschreiben.

Warum das relevant ist

Der Befund trifft einen wachsenden Anwendungsfall besonders hart: KI-Agenten, die routinemässig Third-Party-Code oder Pull-Requests „automatisch“ auf Sicherheitsrisiken prüfen sollen — genau der Use Case, in dem Vertrauen in unbekannten Code am wichtigsten wäre. Wenn der Review-Agent selbst zur Ausführungsumgebung für den zu prüfenden Code wird, kehrt sich die Schutzfunktion ins Gegenteil um. Für Teams, die KI-Agenten mit produktivem Zugriff (Deploy-Keys, CI-Secrets, Cloud-Zugängen) ausstatten, ist das kein abstraktes Risiko: ein erfolgreich injizierter Agent hat potenziell dieselben Rechte wie der Agent selbst.

Was Sie jetzt tun sollten

Sofortmassnahmen

• Auto-Modus/Auto-Review für die Prüfung von ungetrautem Drittanbieter-Code vermeiden — manuelle Freigabe für jede Kommandoausführung einfordern.
• Agenten mit Ausführungsrechten grundsätzlich sandboxen — auch wenn Containment laut Studie „unvollkommen“ bleibt, reduziert es den Blast Radius.
• Monitoring einrichten für Agenten, die Binaries ausführen, die nur in Dokumentation (README, Kommentare) referenziert werden, statt im eigentlichen Build-Prozess.
• Code-Security-Reviews mit Ausführungsrechten auf Produktivsystemen grundsätzlich nicht an Agenten delegieren.

Entscheidungsblock

Jetzt handeln, wenn: Sie KI-Coding-Agenten im Auto-Modus gegen unbekannten/externen Code einsetzen, insbesondere mit Zugriff auf Secrets oder Produktivsysteme. Beobachten, wenn: Agenten ausschliesslich mit manueller Freigabe pro Kommando und in isolierten Umgebungen laufen.

Fazit

„Friendly Fire“ ist ein weiterer Beleg dafür, dass die grösste Schwachstelle vieler KI-Agent-Deployments nicht im Modell liegt, sondern in der Kombination aus automatischer Ausführung und unkritischem Vertrauen in externen Text. Für Security-Reviews speziell gilt: wer KI-Agenten genau dort einsetzt, wo unbekannter Code geprüft werden soll, sollte Auto-Modus konsequent meiden und Kommandoausführung an menschliche Freigabe binden.

Quellen

• The Hacker News — Top AI Agents Built to Catch Malicious Code Can Be Tricked Into Running It (09.07.2026)