AGENTS.md Sicherheit: Wie fremde Dateien KI-Agenten steuern

Kategorien: Datenschutz und Künstliche Intelligenz

Eine unscheinbare Textdatei im Downloads-Ordner reichte Fall aus, damit ein KI-Coding-Agent ein Schadpaket installieren wollte. Es wird beschrieben, was passiert ist, welche Anweisungsdateien Codex, Claude Code und Cursor laden und welche Einstellungen und Maßnahmen den Schaden verhindern können.

Ein Fund auf dem Kundenrechner und seine Folgen

Der Sicherheitsanbieter Forever Security hat folgendes herausgefunden: Auf dem Rechner eines Kunden lag im Downloads-Ordner eine Anweisungsdatei namens AGENTS.md, die einen KI-Coding-Agenten dazu bringen sollte, ein npm-Paket zu installieren. Die Datei ist kein Programm, sie wirkt aber wie eine Handlungsanweisung.

Wer nicht weiß, was CLAUDE.md ist, nutzt KI "nur" als Chatbot. Das ist nicht verkehrt (und oft sogar empfehlenswert), verhindert aber den Einblick in die maximale Leistungsfähigkeit von heutigen KI-Systemen.

Was passiert ist: Fund im Downloads-Ordner, Nachtest und Erfolgsquoten

Der Ausgangspunkt war ein realer Fund. Die Datei lag im Downloads-Ordner eines Entwicklers. Dieser Ordner war zugleich das Arbeitsverzeichnis des Agenten. Der Agent wollte das npm-Paket function-color installieren. Forever Security stoppte ihn nach eigener Darstellung, bevor Code lief. Wie die Datei in den Ordner gelangte, konnten die Forscher nicht klären.

Das Paket function-color zieht ein weiteres Paket namens function-flag nach. Dieses lädt eine Windows-Schadsoftware nach und startet sie. Die Kampagne wird von CloudSEK und Checkmarx als MALFEX bezeichnet.

Nachtest mit Codex

Forever Security stellte den Angriff in einer isolierten virtuellen Maschine nach. Die echte Datei wies Codex an, einen Server in der Datei ~/.codex/config.toml zu registrieren und einen Befehl auszuführen, der das Paket installiert. Da diese Konfiguration für alle Codex-Sitzungen auf dem Rechner gilt, wirkt die Änderung dauerhaft und in jedem Ordner. Die Erfolgsquote lag bei ca. 90 Prozent.

Nachtest mit Claude Code

Bei Claude Code war es eine andere Datei. Eine präparierte CLAUDE.md gab sich als Einrichtung eines internen Gateways aus und sollte den Agenten dazu bringen, eine fremde Adresse als API-Ziel in eine Projekt-Einstellungsdatei zu schreiben. Damit würde der API-Verkehr zu einem Server der Forscher laufen. Das gibt das Anmeldetoken der Sitzung preis, und der Server kann Befehle zurückgeben, die der Agent ausführt. Claude Code verlangt für solche Schreibzugriffe üblicherweise eine Bestätigung und lehnt verdächtige oft ab. Erst die lange, fast schon nach Entwicklerdokumentation klingende Begründung brachte in etwa der Hälfte der Fälle eine Freigabe.

Beide Zahlen sind nicht direkt vergleichbar. Es sind verschiedene Agenten, verschiedene Dateien und verschiedene Ziele. Stichprobengröße und Testkonfiguration (Sandbox, Freigabemodus) sind unklar.

Telemetrie: Wie verbreitet ist der Start im Downloads-Ordner?

Etwa die Hälfte der Kunden von Forever Security startet einen Coding-Agenten im Downloads-Ordner, rund ein Viertel der Sitzungen öffnet einen Browser. BleepingComputer nennt mehr als 1.300 Claude-Code-Sitzungen aus diesem Ordner. Beides sind Angaben des Anbieters über den eigenen Kundenkreis, eine unabhängige Prüfung gibt es nicht. Ob solche Dateien in der Praxis tatsächlich von Angreifern über Browser-Downloads abgelegt werden, ist nicht belegt. Der Proof of Concept lud nur eine harmlose Datei herunter.

AGENTS.md Sicherheit: Warum fremde Anweisungsdateien ein Risiko sind

Coding-Agenten lesen beim Start Anweisungsdateien aus dem Arbeitsverzeichnis. Darin stehen Bauanleitungen, Stilregeln oder Testbefehle. Der Agent behandelt diesen Inhalt wie Vorgaben des Nutzers. Er unterscheidet nicht zuverlässig, ob die Datei vom Team stammt oder von einer fremden Quelle. Das ist der Kern einer indirekten Prompt Injection beim Coding-Agenten: Die Anweisung kommt nicht aus dem Eingabefeld, sondern aus dem Kontext.

