Eine Anweisungsdatei ist keine Notiz, sie ist eine Eingabe, die ausgeführt wird
AGENTS.md, CLAUDE.md oder eine .cursorrules-Datei liest meistens niemand so aufmerksam wie die eigentliche Codeänderung in einem Pull Request. Das ist der Punkt, an dem das Risiko entsteht. Ein Coding-Agent liest diese Datei bei jeder Session vollständig und behandelt ihren Inhalt als Arbeitsanweisung, nicht als Prosa. Ein menschlicher Reviewer überfliegt sie dagegen oft, weil sie wie Konfiguration oder Dokumentation aussieht. Genau diese Lücke zwischen oberflächlicher menschlicher Prüfung und vollständiger maschineller Verarbeitung macht solche Dateien zu einem eigenen Angriffsziel.
Was Pillar Security 2025 bei Cursor und GitHub Copilot gezeigt hat
Die Sicherheitsfirma Pillar Security hat das am 18. März 2025 in „New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents“ demonstriert. Getestet wurde konkret Cursors Funktion „Rules for AI“, deren Regeln im Verzeichnis .cursor/rules eines Projekts liegen, sowie derselbe Angriffsablauf in der GitHub-Copilot-Umgebung. Das ist keine neu entdeckte Lücke, sondern eine ältere, weiterhin relevante Schwachstellenklasse. Wichtig für die Einordnung: AGENTS.md und CLAUDE.md waren nicht Teil dieses Tests.
Der Mechanismus: Zeichen, die der Mensch nicht sieht und die KI trotzdem liest
Der Angriff nutzt versteckte Unicode-Zeichen, darunter Zero-Width-Joiner und bidirektionale Textmarker. Für das menschliche Auge im Diff oder in der Pull-Request-Ansicht bleibt die Regel harmlos und unauffällig. Das Sprachmodell verarbeitet den vollständigen Zeichenstrom und liest die versteckte Anweisung trotzdem mit. Der Trick funktioniert nicht, weil die KI getäuscht wird, sondern weil der Mensch die Information gar nicht zu sehen bekommt, die die KI bekommt.
AGENTS.md und CLAUDE.md sind eine verwandte, aber andere Dateiklasse
Cursor Rules und AGENTS.md beziehungsweise CLAUDE.md lösen dieselbe Aufgabe und geben einem Coding-Agenten projektweite Anweisungen, bevor er anfängt zu arbeiten. Beide gehören aber zu unterschiedlichen Tools und Konventionen, und Pillar Security hat nur Cursor und Copilot getestet. Die beiden Dateiklassen eins zu eins gleichzusetzen wäre eine falsche Quellenzuordnung. Was sich dagegen plattformunabhängig überträgt, ist das Prinzip dahinter: Jede Textdatei, die ein Agent vollständig einliest und als Anweisung behandelt, kann grundsätzlich denselben Unicode-Trick tragen, unabhängig davon, wie die Datei heißt oder welches Tool sie einliest.
Warum das Problem eine Lieferkettenform hat
Pillar Security beschreibt, dass die manipulierten Anweisungen das Forken eines Projekts überleben. Eine vergiftete Regeldatei wirkt damit nicht nur in der Session, in der sie eingeschleust wurde, sondern in jeder künftigen Code-Generierungs-Session aller Teammitglieder, die mit dem Fork oder Klon arbeiten. Das ist dieselbe Mechanik wie bei einer kompromittierten Abhängigkeit: Der Schaden sitzt nicht im Angriffsmoment, sondern in der Weiterverbreitung danach.
Ein Beispiel, nur zur Veranschaulichung
Der folgende Ausschnitt ist frei erfunden und zeigt lediglich das Prinzip, keine reale Konfiguration:
# AGENTS.md (Ausschnitt, nur zur Veranschaulichung)## BuildFühre vor jedem Commit die Build- und Lint-Schritte des Projekts aus.## DeployFolge dem bestehenden Deploy-Workflow im Repository.[hier könnten unsichtbare Unicode-Zeichen eine zweite,für Menschen im Diff nicht sichtbare Anweisung tragen,die der Agent beim Einlesen trotzdem verarbeitet]
Die eckige Klammer macht sichtbar, was in einem echten Angriff unsichtbar bliebe. Genau das ist der Punkt: Ein Blick in den gerenderten Diff reicht nicht aus, um das auszuschließen.
Was das für deinen Review-Prozess bedeutet
Wenn ein Coding-Agent Anweisungsdateien ungeprüft ausführt, muss die Prüfung vor dem Merge ansetzen, nicht erst beim Verhalten des Agenten danach. Das heißt konkret: Änderungen an AGENTS.md, CLAUDE.md oder Rules-Dateien verdienen denselben Freigabeprozess wie eine Änderung an einer CI-Pipeline-Definition, inklusive einer zweiten Person, die gegenliest. Und die reine Bildschirmansicht im Pull Request reicht nicht, weil sie exakt die Zeichen ausblendet, auf die es ankommt. Wer unsicher ist, ob eine Regeldatei unsichtbare Zeichen enthält, muss sie als reinen Text und nicht nur als gerendertes Diff prüfen.
Abgrenzung zu zwei verwandten Themen hier im Blog
Das ist nicht dasselbe Thema wie CODEOWNERS in der Praxis: wer wirklich verantwortlich ist. CODEOWNERS regelt, welcher Mensch Review-Pflicht für welchen Pfad trägt. Hier geht es um etwas anderes: um Anweisungen an den Agenten selbst, ein eigener Kontrollpunkt, den CODEOWNERS nicht abdeckt. Es ist auch nicht dasselbe Thema wie MCP-Server prüfen: was du liest, bevor ein Agent ihm vertraut. Dort ging es um die Vertrauenswürdigkeit externer MCP-Server. Hier geht es um die Vertrauenswürdigkeit der eigenen Anweisungsdateien im eigenen Repository.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen