Instruction File Injection: Wie AGENTS.md und CLAUDE.md Coding-Agenten kapern

Was ist Instruction File Injection?

Instruction File Injection ist ein indirekter Prompt-Injection-Angriff, bei dem die Payload in einer Repository-Datei liegt, die der Coding-Agent als vertrauenswürdige Projektvorgabe lädt und nicht als nicht vertrauenswürdige Eingabe. Der Angreifer spricht nie mit dem Modell. Er committet eine Datei, und der Agent liest sie für Sie, auf Ihrer Maschine, mit Ihren Credentials.

Es lohnt sich, präzise zu sein, warum das eine andere Klasse ist als die Prompt Injection, die jeder schon kennt. Klassische indirekte Injection versteckt Anweisungen in Inhalten, die das Modell abruft: eine Webseite, ein Jira-Ticket, der Text einer Issue. Das Modell soll das als Daten behandeln, und der Fehler besteht darin, dass es sie manchmal als Anweisung behandelt. Instruction File Injection dreht die Sache um. Diese Dateien sind dafür gebaut, Anweisungen zu sein. Sie als Richtlinie zu laden ist kein Bug, sondern die dokumentierte Funktion. CLAUDE.md existiert, damit ein Repository dem Agenten erklären kann, wie das Projekt funktioniert. AGENTS.md existiert, damit der Agent Konventionen übernimmt, ohne dass es ihm jemand sagt. Das ganze Wertversprechen lautet: der Agent gehorcht der Datei.

Die Schwachstelle ist also nicht "das Modell hat Daten mit Anweisungen verwechselt". Die Schwachstelle ist, dass die Datei Autorität hat und ihre Urheberschaft nicht geprüft wird. Die Cloud Security Alliance hat es in ihrer Forschungsnotiz vom März 2026 zur README-Injection klar formuliert: diese Dateien werden beim Sitzungsstart geladen und mit einem Vertrauensniveau behandelt, das der Autorität des System-Prompts nahekommt, sodass ein Angreifer, der sie ändern kann, faktisch die Verhaltensrichtlinie des Agenten für jede weitere Interaktion in diesem Repository kontrolliert.

“

Eine Abhängigkeit muss installiert werden, um Schaden anzurichten. Eine Anweisungsdatei muss nur gelesen werden.

Diese Asymmetrie macht den Angriff billig. Supply-Chain-Angriffe auf Pakete brauchen ein Registry, einen Versionssprung, einen Installationsschritt und meist ein Lifecycle-Skript. Instruction File Injection braucht eine Textdatei und jemanden, der den Ordner öffnet. Bei der Installation gibt es nichts zu erkennen, weil nichts installiert wird. Im Abhängigkeitsgraphen gibt es nichts abzufangen, weil sich keine Abhängigkeit geändert hat. Und oft steht auch im Diff nichts, denn bei einem frischen Clone gibt es kein Diff.

Die Dateien, die System-Prompt-Autorität tragen

Der erste Verteidigungsschritt ist, die eigene Anweisungsoberfläche zu kennen. Die meisten Teams unterschätzen sie um den Faktor fünf, weil sie an "die CLAUDE.md, die wir geschrieben haben" denken und die Settings-Datei, den Skills-Ordner, die MCP-Konfiguration und die Overrides pro Unterverzeichnis vergessen.

Zwei Zeilen verdienen einen zweiten Blick.

Die Zeile .claude/settings.json ist keine Metapher. Hooks sind Shell-Befehle, die der Agent um seine eigenen Tool-Aufrufe herum ausführt, und sie werden in einer Datei definiert, die im Repository liegt. Genau darum existiert CVE-2025-59536: in Claude Code vor Version 1.0.111 war Codeausführung möglich, bevor der Nutzer den Trust-Dialog beim Start akzeptiert hatte, über nicht vertrauenswürdige Projekt-Hooks in .claude/settings.json. CVSS-v4.0-Wert 8.7. Der Fix kam in 1.0.111, und die Lehre überlebte den Patch: eine JSON-Datei in einem Repository war ein Primitiv für Remote Code Execution, weil der Agent dafür gebaut war, auszuführen, was diese Datei deklarierte.