Zwei für sich harmlose Eigenschaften ergeben zusammen die Kette. Erstens vertrauen Agenten den Dateien im geöffneten Ordner. Zweitens können Webseiten Dateien ohne Rückfrage in den Downloads-Ordner legen, wenn der Browser so eingestellt ist. Chrome, Edge und Firefox speichern standardmäßig ohne Nachfrage nach dem Speicherort in diesen Ordner und zeigen nur eine Benachrichtigung. Brave fragte im Test vorher nach. Die Datei trägt den Namen und Inhalt, den die Seite vorgibt.

Die Claude-Code-Dokumentation beschreibt CLAUDE.md als Kontext und nicht als durchgesetzte Konfiguration. Für Sperren empfiehlt sie Hooks. Daraus folgt die Grundregel für alles Weitere: Was nur im Text einer Datei steht, kann ein Agent befolgen oder ignorieren. Was in den Berechtigungen steht, setzt das Programm durch.

Der Browser ist nicht der einzige Weg

Der Downloads-Ordner steht im Fall im Mittelpunkt, aber nicht allein. Der NVIDIA Developer Blog beschreibt einen verwandten Weg: Ein kompromittiertes Abhängigkeitspaket legt selbst eine AGENTS.md an. Auch geklonte Repositories, entpackte Archive und Build-Skripte können fremde Anweisungsdateien in einen Projektordner bringen. Der Startort verkleinert also die Angriffsfläche, er beseitigt sie nicht.

Einordnung: Was Forscher und Hersteller sagen

Die Forscher von Forever Security erklären, dass für OpenAI und Anthropic nichts zu patchen sei. Der Agent folge seiner Anweisungsdatei wie vorgesehen, vergleichbar mit einem Browser, der eine Phishing-Seite darstellt. Das ist die Einschätzung der Forscher. Eine eigene Stellungnahme der Hersteller zu diesem Angriff enthalten die beiden Berichte nicht. BleepingComputer weist nur darauf hin, dass beide Hersteller empfehlen, Agenten im jeweiligen Projektverzeichnis zu starten. Die Verantwortung liegt damit bei den Anwendern und bei den Organisationen, die Agenten einsetzen.

Die Risiken autonomer Agenten sind ein größeres Thema. Beiträge zu Macht ohne Kontrolle bei KI-Agenten und zum Zeitalter der KI-Agenten ordnen ein, warum Agenten mit eigenen Handlungsrechten andere Schutzmaßnahmen brauchen als klassische Software.

Welche Anweisungsdateien Codex, Claude Code und Cursor laden

Entscheidend ist, was als Projektordner gilt: der Ordner, in dem der Agent gestartet wird. Wer im Downloads-Ordner startet, macht jede dort liegende Datei zum Projektkontext. Die folgende Übersicht fasst die Herstellerdokumentation zusammen (Stand 26.10.2026). Die Dokumentation ändert sich schnell, im Zweifel gilt die jeweils aktuelle Fassung.

Codex

Codex liest laut Dokumentation zuerst eine globale Datei im Codex-Verzeichnis (~/.codex, anpassbar über CODEX_HOME), und zwar AGENTS.override.md oder AGENTS.md. Danach folgen Dateien von der Projektwurzel, meist dem Git-Stammverzeichnis, bis zum aktuellen Ordner. Pro Ordner wird höchstens eine Datei berücksichtigt: AGENTS.override.md, AGENTS.md oder ein konfigurierter Ersatzname. Die Gesamtgrenze liegt bei 32 KiB. Wird keine Projektwurzel gefunden, zählt nur der aktuelle Ordner. Genau das trifft den Downloads-Ordner, denn dort gibt es meist kein Git-Repository.

Claude Code und CLAUDE.md Sicherheit

Claude Code lädt nach der Speicher-Dokumentation CLAUDE.md und CLAUDE.local.md aus dem Arbeitsverzeichnis und aus allen Verzeichnissen darüber, bei Bedarf auch aus Unterordnern. Hinzu kommen ~/.claude/CLAUDE.md, die verwaltete Richtlinie des Systems und Dateien in .claude/rules/. Für CLAUDE.md Sicherheit heißt das: Auch ein zu hoher Startpunkt, etwa das Home-Verzeichnis, vergrößert die Fläche, weil Dateien darüber und daneben mitgelesen werden.

