Leitfaden

Claude Code Security: KI-Coding-Agenten im Entwickleralltag absichern

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

Claude Code Security heißt vor allem: festlegen, was der Agent auf Ihrem Rechner ohne Rückfrage tun darf. Claude Code und Cursor lesen Dateien, ändern Code und führen Shell-Befehle mit den Rechten Ihres Benutzerkontos aus, und jeder Text, den der Agent liest, kann versuchen, ihn umzusteuern. Sicher wird der Einsatz durch passende Freigabemodi, harte Deny-Regeln, eine Sandbox mit Netzwerk-Allowlist, geprüfte MCP-Server und eine Team-Richtlinie, die gefährliche Modi abschaltet.

Was ein Coding-Agent auf Ihrem Rechner darf

Ein Chat-Assistent schlägt Code vor, ein Coding-Agent setzt ihn um. Er liest das Repository, legt Dateien an, startet Tests, installiert Pakete und ruft Webseiten ab. Das geschieht in einem lokalen Prozess unter Ihrem Benutzerkonto. Was dieser Prozess erreichen kann, erreicht im Zweifel auch eine Anweisung, die dem Agenten untergeschoben wurde. Die Grundlagen zur Sicherheit handelnder KI-Agenten gelten hier unmittelbar, nur sitzt der Agent nicht auf einem Server, sondern auf dem Entwicklerrechner mit SSH-Schlüsseln, Cloud-Zugängen und Browser-Sitzungen.

Die Hersteller beschreiben die Standardrechte so (Stand der jeweiligen Dokumentation am 28.10.2026):

Wichtig ist eine Einschränkung, die Anthropic selbst nennt: Die Grenze des Arbeitsverzeichnisses ist eine Rückfrage, keine Isolation. Ein Bash-Befehl, den Sie freigeben, kann überall schreiben, wo Ihr Benutzerkonto schreiben darf. Cursor weist zusätzlich darauf hin, dass Änderungen sofort auf der Festplatte landen und bei aktivem Auto-Reload ausgeführt werden können, bevor Sie sie gesehen haben.

Freigabemodi und Sandbox richtig wählen

Die Modi von Claude Code

Claude Code kennt laut Dokumentation zu Berechtigungen sechs Modi. Mit welchem eine Sitzung startet, hängt vom Aufruf ab: Neuere Versionen starten interaktive Sitzungen im Terminal und in VS Code im Modus auto, sofern er verfügbar ist; claude -p und das Agent SDK starten im Modus default. Prüfen Sie den tatsächlichen Modus mit /permissions, statt ihn anzunehmen.

Der Auto-Modus blockiert laut Dokumentation standardmäßig unter anderem das Herunterladen und Ausführen von Code wie curl | bash, das Senden sensibler Daten an externe Endpunkte, Force-Pushes und Produktions-Deployments. Anthropic schreibt aber ausdrücklich, dass der Modus Rückfragen reduziert und keine Sicherheit garantiert. Zu bypassPermissions heißt es, der Modus biete keinen Schutz vor Prompt-Injection. Beide Modi lassen sich mit permissions.disableAutoMode und permissions.disableBypassPermissionsMode abschalten, am wirksamsten in Managed Settings, die Nutzer nicht überschreiben können.

Regeln: deny vor ask vor allow

Regeln werden in fester Reihenfolge ausgewertet: zuerst deny, dann ask, dann allow. Ein Deny auf irgendeiner Ebene lässt sich von keiner anderen Ebene aufheben, auch nicht per Kommandozeile. Zwei Grenzen nennt die Dokumentation selbst:

• Bash-Regeln vergleichen den Befehlstext. Bash(curl *) stoppt curl https://example.com, aber nicht /usr/bin/curl … oder sh -c 'curl …'. Anthropic nennt solche Regeln ausdrücklich keine Sicherheitsgrenze um ein Programm und Muster, die Argumente einschränken, „fragil“.
• Read-Deny-Regeln erfassen nicht jeden Prozess. Read(./.env) greift für die eingebauten Dateiwerkzeuge und erkannte Befehle wie cat oder sed, aber nicht für ein Python- oder Node-Skript, das die Datei selbst öffnet.

