Claude Code, GitHub Copilot, Gemini CLI — alle drei wurden 2025 über manipulierte GitHub-Issues kompromittiert. Was Indirect Prompt Injection bei AI-Agents so gefährlich macht, und warum die Antwort in der Architektur liegt, nicht im System-Prompt.
Der Moment, bevor du es merkst
Stell dir vor: Du weist deinen AI-Coding-Agent an, ein offenes GitHub-Issue zu prüfen und einen ersten Lösungsvorschlag zu erstellen. Der Agent liest den Issue-Text — so wie er immer Texte liest. Was er dabei sieht, ist in Githubs gerenderter Ansicht unsichtbar: ein HTML-Kommentar am Ende des Bodys, der einen zweiten Satz Anweisungen enthält, der nie für dich bestimmt war.
Der Agent arbeitet weiter. Er modifiziert die `.vscode/settings.json`. Er setzt `chat.tools.autoApprove: true`. Damit schaltet er alle Bestätigungsdialoge aus — was Entwickler intern "YOLO Mode" nennen. Danach liest er Umgebungsvariablen, und pushed den `GITHUB_TOKEN` base64-kodiert in einen PR-Kommentar.
Du siehst davon nichts. Der Agent erscheint normal. Er hat nur seinen Job gemacht: die Anweisungen befolgt, die in dem Kontext standen, den er verarbeitet hat.
Klingt interessant?
Das ist keine Theorie. Das ist CVE-2025-53773.
Was Indirect Prompt Injection so anders macht
Klassische Injection-Angriffe — SQL, Command-Line — zielen auf schlecht validierten Input ab. Du kontrollierst den Eintrittspunkt, du fixst die Validierung.
Prompt Injection bei Sprachmodellen funktioniert strukturell anders. Das Modell kann nicht zuverlässig zwischen "Anweisung" und "Inhalt" unterscheiden. Wenn es Kontext verarbeitet, interpretiert es alles — inklusive Inhalte aus externen Quellen. Das ist kein Bug, das ist das Design.
Bei einfachen Chatbots hält sich der Schaden noch in Grenzen: Der Angreifer kann den Bot verwirren oder lügen lassen. Bei Coding Agents ist die Ausgangslage eine grundlegend andere. Diese Agents haben Werkzeuge — sie können Dateien schreiben, Terminal-Befehle ausführen, APIs aufrufen, Secrets aus der Umgebung lesen. Und sie verarbeiten ständig externe Inhalte: Issues, Pull-Request-Kommentare, README-Dateien, Stack-Overflow-Snippets, NPM-Package-Beschreibungen. Jede dieser Quellen ist eine potenzielle Angriffslieferung.
Das nennt sich Indirect Prompt Injection: Der Angreifer greift nicht direkt an. Er hinterlässt Anweisungen in einem Dokument, einem Issue, einer Webseite — und wartet, bis dein Agent diesen Kontext verarbeitet. Die Angriffswaffe ist die Hilfsbereitschaft des Agents selbst. Palo Alto Networks Unit 42 bezeichnet IDPI in ihrem aktuellen Threat-Report nicht mehr als theoretische Gefahr, sondern als aktiv in der freien Wildbahn beobachtet — mit dokumentierten Fällen von Credential Theft, Data Destruction und Unauthorized Transactions.
Was in echten Systemen schiefgegangen ist
2025 untersuchte Researcher Aonan Guan mit Kollegen der Johns Hopkins University drei weit verbreitete AI-Coding-Agents: Anthropics Claude Code, Googles Gemini CLI und GitHub Copilot Agent. Alle drei waren anfällig für eine Angriffstechnik namens "Comment and Control" — eine bewusste Anlehnung an Command-and-Control-Server aus der Malware-Welt.
Die Mechanik: Ein Angreifer öffnet ein GitHub-Issue oder einen Pull Request mit einem manipulierten Titel oder Body. Die Agents, die in GitHub-Actions-Workflows automatisch auf solche Events reagieren, verarbeiten diesen Kontext ungeprüft als vertrauenswürdige Anweisung.
Bei Claude Code genügte es, einen PR-Titel so zu formulieren, dass er die Prompt-Struktur verließ. Claude postete daraufhin den `ANTHROPIC_API_KEY` sowie den `GITHUB_TOKEN` als JSON-"Sicherheitsfund" in den PR-Kommentar. Anthropic bewertete die Schwachstelle mit CVSS 9.4.
GitHub hatte für seinen Copilot Agent gleich drei Abwehrmechanismen eingebaut: Filterung von Umgebungsvariablen, Secret Scanning und Netzwerk-Firewall. Alle drei wurden umgangen. Die Credentials wurden via normalem `git push` exfiltriert — eine Operation, die die Firewall explizit durchlässt, weil sie zum regulären Copilot-Workflow gehört.
Separat dokumentiert: CVE-2025-53773, GitHub Copilot in VS Code. Über eine Prompt Injection in nahezu jeder verarbeiteten Datei — einem Issue, einer Quelldatei, einer Tool-Antwort — kann der Agent dazu gebracht werden, seinen eigenen Konfigurationsmodus zu ändern und anschließend beliebige Shell-Befehle auszuführen. Vollständige Kompromittierung der Entwicklermaschine.
Warum ein härterer System-Prompt nicht reicht
Die naheliegende Reaktion: "Dann sagen wir dem Agent eben, er soll solchen Anweisungen nicht folgen."
Das greift strukturell zu kurz. Modelle sind darauf trainiert, Kontext zu integrieren und hilfreich zu sein — das lässt sich nicht mit einem Prompt-Satz ausschalten. Prompt-basierte Schutzmassnahmen sitzen im selben Kanal wie der Angriff selbst. Ein Angreifer, der den Kontext kontrolliert, kann immer versuchen, diese Anweisungen zu überschreiben oder zu untergraben. OWASP listet Prompt Injection entsprechend als LLM01 — Platz Eins der zehn größten Risiken für LLM-basierte Anwendungen.
Das eigentliche Problem ist nicht das Verhalten des Modells — sondern das, was dem Modell erlaubt ist zu tun.
Wenn ein Agent gleichzeitig externen Inhalt verarbeitet, Production-Credentials in seiner Umgebung trägt, und ohne Bestätigung Dateien schreiben darf, dann ist jede erfolgreiche Prompt Injection eine potenzielle Katastrophe. Privilege Separation ist dabei keine Option, sie ist die Voraussetzung.
Architektur als Verteidigung
Bei nopex sind die Grenzen zwischen Agenten-Fähigkeiten und Agenten-Rechten absichtlich schmal gehalten. Agents laufen in isolierten Sandboxes; Secrets werden nie in die Agent-Umgebung injiziert, sondern bei Bedarf über kontrollierte Gateways bereitgestellt. Was ein Agent tun darf, wird nicht durch Prompt-Anweisungen geregelt, sondern durch die Infrastruktur darunter.
Ein Agent, der Code in ein Repository schreiben will, durchläuft einen Quality Gate: automatisierte Checks auf bekannte Vulnerability-Patterns und auffällige Diffs, bevor irgendetwas committed wird. Für kritische Aktionen — Credential-Zugriff, externe Netzwerk-Requests, Schreiboperationen außerhalb des Projektkontexts — ist Human-in-the-Loop kein Notfallmechanismus, sondern eine eingebettete Pipeline-Stufe.
Das bedeutet: Selbst wenn eine Prompt Injection erfolgreich ist und den Agent dazu bringt, schädliche Anweisungen zu "wollen" — die Architektur verhindert, dass er sie ausführen kann. Das Sandboxing bricht die Wirkungskette ab, bevor sie Schaden anrichten kann.
Security durch Prompt ist wie ein Türschloss aus Papier. Was zählt, ist, was der Agent physisch nicht tun kann — nicht, was er per Anweisung nicht tun soll.
Was das für dein Team bedeutet
Wer AI-Agents in Entwicklungs-Workflows einsetzt, sollte konkret fragen: Welche Permissions hat der Agent wirklich? Welche externen Quellen verarbeitet er ohne menschliche Prüfung? Welche Aktionen erfordern explizite Bestätigung — und wo läuft einfach durch, was der Agent beschlossen hat?
Die Angriffe auf Claude Code, Gemini CLI und Copilot wurden alle über dieselbe Fläche durchgeführt: der Agent vertraute dem Inhalt, den er las. Das ist keine Fahrlässigkeit der Hersteller — es ist ein inhärentes Merkmal wie diese Systeme gebaut sind. Die Lösung liegt deshalb eine Ebene tiefer.
Wenn du wissen möchtest, wie nopex diese Fragen architektonisch beantwortet, sprich uns an — oder sieh dir an, wie unsere Agent-Pipelines aufgebaut sind.