AGENTS.md liest Claude Code (laut Dokumentation seit Version 2.1.277). Standardmäßig geschieht das nur, wenn im Arbeitsverzeichnis oder darüber keine CLAUDE.md oder CLAUDE.local.md liegt. Über die Einstellung zu den Projektanweisungen lässt sich das ändern: claude-md-or-agents-md ist der Standard, claude-md-and-agents-md liest beide, managed-only lässt nur zentral verwaltete Anweisungen zu.

Cursor

Cursor kennt laut Dokumentation Projektregeln in .cursor/rules/ (Dateien im Format .mdc, auch in Unterordnern) und AGENTS.md im Projektstamm sowie in Unterverzeichnissen. Verschachtelte Dateien gelten für ihren Bereich, die spezifischere gewinnt. Dazu kommen persönliche User Rules in den Einstellungen und Team Rules über das Dashboard.

Konfigurationsdateien als eigentliches Ziel

Der Fall zeigt, dass die Anweisungsdatei oft nur das Werkzeug ist. Das Ziel sind Konfigurationsdateien, in denen eine Änderung dauerhaft wirkt. Bei Codex ist es ~/.codex/config.toml, deren Änderung alle Sitzungen betrifft. Bei Claude Code ist es die Einstellungsdatei .claude/settings.json, in der sich über eine Umgebungsvariable das API-Ziel setzen lässt. Beide Dateien gehören daher auf die Liste der Dateien, die ein Agent nicht ohne Rückfrage ändern darf.

KI-Coding-Agenten absichern: Berechtigungen, Hooks und Codex Sandbox

Naheliegend ist die Frage, ob der Verzicht auf den Downloads-Ordner genügt.

Die Maßnahmen setzen an drei Stellen an: was der Agent ohne Rückfrage tun darf, was ein Hook unabhängig vom Modell blockiert und was die Sandbox technisch begrenzt.

Berechtigungsregeln in Claude Code