Für Grenzen, die nicht vom Befehlstext abhängen, verweist Anthropic auf die Sandbox.

Die Sandbox von Claude Code

Die Sandbox isoliert Shell-Befehle und deren Kindprozesse auf Betriebssystemebene, unter macOS mit Seatbelt, unter Linux und WSL2 mit bubblewrap. Sie basiert auf dem quelloffenen Paket sandbox-runtime. Unter nativem Windows laufen Befehle laut Dokumentation ohne Sandbox. Sie ist standardmäßig ausgeschaltet und wird mit /sandbox oder sandbox.enabled aktiviert. Was Sie wissen sollten:

• Schreiben ist auf das Arbeitsverzeichnis, ein temporäres Verzeichnis und freigegebene Zusatzverzeichnisse begrenzt. Einstellungen, Hooks, .mcp.json, Shell-Startdateien und Git-Hooks bleiben auch darin schreibgeschützt.
• Lesen ist standardmäßig fast überall erlaubt. Die Dokumentation sagt deutlich, dass damit auch ~/.ssh und ~/.aws/credentials lesbar bleiben, solange Sie sie nicht per denyRead sperren.
• Netzwerk läuft über einen lokalen Proxy mit Domain-Allowlist, die leer beginnt. Weit gefasste Einträge wie github.com können laut Anthropic Wege zum Datenabfluss öffnen, weil der Proxy TLS standardmäßig nicht prüft.
• Ausnahmen: Hooks, lokale MCP-Server und die eingebauten Datei- und Webwerkzeuge laufen außerhalb der Sandbox. Scheitert ein Befehl, kann Claude ihn ohne Sandbox wiederholen wollen. Mit allowUnsandboxedCommands: false unterbinden Sie das, mit failIfUnavailable: true verhindern Sie, dass Claude Code bei fehlender Sandbox still ohne sie weiterläuft.

Anthropic fasst es so zusammen: Wirksame Isolation braucht Dateisystem- und Netzwerkgrenze zugleich. Ohne Netzwerkgrenze kann ein kompromittierter Agent SSH-Schlüssel abfließen lassen, ohne Dateisystemgrenze sich weitere Rechte verschaffen.

Cursor-Sicherheit: Run Modes und Sandbox

Cursor steuert die Ausführung über Run Modes: Auto-review (laut Cursor empfohlen) führt Befehle von der Allowlist direkt aus, andere wenn möglich in der Sandbox und den Rest nach Prüfung durch einen Klassifikator. Allowlist führt nur freigegebene Aktionen ohne Rückfrage aus, Run Everything alles ohne Sandbox und Klassifikator. Cursor schreibt selbst, dass Auto-review keine Sicherheitsgrenze ist und der Klassifikator sich irren kann. Die Sandbox nutzt unter macOS Seatbelt, unter Linux Landlock und seccomp. Netzwerk ist darin zunächst gesperrt und wird je nach Netzwerkmodus geöffnet; .git/config, .git/hooks, .vscode und .cursorignore sind geschützt. Teamvorgaben haben Vorrang vor Einstellungen einzelner Nutzer und Projekte.

Prompt-Injection über Repo, Issues, Webseiten und Abhängigkeiten

Die OWASP Top 10 für LLM-Anwendungen 2025 führen Prompt-Injection als LLM01 und unterscheiden direkte von indirekter Injection: Im indirekten Fall stammen die Anweisungen aus externen Inhalten wie Webseiten oder Dateien, die das Modell verarbeitet. OWASP hält fest, dass unklar ist, ob es eine lückenlose Abwehr gibt. Für einen Coding-Agenten ist fast alles externer Inhalt:

• Repository-Inhalte: README, Kommentare, Testdaten, Dokumentation, Agenten-Anweisungsdateien in einem fremden oder geforkten Projekt.
• Issues und Pull Requests: Der Agent soll „das Issue lösen“ und liest dabei Text, den jeder mit Schreibzugriff auf den Tracker verfassen konnte.
• Webseiten: Dokumentation, Foren, Suchergebnisse, die der Agent abruft.
• Abhängigkeiten: Quelltext und Dateien installierter Pakete, die der Agent zur Fehlersuche öffnet.
• Werkzeug-Antworten: Ausgaben von MCP-Servern, Logs, Fehlermeldungen aus Drittsystemen.

Gefährlich wird eine eingeschleuste Anweisung erst durch die Rechte, die der Agent danach nutzen kann: einen Befehl ausführen, eine Konfigurationsdatei anlegen, Daten an eine fremde Adresse senden. OWASP beschreibt das als LLM06 Excessive Agency und empfiehlt, Erweiterungen und Rechte auf das Nötige zu begrenzen und Aktionen mit großer Wirkung von einem Menschen freigeben zu lassen. Genau dafür sind Freigabemodi, Deny-Regeln und Sandbox da.

Claude Code ergänzt einige Schutzschichten: Netzwerkbefehle wie curl und wget werden nicht automatisch freigegeben, WebFetch liefert in den meisten Fällen die Antwort eines separaten Modellaufrufs statt der rohen Seite, und Befehle, die Claude Code nicht vollständig analysieren kann, lösen im Modus Manual eine Rückfrage aus. Anthropic empfiehlt zusätzlich, nicht vertrauenswürdige Inhalte nicht direkt an Claude weiterzureichen und Skripte mit externen Diensten in VMs auszuführen. Wie Injection speziell über MCP-Werkzeugbeschreibungen funktioniert, erklärt unser Artikel zu Prompt-Injection und Tool-Poisoning bei MCP.

MCP-Server, Plugins und Skills als Angriffsfläche

Jeder angebundene MCP-Server erweitert, was der Agent tun kann, und liefert Text in seinen Kontext. Anthropic empfiehlt, eigene MCP-Server zu schreiben oder Server von Anbietern zu nutzen, denen Sie vertrauen, und stellt klar, dass Anthropic MCP-Server nicht sicherheitsprüft oder betreibt. Server aus der projektweiten .mcp.json brauchen in Claude Code eine eigene Freigabe. Die Dokumentation weist aber darauf hin, dass weitere Server aus Benutzer-Einstellungen, Konnektoren und Plugins kommen können. Ein Blick in .mcp.json zeigt also nicht alles, was eine Sitzung lädt.

Cursor verlangt laut Agent-Security-Dokumentation eine Freigabe für jede MCP-Verbindung und danach für jeden Werkzeugaufruf, sofern das Werkzeug nicht auf einer Allowlist steht. Dass eine einmal erteilte Freigabe an einer Datei hängen kann, die sich später ändert, zeigt ein öffentlich dokumentierter Fall:

• CVE-2025-54136 (Cursor): Laut NVD und dem GitHub-Advisory des Herstellers konnte ein Angreifer mit Schreibzugriff auf ein gemeinsames Repository eine bereits freigegebene MCP-Konfiguration nachträglich gegen einen beliebigen Befehl austauschen, ohne dass eine erneute Freigabe verlangt wurde. Behoben in Version 1.3.

Plugins und Skills verdienen dieselbe Sorgfalt: In Claude Code können Plugins MCP-Server und Hooks mitbringen, Skills eigene Hooks und vorab freigegebene Werkzeuge. Behandeln Sie sie wie Software, die Sie installieren. Wie Sie einen MCP-Server selbst absichern, steht in unserem Leitfaden MCP-Server absichern, die Risikoklassen im Überblick in den OWASP MCP Top 10.

Hooks und Konfigurationsdateien im Repository