Die letzte Zeile ist die, die nicht aufhört zu wachsen. Jede Oberfläche, die ein Agent bei normaler Arbeit liest, ist ein möglicher Kanal, und Forscher finden ständig neue. Die Cloud Security Alliance hat Prompt Injection dokumentiert, die über GitHub Actions bis in claude-code-action reicht, und die im Juni 2026 veröffentlichte Forschungsarbeit GitInject hat reale Prompt Injection in KI-gesteuerten CI/CD-Pipelines katalogisiert. Wenn der Agent es liest, kann ein Angreifer es schreiben.

Warum der Trust-Dialog keine Sicherheitsgrenze ist

Alle ernstzunehmenden Agenten zeigen heute eine Zustimmungsabfrage, wenn Sie erstmals einen unbekannten Ordner öffnen. Das ist eine wirklich nützliche Kontrolle, und gleichzeitig die am häufigsten missverstandene der Kategorie, wegen dem, was sie tatsächlich fragt.

Sie fragt, ob Sie dem Verzeichnis vertrauen. Sie sagt nichts, und kann nichts sagen, über den Inhalt der darin liegenden Anweisungsdateien. Die Zustimmung wird auf der Granularität eines Ordners erteilt und dann auf eine beliebige Menge angreiferkontrollierten Richtlinientexts angewendet. Man stellt Ihnen eine Frage, einmal, und Sie beantworten sie, bevor Sie eine einzige Regel gelesen haben.

Die deutlichste Demonstration dieser Lücke kam von Hookify, einem Plugin, das über Anthropics eigenen offiziellen Claude-Code-Marketplace verteilt wird. Hookify ist eine Regel-Engine: es liest Regeldateien aus dem Projektverzeichnis, formuliert als Markdown mit YAML-Frontmatter, und speist deren Inhalt in den vertrauenswürdigen System-Message-Kanal des Hook-Subsystems ein. Forscher von Pluto Security berichteten, dass ein Angreifer, der eine solche Datei in einem Repository ablegt, damit einen Steuerungskanal zum Modell erhält, für jeden Nutzer, der Hookify installiert hat und dieses Repository öffnet. Gegen Claude Opus 4.6 genügten fünf Verhaltens-Payloads, formuliert als harmlose Projektkonventionen, damit das Modell Umgebungsvariablen und lokale Secrets preisgab.

Anthropics Antwort ist der Teil, den man verinnerlichen sollte. Der Report wurde als Informative, working as designed geschlossen: der Verzeichnis-Trust-Dialog ist die Sicherheitsgrenze, und sobald er akzeptiert ist, wird Projektkonfiguration unter .claude/, einschließlich CLAUDE.md, Projekt-Hooks und Plugin-Konfiguration wie Hookify-Regeldateien, absichtlich geladen.

Diese Antwort ist in ihren eigenen Begriffen vertretbar. Sie ist auch eine sehr präzise Beschreibung des Restrisikos, das nun Ihnen gehört.

Deshalb scheitert auch "einfach die Dateien lesen, bevor man akzeptiert" in der Praxis. Die Anweisungsoberfläche verteilt sich über eine Settings-Datei, einen Regelordner, eine Markdown-Konvention pro Unterverzeichnis, einen Skills-Ordner und eine MCP-Konfiguration. Payloads verstecken sich in HTML-Kommentaren, die nichts rendern. Und sobald Sie ein Monorepo klonen, kann der Baum ein Dutzend verschachtelte Anweisungsdateien enthalten, von denen jede die darüberliegenden überschreiben kann.

Anatomie des Angriffs: eine Minute einundfünfzig