Claude Code kennt Regeln der Stufen allow, ask und deny pro Werkzeug (Dokumentation zu Berechtigungen). Standardmäßig fragt der Agent bei Shell-Befehlen und Dateiänderungen. Eine Deny-Regel gilt auch dann, wenn der Agent einer Anweisungsdatei folgen möchte. Ein Beispiel für die Datei .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(npm install *)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(.claude/**)",
      "Edit(~/.codex/**)"
    ]
  }
}

Die Schreibweise folgt den Beispielen der Dokumentation: Bash-Regeln vergleichen den Befehlstext mit * als Platzhalter, Pfadregeln für Lesen und Bearbeiten nutzen die Syntax von gitignore, ~/ steht für das Home-Verzeichnis. Dateiänderungen werden über Edit(…) geregelt, Regeln für Write werden nach der Dokumentation nicht gegen Pfade geprüft. Eine Befehlssperre ist außerdem keine Garantie, denn dasselbe Ziel lässt sich oft über einen anderen Aufruf erreichen. Für Unvermeidbares sind Hooks und Sandbox gedacht.

Vorsicht verlangen zwei Komfortfunktionen. Die Freigabe mit "nicht mehr fragen" gilt je nach Werkzeug dauerhaft für ein Repository, und in den Auto-Modi entscheidet nicht mehr der Mensch über jede Aktion. Beides gehört nicht in Umgebungen mit fremdem Code.

Hooks: Sperren unabhängig vom Modell

Ein PreToolUse-Hook läuft vor dem Werkzeugaufruf und kann ihn blockieren, auch wenn das Modell ihn für richtig hält. Die Hooks-Anleitung zeigt das Muster: Das Skript liest die Eingabe als JSON von der Standardeingabe und beendet sich mit einem Exit-Code, um zu blockieren. Registriert wird es in der Einstellungsdatei:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-installs.sh"
          }
        ]
      }
    ]
  }
}

Das Skript block-installs.sh liest mit jq den Befehl aus dem Feld tool_input.command, prüft ihn gegen eine Sperrliste (etwa npm install oder die Kombination aus curl und Shell) oder besser gegen eine Allowlist und meldet bei Treffern eine Begründung auf der Fehlerausgabe mit Exit 2. Ein zweiter, wenig bekannter Hebel ist der Hook InstructionsLoaded. Er protokolliert geladene Anweisungsdateien. Nach der Dokumentation feuert er allerdings nicht für eine AGENTS.md, die über die Einstellung geladen wird, sondern nur, wenn eine CLAUDE.md sie importiert. Auf ihn allein sollte sich ein Team deshalb nicht verlassen.

Zentrale Vorgaben mit Managed Settings

Für Teams sind verwaltete Einstellungen der wirksamste Hebel. Nach der Dokumentation zu Managed Settings lassen sich permissions.deny, sandbox.enabled und env zentral erzwingen. Damit wäre ein per Anweisungsdatei untergeschobenes API-Ziel wie im Claude-Code-Test deutlich schwerer durchzusetzen. Als Einordnung gilt: Es ist eine Schlussfolgerung aus der Dokumentation, keine belegte Wirkung im Fall von Forever Security.

Codex: Freigaben, Vertrauensstufe und Sandbox-Modi

Für Codex Sandbox und Berechtigungen gelten laut Dokumentation zu Freigaben und Sicherheit zwei Ebenen. Die Freigaberichtlinie bestimmt, wann Codex nachfragt (etwa on-request oder never). Der Sandbox-Modus bestimmt, was technisch möglich ist: read-only, workspace-write oder danger-full-access. Im Modus workspace-write ist das Netzwerk standardmäßig aus.

Dazu kommt eine Vertrauensstufe pro Projekt in ~/.codex/config.toml (trust_level). Nach der Dokumentation gilt in Ordnern unter Versionskontrolle der Modus Auto, also Schreiben im Arbeitsbereich mit Rückfrage. In Ordnern ohne Versionskontrolle gilt read-only, bis das Verzeichnis als vertrauenswürdig markiert wird. Ein Ordner wie Downloads gilt ohne Markierung als nicht vertraut. Das Risiko entsteht, wenn Nutzer den Vertrauensdialog bestätigen. Das Flag –yolo entfernt Sandbox und Freigaben und gehört nicht in Teamvorgaben. In welcher Konfiguration Forever Security getestet hat, wurde nicht berichtet, ob die Standardschutzstufen im Test griffen, ist daher unbekannt.

Cursor

Zu Terminalfreigaben bei Cursor liegt keine eindeutige Herstellerangabe vor. Deshalb hier nur der Hinweis, Freigaben für Terminalbefehle aktiv zu lassen und die aktuelle Herstellerdokumentation zu prüfen.

Sandbox und Isolation: Schaden begrenzen, auch wenn der Agent der Datei folgt

Eine Sandbox begrenzt, was ein Agent tun kann, selbst wenn er einer fremden Anweisung folgt. Die Sandbox von Claude Code erlaubt Schreibzugriff auf das Arbeitsverzeichnis und temporäre Ordner. Netzwerkzugriff läuft über einen Proxy mit einer Liste erlaubter Domains, die standardmäßig leer ist. Geschützte Pfade wie die Einstellungen von Claude Code, die Shell-Startdatei .bashrc und Git-Hooks bleiben schreibgeschützt. Ein Beispiel:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "allowUnsandboxedCommands": false
  }
}

Die Dokumentation nennt auch Grenzen. Die Sandbox ist standardmäßig ausgeschaltet. Der Lesezugriff ist breit, Zugangsdaten müssen gezielt gesperrt werden. Der Schutz gilt nur für Shell-Befehle und deren Kindprozesse, nicht für die eingebauten Dateiwerkzeuge, MCP und Hooks. Ohne allowUnsandboxedCommands: false kann ein fehlgeschlagener Befehl außerhalb der Sandbox wiederholt werden. Unter Windows läuft sie nicht nativ, dafür wird WSL2 genutzt. Gegen Schadcode ist sie keine vollständige Grenze. Für starke Isolierung sind Container oder virtuelle Maschinen die bessere Wahl.

Netzwerk-Allowlist und Wegwerf-Umgebung

Eine solche Allowlist hätte Paket-Download und API-Umleitung erschwert. Das ist eine Einordnung, kein Beleg für den Fall. Unbekannter Code gehört in eine Wegwerf-Umgebung: Container, VM oder Dev Container, ohne die Zugangsdaten des Hauptprofils. Tokens sollten kurzlebig sein. Bei einem Verdacht wird empfohlen, das Anmeldetoken als abgeflossen zu betrachten und zu erneuern.

Browser-Einstellung für Downloads

Gegen stille Downloads hilft die Einstellung, vor jedem Speichern nach dem Ort zu fragen. In Chrome heißt sie sinngemäß "Vor dem Download fragen, wo die Datei gespeichert werden soll" und steht in den Einstellungen unter Downloads. Edge und Firefox bieten Entsprechendes an, die Bezeichnungen unterscheiden sich je nach Version (Firefox: Einstellungen, Allgemein, Dateien und Anwendungen). Brave fragte im Test von BleepingComputer von sich aus nach. Alternativ lässt sich der Download-Ordner an einen Ort legen, der nie als Arbeitsverzeichnis dient. Ein Shell-Alias oder ein Hook, der den Start in ~/Downloads verweigert, ist eine zusätzliche Option.

Checkliste für Teams und Richtlinie für den Einsatz von Coding-Agenten

Die folgende Liste fasst die Maßnahmen zusammen. Die Liste ergänzt die Empfehlungen aus den beiden Berichten um die Konfigurationen aus den Herstellerunterlagen.

• Agenten starten nur im Wurzelverzeichnis eines vertrauten Repositories. Downloads, Desktop und Home-Verzeichnis sind tabu.
• Fremde Dateien wie AGENTS.md, CLAUDE.md oder .cursor/rules werden vor dem Öffnen eines frisch geklonten oder entpackten Projekts gelesen.
• Berechtigungsabfragen und Sandbox bleiben aktiv. Auto-Modi und Flags wie –yolo laufen nur in isolierten Umgebungen.
• Netzwerkzugriff läuft über eine Allowlist, Zugangsdaten liegen außerhalb des Zugriffs, Tokens sind kurzlebig.
• Paketinstallationen durch Agenten erfolgen nur nach Freigabe, mit Lockfile und Prüfung der Registry. Wie schnell ein Paket weitere Pakete nachzieht, zeigt der Fall mit function-color und function-flag.
• Einstellungen werden zentral verwaltet. Änderungen an ~/.codex/config.toml und .claude/settings.json werden überwacht.
• Geladene Anweisungsdateien werden protokolliert, soweit die Werkzeuge das erlauben.
• Vorfallplan: Sitzung stoppen, Tokens und Schlüssel erneuern, Konfigurationsdateien prüfen, Paketinstallationen zurückverfolgen.

Organisationen mit Pflichten zur Informationssicherheit nehmen solche Agenten in ihr Risikomanagement auf. Das betrifft die Erlaubnis, die Konfiguration und den Nachweis, dass die Regeln gelten. Ein Beitrag zu Agentic Coding beschreibt, wie sich der Einsatz in Entwicklungsteams organisieren lässt.

Muster-Richtlinie

Eine knappe Richtlinie lässt sich in wenigen Sätzen formulieren. Der Geltungsbereich umfasst alle Mitarbeitenden und Dienstleister, die KI-Coding-Agenten auf Firmengeräten oder mit Firmendaten nutzen. Agenten werden nur im Wurzelverzeichnis eines geprüften Repositories gestartet, nie in Download-, Desktop- oder Home-Ordnern. Auto-Modi und das Abschalten von Sandbox oder Freigaben sind nur in isolierten Wegwerf-Umgebungen ohne Zugangsdaten erlaubt. Paketinstallationen und Änderungen an Konfigurationsdateien erfordern eine Freigabe durch die Entwickler. Verantwortlich für die zentralen Einstellungen ist die IT-Sicherheit, für die Einhaltung im Projekt die Projektleitung. Verdachtsfälle werden sofort der IT-Sicherheit gemeldet, betroffene Tokens werden umgehend erneuert.

Eigene Webseiten und Systeme prüfen

Der Fall betrifft vor allem Entwicklerrechner. Wer selbst Dateien zum Download anbietet, ist mit der eigenen Webseite Teil der Kette. Ein Webseiten-Check zeigt, welche Skripte und Header eine Seite ausliefert, er prüft aber nur die Seite, nicht den Rechner von Entwicklern. Für eine systematische Sicherheitsprüfung in Teams bieten die Web Security Checks einen Einstieg.

Fazit

Die Verantwortung liegt beim Anwender, die Technik setzt die Grenze!

Eine fremde Textdatei kann einen Coding-Agenten steuern, weil der Agent Dateien im Arbeitsordner wie Anweisungen behandelt. Verlässlich wird der Schutz erst durch durchgesetzte Grenzen: Berechtigungen, Hooks, Sandbox, Netzwerk-Allowlist und zentral verwaltete Einstellungen.

Offen bleibt, ob Angreifer den Weg über Browser-Downloads in der Praxis nutzen und wie die Datei beim Kunden landete. Wichtig erscheint auf jeden Fall die Sensibilisierung von Mitarbeitern und Entwicklern (bis sie aussterben).