Hooks sind Shell-Befehle, die Claude Code bei bestimmten Ereignissen automatisch ausführt, mit Ihrer Umgebung und Ihren Rechten. Sie können in .claude/settings.json im Repository stehen und damit mit eingecheckt werden. Das ist für Teams nützlich und zugleich der Grund, warum ein fremdes Repository Code auf Ihrem Rechner ausführen kann, sobald Sie den Agenten darin starten.

Claude Code schützt das mit dem Workspace-Trust-Dialog: In einem nicht vertrauten Ordner fragt eine interaktive Sitzung zuerst, Allow-Regeln aus dem Projekt gelten erst nach Zustimmung. Zwei Details aus der Dokumentation sind entscheidend:

• claude -p und das SDK zeigen keinen Trust-Dialog. Hooks aus den Projekteinstellungen werden dort verwendet, Server aus .mcp.json ohne Rückfrage verbunden. Für fremde Repositories empfiehlt Anthropic --setting-sources user, --bare oder --settings '{"disableAllHooks": true}'. Letzteres nur in der eigenen Benutzer-Konfiguration zu setzen, reicht nicht, weil Projekteinstellungen Vorrang haben.
• Vertrauen in einen übergeordneten Ordner zählt teilweise mit. Hooks eines Projekts werden dann bereits verwendet, Allow-Regeln dagegen erst nach eigener Zustimmung.

Dass diese Grenze ein lohnendes Ziel ist, zeigt CVE-2026-40068: Laut NVD und dem Advisory von Anthropic konnte ein präpariertes Repository über eine Git-Worktree-Datei den Trust-Dialog umgehen und Hooks aus .claude/settings.json sofort ausführen. Voraussetzung war, dass der Angreifer einen bereits vertrauten Pfad kannte oder erriet. Behoben in Version 2.1.84. Bei Cursor beschreibt CVE-2025-54135 (Advisory) eine Kette, in der indirekte Prompt-Injection den Agenten eine noch nicht vorhandene .cursor/mcp.json anlegen ließ, weil das Neuanlegen einer Dotfile keine Freigabe brauchte. Behoben in Version 1.3.9.

Beide Hersteller haben reagiert: Claude Code genehmigt Schreibzugriffe auf geschützte Pfade wie .git, .claude, .vscode, .mcp.json, Shell-Startdateien und .npmrc in keinem Modus automatisch; die Ausnahme ist im Kern bypassPermissions. Cursor verlangt für Konfigurationsdateien eine Freigabe. Der Workspace-Trust von Cursor ist laut Dokumentation standardmäßig ausgeschaltet und lässt sich mit "security.workspace.trust.enabled": true aktivieren; im eingeschränkten Modus funktionieren die KI-Funktionen dann nicht.

Secrets im Kontext: .env, Schlüssel und Tokens

OWASP führt die Offenlegung sensibler Informationen als LLM02. Bei Coding-Agenten liegt das Risiko in zwei Schritten: Ein Secret gelangt in den Kontext, etwa weil der Agent eine .env liest, um einen Fehler zu verstehen. Danach kann es in Logs, Commits, Testdateien oder über eine eingeschleuste Anweisung nach außen gelangen.