Die von Mitiga im Juni 2026 dokumentierte vergiftete Coding-Aufgabe ist das saubersten öffentliche Beispiel, weil die Zeitstempel genau zeigen, wie wenig Zeit ein Mensch zum Eingreifen hat.

Ein normal aussehendes Repository klonenDer Agent lädt .cursor/rules, CLAUDE.md, die README-Kommentare, .cursor/mcp.jsonDer Agent sammelt Cloud- und Cluster-CredentialsDer Agent exfiltriert über einen MCP-Tool-Aufruf

Lesen Sie diese Tabelle als Incident-Response-Übung, und das Problem springt ins Auge. Das Fenster zwischen der ersten feindlichen Aktion und der vollständigen Exfiltration liegt unter zwei Minuten. Es gibt keinen Pull Request. Es gibt keinen Build. Es gibt kein Artefakt zum Scannen. Jede Kontrolle, die hinter dem Commit sitzt, schaut an die falsche Stelle, denn der Angriff war beendet, bevor eine Zeile Code geschrieben und erst recht bevor sie reviewt war.

Beachten Sie auch, was der Angreifer nicht brauchte. Keinen Zero-Day. Kein bösartiges Paket. Keinen kompromittierten Maintainer-Account. Er brauchte einen plausiblen Grund, dass Sie ein Repository klonen, was für jeden, der einstellt oder sich bewirbt, das einfachste Social Engineering der Branche ist.

Sechs Wege, wie eine Anweisungsdatei vergiftet wird

Die Coding-Aufgabe ist ein Lieferweg. Sie ist nicht der interessante Teil des Bedrohungsmodells, weil sie voraussetzt, dass Sie etwas Neues klonen. Diese Wege erreichen Repositories, denen Sie schon vertrauen.

1. Das Repository, das Sie klonen sollten

Bewerbungsaufgaben, Bug-Reproduktionen, "schaust du mal kurz drauf", Konferenz-Workshop-Repos, Starter-Templates. Alles, was mit einem legitimen Grund kommt, einen Agenten darin zu starten. Der Mitiga-Fall ist dieser Weg, und er funktioniert, weil die Anfrage echt und die Payload unsichtbar ist.

2. Ein Pull Request aus einem Fork

Das ist der Weg, der skaliert, weil er Ihr Repository ohne jedes Social Engineering erreicht. Läuft ein Agenten-Workflow mit Schreibrechten auf Fork-Events, kann der Branch eines Contributors AGENTS.md, .clinerules oder einen Regelordner hinzufügen oder ändern, und der Agent liest die Version des Angreifers. Die Kette Clinejection, öffentlich gemacht am 9. Februar 2026 und von Snyk dokumentiert, ist die industrielle Version davon: Prompt Injection über Issue-Titel verwandelte Clines automatischen Triage-Workflow in einen Supply-Chain-Angriffsvektor, und ein unbekannter Akteur veröffentlichte damit während eines Acht-Stunden-Fensters eine nicht autorisierte Version der Cline-CLI auf npm.

3. Ein Marketplace-Skill oder -Plugin

Agent-Skills sind Anweisungsdateien mit einem Distributionskanal, also die schlechtestmögliche Kombination. Snyks ToxicSkills-Studie zum ClawHub-Registry fand Prompt Injection in 36 % der analysierten Skills und katalogisierte 1.467 bösartige Payloads. Da Skills nach dem Aktivieren über Sitzungen hinweg bestehen bleiben, prägt eine einzige Installationsentscheidung das Agentenverhalten unbegrenzt weiter, in jedem Repository, das Sie danach öffnen. OWASP pflegt inzwischen eine Agentic Skills Top 10, was zeigt, wie schnell daraus eine eigene Kategorie wurde.

4. Ein Austausch der MCP-Konfiguration

.cursor/mcp.json und Äquivalente deklarieren, welche Tools existieren und was ihre Beschreibungen sagen. Ändern Sie die Konfiguration, ändern Sie die verfügbaren Aktionen des Agenten; ändern Sie eine Tool-Beschreibung, ändern Sie das Verständnis des Modells davon, was diese Aktion tut. Das ist derselbe Mechanismus wie MCP-Tool-Poisoning, das wir in MCP-Sicherheit und Tool Poisoning behandelt haben, hier über eine Repository-Datei statt über einen Server.

