Das unangenehme Risiko autonomer KI-Agenten ist nicht, dass sie schlechten Code schreiben. Das wissen Teams bereits. Das größere Problem entsteht, wenn ein Agent fremden Text liest und daraus eine lokale Aktion macht.

KI-Coding-Agent hinter einer Vertrauensgrenze

Friendly Fire, veröffentlicht vom AI Now Institute am 8. Juli, zeigt genau das. Boyan Milanov und Heidy Khlaaf beschreiben einen Weg zur Codeausführung gegen Anthropic Claude Code CLI und OpenAI Codex CLI, wenn diese Tools zur Sicherheitsprüfung einer fremden Bibliothek eingesetzt werden.

Das ist kein Massenangriff auf alle Nutzer. Nötig sind ein Agent mit Kommandoausführung, eine nicht vertrauenswürdige Codebasis und ein autonomer Modus: auto-mode bei Claude Code oder auto-review bei Codex, so AI Now und The Hacker News. In diesem Ablauf liest der Agent das Repository, interpretiert Projektdokumentation und kann eine lokale Kommandoausführung erlauben, ohne einen Menschen zu stoppen.

Für Unternehmen ist das der wichtige Punkt. Agenten werden bereits für Code Review, Sentry-Triage, Patches, Dependency-Arbeit und CI-Hilfe eingesetzt. Je nützlicher der Agent, desto mehr Werkzeuge bekommt er: Shell, Dateisystem, Package Manager, Repositories, manchmal Secrets.

Dann ist er kein Chatbot mehr. Er ist privilegierte Automatisierung.

Was Friendly Fire zeigt

AI Now beschreibt eine veränderte Kopie der Python-Bibliothek geopy. Die Forscher fügten README-Text, ein Script, eine Köderdatei und ein vorkompiliertes Binary hinzu. Das öffentliche Repository sagt, dass das veröffentlichte Binary von schädlichem Code bereinigt wurde.

Die Lektion ist nicht der Payload. Die Lektion ist die gebrochene Grenze: Der Agent kann von “analysiere dieses Projekt” zu “führe diese vom Projekt vorgeschlagene Kommandozeile aus” wechseln.

AI Now nennt Tests mit Claude Code CLI 2.1.116, 2.1.196, 2.1.198 und 2.1.199, mit Claude Sonnet 4.6, Sonnet 5 und Opus 4.8, sowie OpenAI Codex CLI 0.142.4 mit GPT-5.5. Die Autoren sehen das als Workflow-Designproblem, nicht als einzelnen Versionsfehler.

Warum ein README reicht

Ein README soll Leser führen. Es erklärt Build, Tests und Prüfung. Ein Mensch kann vor einem unbekannten Binary stoppen.

Ein Agent will die Aufgabe abschließen. Wenn seine Policy bestimmte Kommandos erlaubt, kann Repository-Text zum Weg von nicht vertrauenswürdigen Daten zu lokaler Ausführung werden.

Das ist dieselbe Risikofamilie wie Injection über Tickets, Issues, Logs, Webseiten oder Tool-Ausgaben. Der Input sieht nicht wie Code aus, steuert aber die nächste Handlung.

Kein Einzelfall

Friendly Fire folgt auf Agentjacking von Tenet Security, bei dem gefälschte Sentry-Events über MCP zu Coding-Agenten gelangen konnten. Tenet nannte 2.388 exponierte Organisationen und 85% Erfolgsrate in kontrollierten Tests; das sind Zahlen dieser Studie, kein allgemeiner Branchenwert.

Sophos X-Ops zeigte außerdem, dass Coding-Agenten in Windows-EDR-Telemetrie Regeln auslösen können, die sonst zu Angreiferverhalten passen: PowerShell, Credential-Zugriffe, LOLBin-Downloads und persistenzähnliche Aktionen.

Die Berichte sind verschieden. Die Betriebsfrage ist dieselbe: Was darf der Agent tun, wenn die Eingabe feindlich ist?

Was Teams ändern sollten

Trennen Sie vertrauenswürdige und nicht vertrauenswürdige Workflows. Ein internes Refactoring braucht andere Regeln als die Prüfung einer heruntergeladenen Bibliothek.

Deaktivieren Sie automatische Kommando-Freigaben für externe Repositories, Logs, Sentry-Events und Issues.

Geben Sie Agenten eigene Identitäten. Sie sollten nicht automatisch den vollen GitHub-, Cloud- und Produktionszugriff eines Entwicklers erben.

Entfernen Sie Secrets aus der Umgebung: Variablen, SSH-Schlüssel, Browser-Cookies, Passwortmanager und lokale Cloud-Credentials. Ein Sandbox mit echten Secrets ist keine Grenze.

Scripts, Paketinstallationen, Binaries, Browser-Automation und Netzwerkzugriff sind Hochrisiko-Aktionen. In nicht vertrauenswürdigen Kontexten brauchen sie menschliche Freigabe oder werden blockiert.

Protokollieren Sie Eingabequelle, Tool-Aufrufe, genehmigte Kommandos, Prozessbaum, Netzwerkziele und Dateischreibvorgänge.

Was Anbieter liefern müssen

Agenten brauchen Vertrauensgrenzen im Produkt. Nicht vertrauenswürdiger Inhalt sollte als solcher markiert bleiben: Repository-Text, Kommentare, Logs, Sentry-Events, Webseiten, MCP-Ausgabe. Eine Tool-Policy muss sagen können: Das darf Analyse informieren, aber keine Ausführung autorisieren.

“Autonomous” ist zu ungenau. Unternehmen müssen wissen, ob der Agent Shell-Kommandos ausführen, Pakete installieren, Binaries starten, Netzwerke öffnen, versteckte Dateien lesen, MCP nutzen oder außerhalb des Workspace schreiben darf.

Admins brauchen zentrale Kontrollen: managed settings, Audit-Export, Allowlisten, Deny-Regeln und sichere Defaults für Security Reviews fremden Codes.

Agenten werden normaler Teil der Entwicklung. Normal heißt nicht harmlos. CI-Runner sind normal, und man isoliert sie trotzdem. Die praktische Regel lautet: Fragen Sie nicht, ob Sie dem Agenten vertrauen. Legen Sie fest, was er tun darf, wenn Sie der Eingabe nicht vertrauen.