• Claude Code: Read-Deny-Regeln wie Read(./.env) oder Read(./secrets/**) sperren die eingebauten Werkzeuge. Für alle Prozesse gilt die Sperre erst mit Sandbox und denyRead. Eine .claudeignore-Datei hat laut Dokumentation keine Wirkung.
• Cursor: .cursorignore sperrt Dateien für Agent und @-Erwähnungen. Laut Dokumentation können Terminal- und MCP-Werkzeuge den Zugriff aber nicht verhindern, und vollständiger Schutz ist nicht garantiert.
• Unabhängig vom Werkzeug: Am sichersten ist ein Secret, das nicht als Klartextdatei im Projekt liegt. Nutzen Sie lokal Entwicklungszugänge mit geringen Rechten, kurzlebige Tokens und einen Secret-Manager. Produktionsschlüssel gehören nicht auf den Entwicklerrechner, auf dem ein Agent läuft.

Wie Secrets in Git und im Frontend-Bundle landen, behandelt unsere Vibe-Coding-Checkliste.

Supply Chain: Pakete, Erweiterungen, Agent-Konfiguration

OWASP führt die Lieferkette als LLM03. Beim Coding-Agenten hat sie drei Ebenen:

• Pakete, die der Agent installiert. Der Auto-Modus von Claude Code erlaubt laut Dokumentation standardmäßig das Installieren von Abhängigkeiten, die in Lockfiles oder Manifesten deklariert sind. Prüfen Sie neue Einträge in diesen Dateien daher im Review wie Code. Install-Skripte von Paketmanagern laufen mit den Rechten des Befehls.
• Erweiterungen des Agenten: MCP-Server, Plugins, Skills, Editor-Erweiterungen. Sie laufen teils außerhalb der Sandbox.
• Konfiguration aus dem Repository: Hooks, .mcp.json, Agenten-Anweisungen. Sie kommen mit jedem git pull und gehören in die Code-Review wie ein CI-Skript.

Claude Code Security im Team: Richtlinie und Härtungs-Checkliste

Einzelne Entwickler können vieles selbst einstellen. Verbindlich wird es erst über zentral verteilte Einstellungen: Claude Code bietet Managed Settings, die Nutzer- und Projekteinstellungen nicht überschreiben können, Cursor Teamvorgaben, die Vorrang vor individuellen Einstellungen haben. Eine Team-Richtlinie für KI-Coding-Agenten sollte mindestens diese Punkte festlegen:

Ein Ausgangspunkt für eine projektweite .claude/settings.json, aufgebaut nach den Beispielen der Dokumentation. Passen Sie Pfade und Domains an Ihr Projekt an:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"]
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org"]
    }
  }
}

Deny-Regeln aus dem Projekt gelten sofort, auch ohne Trust-Dialog, weil sie nur einschränken. Für eine Richtlinie, die niemand lokal aufweichen kann, gehören dieselben Werte in die Managed Settings. Wie Sie den Einsatz von KI-Werkzeugen organisatorisch regeln, beschreibt unser Artikel zur KI-Richtlinie im Unternehmen.

Was eine Konfiguration nicht zeigt

Eine saubere Einstellungsdatei sagt noch nicht, ob sie im Alltag hält: ob eine Ausnahme in excludedCommands die Sandbox aushebelt, ob ein freigegebener MCP-Server mehr darf als gedacht, ob ein Hook im Repository beim nächsten Pull etwas anderes tut oder ob eine Anweisung in einem Issue den Agenten zu einem Datenabfluss bringt. Das zeigt sich erst, wenn jemand die Umgebung gezielt mit den Mitteln eines Angreifers prüft, im vereinbarten Rahmen und auf Systemen, die dafür freigegeben sind.

Häufige Fragen

Weiterlesen

• KI-Agenten absichern: der praktische Überblick
• MCP-Server absichern: der praktische Leitfaden
• Prompt-Injection und Tool-Poisoning bei MCP
• Leistung: KI-Pentest und MCP-Sicherheit

Quellen

• Claude Code Docs: Security
• Claude Code Docs: Configure permissions
• Claude Code Docs: Permission modes
• Claude Code Docs: Sandboxing
• Claude Code Docs: Hooks reference
• Anthropic: sandbox-runtime (GitHub)
• Cursor Docs: Agent Security
• Cursor Docs: Run Modes
• Cursor Docs: Ignore files
• Cursor: Security
• OWASP Top 10 for LLM Applications 2025
• NVD: CVE-2026-40068 und GHSA-q5hj-mxqh-vv77
• NVD: CVE-2025-54136 und GHSA-24mc-g4xr-4395
• NVD: CVE-2025-54135 und GHSA-4cxx-hrm3-49rm