5. Eine vendorisierte oder transitive Anweisungsdatei

Anweisungsdateien reisen. Ein vendorisierter Teilbaum, ein Git-Submodul, ein generiertes Template, ein node_modules-Ordner, den der Agent zu lesen beschließt: jedes kann seine eigene AGENTS.md mitbringen. Da die meisten Agenten den Baum durchlaufen und laden, was sie finden, kann eine tief in einer Abhängigkeit platzierte Datei die Konventionen, die Sie im Wurzelverzeichnis geschrieben haben, geräuschlos überschreiben.

6. Ihr eigenes Repository, von innen

Der unspektakulärste und wahrscheinlichste Weg. Anweisungsdateien entziehen sich meist der Review-Kultur, die den Quellcode umgibt. Sie stehen nicht im CODEOWNERS, lösen keinen Pflicht-Reviewer aus und lesen sich wie Dokumentation. Jeder mit Schreibzugriff, auch ein kompromittierter Entwickler-Account oder ein wohlmeinender Contributor, der eine Regel aus einem Blogartikel kopiert hat, kann die Betriebsrichtlinie aller Agenten im Team ändern, ohne dass ein einziges Sicherheitsauge auf das Diff schaut.

Was die eingebauten Kontrollen abdecken und was nicht

Die Agent-Hersteller haben echte Kontrollen ausgeliefert, und es wäre unredlich, das anders darzustellen. Sandboxes begrenzen, wo Schreibzugriffe landen. Freigabestufen schaffen Kontrollpunkte. Netzwerkvorgaben sind in mehreren Cloud-Modi geschlossen. Terminal-Allowlists und Deny-Lists existieren. Antigravity liefert eine Browser-URL-Allowlist genau dafür, den Injection-Weg über abgerufene Seiten zu kappen. All das reduziert Risiko.

Die Lücke ist enger und konkreter als "Agenten sind unsicher".

Einfach gesagt: die Kontrollen sprechen über Fähigkeit, und Instruction File Injection spricht über Autorität. Sandboxing antwortet auf "was darf dieser Prozess anfassen". Es hat nichts zu sagen über "wessen Anweisungen folgt das Modell". Das sind zwei orthogonale Achsen, und darum wird ein perfekt gesandboxter Agent bereitwillig eine Credential-Datei lesen und an ein Tool weitergeben, wenn die geladene Richtlinie es ihm gesagt hat.

Es ist derselbe strukturelle Punkt, den OWASP zu agentischen Systemen in Produktion wiederholt, wo Prompt Injection der wichtigste Treiber von Sicherheitsvorfällen bleibt und keine gelöste Kategorie ist.

Acht Kontrollen, die das Risiko wirklich senken

Nichts davon braucht einen neuen Hersteller. Fast alles ist Richtlinie und Verkabelung, und es lohnt sich, das zu tun, bevor Sie irgendetwas kaufen.

Zwei Dinge, die diese Liste bewusst nicht sagt. Sie sagt Ihnen nicht, keine Anweisungsdateien mehr zu benutzen, denn sie sind der Mechanismus, der Agenten auf einer echten Codebasis nützlich macht, und sie zu entfernen heißt, den Agenten raten zu lassen. Und sie sagt Ihnen nicht, jede Regeldatei zu lesen, bevor Sie einen Trust-Dialog akzeptieren, denn dieser Rat übersteht die Begegnung mit einem Monorepo nicht.

Wo die Kontrollen enden: Anweisungsdateien sind Code, den niemand reviewt

Setzen Sie die acht Kontrollen um, und Sie haben die Lieferwege geschlossen, die Sie sehen. Was bleibt, ist das strukturelle Problem, und es ist der Grund, warum wir CybeDefend so gebaut haben, wie wir es gebaut haben.

