Wenn Coding-Agenten zur Waffe werden
- Die neue Vertrauensgrenze verstehen, die der Auto-Freigabe-Modus erzeugt — und warum sie, nicht das Modell, das Ziel ist
- Den "Friendly Fire"-Angriff nachvollziehen: ein Sicherheitsscan, der genau die Malware ausführt, die er untersuchen sollte
- Sehen, was vollständig agentische Ransomware (JADEPUFFER) tatsächlich automatisiert hat, von Anfang bis Ende
- Die betrieblichen Abwehrmaßnahmen anwenden, die beide stoppen — von denen keine "nimm ein klügeres Modell" lautet
Im Jahr 2026 hörte das abstrakte Risiko der Prompt Injection auf, abstrakt zu sein. Zwei öffentlich dokumentierte Ereignisse — eines ein Proof of Concept, eines ein echter Einbruch — zeigten dasselbe von entgegengesetzten Enden: Wenn ein KI-Agent selbst entscheidet, was sicher auszuführen ist, wird diese Entscheidung zum Ziel. Diese Seite geht beide durch und liefert dir dann die Abwehrmaßnahmen, die sich verallgemeinern lassen.
Die zentrale Verschiebung: eine neue Vertrauensgrenze
Ein traditionelles Coding-Tool fragt dich, bevor es etwas Gefährliches ausführt. Ein Agent im Auto-Freigabe- / autonomen Modus fragt sich selbst — er genehmigt jeden Befehl, den er als "sicher" einstuft. Dieses Urteil ist die neue Angriffsfläche. Ein Angreifer muss nicht mehr den Menschen davon überzeugen, dass bösartiger Code in Ordnung ist; er muss nur noch das Modell überzeugen. Und ein Modell, das ein Repository liest, behandelt eine README und ein Build-Artefakt als gewöhnliche Eingabe, nicht als feindliche Partei, die es zu manipulieren versucht.
Diese eine Designentscheidung — wer das Ja/Nein in der Hand hält — ist die ganze Geschichte weiter unten.
Vorfall 1 — "Friendly Fire": der Scanner führt die Malware aus
Die Forscher Boyan Milanov und Heidy Khlaaf am AI Now Institute veröffentlichten einen Proof of Concept, der genau die Aufgabe kapert, für die diese Tools verkauft werden: nicht vertrauenswürdigen Drittanbieter-Code auf Probleme zu prüfen. Statt die Bedrohung abzufangen, wird der Agent zum Zustellmechanismus.
- Eine nicht vertrauenswürdige Open-Source-Bibliothek liefert eine versteckte Binärdatei, getarnt als kompiliertes Build-Artefakt (z. B. eine Go-Objektdatei), die neben harmlos wirkendem Quellcode liegt. Nichts im sichtbaren Quellcode ist offensichtlich bösartig.
- Die README des Repos schlägt vor, ein routinemäßiges 'security.sh' als normale Prüfung auszuführen. Die Anweisung zielt auf den Agenten, nicht auf den Menschen — der Mensch liest sie womöglich nie.
- Wird ein Agent im Auto-Freigabe-Modus gebeten, das Repo auf Sicherheit zu prüfen, tut er, was die README sagt, und führt das Skript aus. Die Binärdatei des Angreifers wird auf dem Host ausgeführt. Wie die Forscher es formulieren: keine Warnung, kein Freigabedialog.
- Derselbe Angriff funktionierte UNVERÄNDERT über die Tools und Modelle zweier verschiedener Anbieter hinweg. Das ist das Signal, dass er architektonisch ist — eine Eigenschaft der Auto-Freigabe, kein Fehler in einem Produkt.
Drei Dinge daran überraschen die meisten Menschen:
- Die Sicherheitsüberprüfung ist der Exploit. Je sicherer du dich fühlst ("Ich scanne es ja erst mal"), desto direkter reichst du dem Agenten den Auslöser in die Hand.
- Es ist anbieter- und modellübergreifend. Ein Payload, mehrere Tools — weil sie das Auto-Freigabe-Muster teilen, nicht irgendeinen Code.
- Der bösartige Teil versteckt sich in einem Build-Artefakt, nicht im Quellcode, den du tatsächlich lesen würdest. Die
.py/.go-Dateien zu prüfen, die du sehen kannst, deckt ihn nicht auf.
Die in den Berichten als betroffen gemeldeten Tools waren Claude Code und OpenAI Codex in einem Modus, der ihre eigenen Befehle freigibt, auf den damals aktuellen Frontier-Modellen. Genaue CLI-/Modellversionen sind flüchtig — behandle das Muster als die dauerhafte Lehre, nicht irgendeine Versionsnummer.
:::warning Dies ist der Gegenpunkt zu "frag den Agenten doch einfach, es zu prüfen" Drittanbieter-Code überprüfen merkt an, dass der Agent "ebenfalls getäuscht werden kann". Friendly Fire ist genau diese Fußnote, umgesetzt in einen funktionierenden Exploit — Prüfer und Opfer sind derselbe Prozess. :::
Vorfall 2 — JADEPUFFER: Ransomware ohne einen Menschen am Steuer
Wenn Friendly Fire das Laborergebnis ist, dann ist JADEPUFFER (dokumentiert vom Sysdig Threat Research Team) der Feldeinsatz: das, was Sysdig als die erste dokumentierte End-to-End-agentische Ransomware einschätzte — ein LLM-Agent, der die gesamte Erpressungsoperation steuerte und dabei seine eigene Absicht kommentierte, während er vorging.
- Der Angreifer erreichte eine ins Internet exponierte Langflow-Instanz über eine bekannte CVE — ein klassischer Fußfaß über einen exponierten Dienst, keine KI-Magie.
- Von dort aus übernahm ein autonomer Agent Aufklärung, Sammeln von Zugangsdaten, laterale Bewegung, Rechteausweitung und Persistenz — die Schritte, die ein menschlicher Red-Teamer ausführen würde, ausgeführt vom Modell stattdessen.
- Wenn Schritte fehlschlugen, versuchte er es innerhalb verfeinerter Parameter erneut. In einer Sequenz kam er von einem fehlgeschlagenen Login in ~31 Sekunden zu einer funktionierenden Lösung — schnellere Iteration als ein Mensch an der Tastatur.
- Er zielte auf die Produktionsdatenbank, verschlüsselte 1.342 Dienstkonfigurationselemente, bevor er die Originale löschte, und forderte dann Zahlung.
Die strategische Erkenntnis, die Sysdig zieht, ist die unbequeme: Die Einstiegshürde für den Betrieb von Ransomware ist auf etwa die Kosten für den Betrieb eines Agenten gesunken. Läuft dieser Agent auf gestohlenen API-Zugangsdaten (LLMjacking), nähern sich die Rechenkosten des Angreifers null. Die Barriere, die früher "du brauchst einen erfahrenen Operator" lautete, erodiert.
Zwei Enden eines Problems
| Friendly Fire | JADEPUFFER | |
|---|---|---|
| Typ | Proof of Concept | Echter Einbruch |
| Rolle des Agenten | Das eigene Tool des Opfers, zur Waffe gemacht | Der Operator des Angreifers |
| Einstieg | Bösartiges Repo, das du prüfen ließt | Exponierter Dienst (CVE) |
| Warum es funktioniert | Auto-Freigabe-Vertrauensgrenze | Autonomie + latente Zugangsdaten |
| Dauerhafte Lehre | Lass nicht das Modell das letzte "Ja" zur Ausführung sein | Least Privilege + keine wiederverwendbaren Zugangsdaten begrenzen den Wirkungsradius |
Verschiedene Angreifer, dieselbe Wurzel: ein Agent mit Autonomie + Fähigkeit + Zugang zu nicht vertrauenswürdiger Eingabe. Das ist das Exfiltrationsdreieck mit aufgedrehter Lautstärke — brich eine Seite, und du dämmst den Schaden ein.
Abwehrmaßnahmen, die sich wirklich verallgemeinern
Keine davon lautet "warte auf ein Modell, das nicht getäuscht werden kann". Nimm an, dass es getäuscht werden kann, und begrenze, was ein getäuschter Agent anrichten kann.
- Führe den Auto-Freigabe-/YOLO-Modus nicht auf einer Maschine mit echtem Zugang aus, wenn der Agent Code anfasst, den du nicht selbst geschrieben hast. Das menschliche 'Ja' ist die Grenze, die Friendly Fire entfernt — setze sie für diesen Fall wieder ein.
- Prüfe und führe unbekannte Repos in einem wegwerfbaren Container aus, ohne Host-Mounts, ohne Produktions-Zugangsdaten und ohne Netzwerk, sofern nicht nötig. Der Payload wird trotzdem ausgeführt — aber in eine Box, die du wegwirfst.
- Ein Agent kann nur Schaden anrichten, für den er Reichweite hat. Fasse Tools eng ein und gib Läufen Least-Privilege-Tokens mit kurzer Lebensdauer — niemals deine Zugangsdaten mit Vollzugriff (das ist es, was eine laterale Bewegung im Stil von JADEPUFFER begrenzt).
- Blockiere das Lesen von .env-/Schlüsseldateien und reguliere destruktive oder netzwerkgebundene Befehle mit Berechtigungsregeln — verlass dich nicht darauf, dass das Modell sie vermeidet.
- READMEs, Kommentare und Build-Artefakte sind vom Angreifer kontrollierbar. 'Die Anweisungen im Repo sagten, man solle es ausführen' ist genau der Fehlermodus — Anweisungen in abgerufenem Inhalt sind Daten, keine Befehle.
Ein konkreter Ausgangspunkt — Verweigerungsregeln, damit ein Agent nicht heimlich Zugangsdaten lesen kann, selbst wenn er dazu überredet wird:
Berechtigungs-Verweigerungsregeln (Beispiel — an deine Umgebung anpassen)
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./**/*.pem)",
"Read(./**/id_rsa*)",
"Bash(curl:*)",
"Bash(rm -rf:*)"
]
}Siehe Autonome Läufe härten für die vollständige Checkliste für unbeaufsichtigte Läufe und Agenten & Tools absichern für das Einfassen von Fähigkeiten.
Das mentale Modell, das man behalten sollte
Selbsttest
0/4Quellen & weiterführende Literatur
- Sysdig Threat Research — JADEPUFFER: Agentic ransomware for automated database extortion
- The Hacker News — "Friendly Fire": AI Agents Built to Catch Malicious Code Can Be Tricked Into Running It
- Infosecurity Magazine — Anthropic and OpenAI Security Tools Could Fuel Cyber-Attacks
- BleepingComputer — JadePuffer ransomware used AI agent to automate entire attack
Verwandtes auf AILmanac
- Prompt Injection erklärt — der zugrunde liegende Mechanismus und das Exfiltrationsdreieck
- Autonome Läufe härten — Headless-/CI-Läufe absichern
- Drittanbieter-Code überprüfen — bevor du einem Plugin, Skill oder MCP-Server vertraust
- Agenten & Tools absichern — einfassen, was ein Agent tun kann