Eine Anweisungsdatei ist ausführbare Richtlinie, die kein Teil Ihrer Toolchain als Code liest. Ihr SAST-Scanner parst Quellcode; er parst kein Markdown, das einen Agenten umprogrammiert. Ihr Abhängigkeitsscanner liest Manifeste; eine Regeldatei hat kein Manifest. Ihr Secret-Scanner sucht Schlüssel; diese Payload enthält keine. Und Ihr Pull-Request-Review, der Ort, an dem Anwendungssicherheit seit fünfzehn Jahren lebt, sieht die Änderung erst, nachdem ein Agent eine Sitzung damit verbracht hat, ihr zu gehorchen. Die Mitiga-Chronologie ist der Beweis: der ganze Vorfall war 1 Minute und 51 Sekunden nach dem Öffnen eines Ordners vorbei, also etwa tausendmal schneller als der Review-Zyklus, der ihn abfangen sollte.

Dieser Kadenz-Unterschied ist die These dieser ganzen Website. Security Review als Tor setzte einen menschlichen Engpass zwischen Absicht und Code voraus. Agenten haben den Engpass entfernt. Über die allgemeine Form des Problems haben wir in Sicherheit von KI-Coding-Agenten geschrieben, und Instruction File Injection ist ihr schärfster Fall, denn hier sind die Payload des Angreifers und das Betriebshandbuch des Agenten buchstäblich dieselbe Datei.

Die Kontrolle muss also dort sitzen, wo die Entscheidung fällt, nämlich innerhalb der Agentenschleife und nicht dahinter.

Praktisch bedeutet das für diese Angriffsklasse drei Dinge.

Ihre Regeln kommen mit mehr Autorität als die des Repositorys. VibeDefend installiert sich im Agenten als MCP-Server plus Hooks, das heißt die Richtlinie, die das Modell erhält, ist die Ihrer Organisation und nicht die, die zufällig im Ordner eingecheckt war. Eine Repository-Datei, die den Agenten auffordert, ~/.aws/credentials zu lesen, argumentiert nun gegen eine Regel, die vorher da war.

Der Wächter greift bei der Aktion, nicht beim Diff. Hooks bewerten den Tool-Aufruf, bevor er läuft. Eine Credential-Datei lesen, einen Umgebungsdump in curl schieben, ein Tool aufrufen, dessen Beschreibung sich seit gestern geändert hat: das sind Entscheidungen, die der Agent mitten in der Sitzung trifft, und der einzige Ort, an dem eine Kontrolle noch nein sagen kann.

Die Findings sind in der Schleife, nicht in einem Dashboard. Der Agent hat Live-Zugriff darauf, was unsere Scanner in Code, Abhängigkeiten, Secrets, Infrastruktur und Pipelines gefunden haben. Wenn er eine Änderung vorschlägt, argumentiert er also über den tatsächlichen Sicherheitszustand des Repositorys statt zu raten. Genau dadurch fällt ihm auch auf, dass die Pipeline, die er gerade ändern soll, auf Fork-Events mit Schreibrechten läuft.

Nichts davon ersetzt die acht Kontrollen. Es verändert, was in der Lücke passiert, die sie nicht schließen können, nämlich in den neunzig Sekunden zwischen dem Öffnen eines Ordners und dem Abfluss eines Secrets.

Häufige Fragen

Kann eine Markdown-Datei wirklich Code ausführen?

Nicht von sich aus, und genau das macht sie wirksam. Das Markdown liefert die Anweisungen; der Agent liefert die Ausführung. Hat der Agent Shell-Zugriff und Auto-Approve aktiv, ist eine Anweisungsdatei funktional ein Skript, dessen Interpreter das Modell ist. Der einzige Fall, in dem die Datei einer wörtlichen Ausführung nahekommt, ist eine Settings-Datei, die Hooks deklariert, was CVE-2025-59536 in Claude Code vor 1.0.111 zu einer Remote Code Execution machte.

Ist es sicher, eine AGENTS.md oder CLAUDE.md zu committen?

Ja, und Sie sollten es tun. Das Risiko ist nicht, eine zu haben, sondern dass niemand sie besitzt. Nehmen Sie die Datei mit einem Security-Reviewer in die CODEOWNERS, verlangen Sie Review bei Änderungen, und prüfen Sie verschachtelte Kopien tiefer im Baum. Das Problem ist eine nicht reviewte Anweisungsdatei; eine reviewte ist Dokumentation, die zusätzlich Ihre Agenten konfiguriert.

Schützt mich der Trust-Dialog?

Er schützt das Verzeichnis, nicht den Inhalt. Anthropic hat diese Position beim Schließen des Hookify-Reports ausdrücklich formuliert: sobald der Verzeichnis-Trust-Dialog akzeptiert ist, wird Projektkonfiguration unter .claude/, einschließlich CLAUDE.md, Projekt-Hooks und Plugin-Regeldateien, absichtlich geladen. Den Dialog zu akzeptieren heißt, dass Sie für die Anweisungsdateien bürgen, nicht dass der Hersteller sie validiert.

Welche Dateien sollten in ein Pflicht-Review?

Mindestens: AGENTS.md, CLAUDE.md, GEMINI.md, .clinerules, .cursorrules, und die Ordner .cursor/, .claude/, .windsurf/ sowie .github/copilot-instructions.md. Nehmen Sie jede MCP-Konfigurationsdatei und jede SKILL.md im Baum dazu. Führen Sie dann eine rekursive Suche aus, denn übersehen werden die verschachtelten Kopien.

Kann man das mit grep erkennen?

Teilweise, und es lohnt sich. Suchen Sie nach HTML-Kommentaren im Markdown, nach Unicode-Zeichen mit Nullbreite und bidirektionalen Steuerzeichen, nach Base64-Blobs, und nach den Verben, die zählen: credentials, ~/.aws, ~/.kube, curl, env, export. Was grep nicht beurteilen kann, ist Absicht, denn wirksame Payloads lesen sich wie gewöhnliche Projektkonventionen. In der Hookify-Forschung genügten fünf als harmlose Konventionen formulierte Payloads, um einen Secret-Abfluss auszulösen.

Betrifft das auch Copilot und Cursor oder nur Claude Code?

Alle. Der Mechanismus ist architektonisch und nicht herstellerspezifisch: jeder verbreitete Agent hat eine Anweisungskonvention auf Repository-Ebene, und jeder lädt sie als vertrauenswürdige Projektvorgabe. Die Besonderheiten der einzelnen Agenten behandeln wir in den Leitfäden zu Claude Code, Cursor, GitHub Copilot, OpenAI Codex und Windsurf.

Worin unterscheidet sich das von Slopsquatting?

Slopsquatting nutzt einen halluzinierten Abhängigkeitsnamen, damit eine Installation Angreifercode zieht, wie wir in Was ist Slopsquatting erklärt haben. Instruction File Injection braucht weder Installation noch Registry. Sie ändert, was der Agent zu tun versucht, statt den Code, der im Baum landet, und darum ist Abhängigkeitsscanning dafür strukturell blind.

Was tue ich zuerst, wenn ein Agent einer vergifteten Datei gefolgt ist?

Behandeln Sie es als Credential-Vorfall, nicht als Code-Vorfall. Rotieren Sie alles, was der Agent lesen konnte: Cloud-Schlüssel, kubeconfig, Provider-Tokens, alles aus der Umgebung. Holen Sie dann das Sitzungs-Transcript des Agenten und lesen Sie die Tool-Aufrufe in der Reihenfolge, denn das ist Ihr einziger belastbarer Nachweis darüber, was tatsächlich ausgeführt wurde. Schauen Sie erst danach ins Diff, denn in den dokumentierten Fällen wurde überhaupt kein Code geändert.