CLAUDE.md ist kein Schutzschild: Claude Code Security 2026

Claude Code lädt CLAUDE.md zusammen mit dem Projektkontext in die Arbeitssitzung. Das Modell verarbeitet die Datei mit Prompts, Repository-Dateien und weiteren Anweisungen. CLAUDE.md als Sicherheitskontrolle zu behandeln, ist ein Architekturfehler, weil Anweisungen im Modellkontext weder Datei- noch Netzwerkzugriffe technisch sperren. Permissions, blockierende Hooks und die Sandbox greifen dagegen am Tool-Aufruf oder am gestarteten Prozess. Das ist eine andere Schutzebene.

Für Teamregeln sind drei Zugriffspfade relevant: native Tool-Aufrufe, Prozesse aus Bash und lokal registrierte Hooks. Jede Vorgabe muss an dem Pfad greifen, über den die unerwünschte Wirkung entsteht. Eine Lesesperre für das Read-Tool deckt beispielsweise keinen cat-Aufruf ab.

Warum CLAUDE.md allein Claude Code nicht absichert

Anweisungen wie „Lies niemals .env-Dateien“ oder „Führe keinen git push aus“ beschreiben erwartetes Verhalten. Sie verhindern keinen Systemaufruf. Eine Permission kann den passenden Tool-Aufruf verweigern, ein PreToolUse-Hook kann ihn blockieren, während die Sandbox den verfügbaren Datei- und Netzwerkbereich begrenzt.

Für CLAUDE.md eignen sich Informationen, die Claude Code beim Bearbeiten des Repositorys benötigt:

• Die Repository-Struktur und die Modulgrenzen
• Die eingesetzten Frameworks und Versionen
• Die Befehle für Unit- und Integrationstests
• Die Namens- und Formatierungskonventionen
• Die Anforderungen an Pull Requests

Die Datei kann den passenden Testbefehl nennen, aber weder dessen Ausführung erzwingen noch fehlerhaften Code am Merge hindern. CI-Prüfungen und Code-Reviews müssen Fehler deshalb unabhängig vom Modell erkennen.

Steuernder Kontext beeinflusst die Modellausgabe. Technische Kontrollen begrenzen konkrete Zugriffe. Aus dieser Unterscheidung ergibt sich die Auswahl des passenden Mechanismus.

Welche Claude-Code-Kontrolle passt zu welcher Vorgabe?

CLAUDE.md speichert Architekturwissen und Repository-Kontext. Rules, Skills und Subagents gliedern Arbeitsanweisungen oder begrenzen den Kontext einzelner Aufgaben. Verbindliche Zugriffsregeln gehören in Permissions, Hooks, Sandbox oder Managed Settings.

Die erste Anwendung betrifft Dateien, deren Inhalt nicht in den Modellkontext gelangen darf.

Secrets und vertrauliche Dateien schützen

Eine Deny-Regel für das Read-Tool sollte Umgebungsdateien wie .env und .env.production, Verzeichnisse mit Zugangsdaten sowie private Schlüssel abdecken. Produktive Tokens, Kennwörter und vertrauliche Inhalte gehören auch nicht in CLAUDE.md, Rules oder Skills, weil Claude Code diese Dateien als Kontext verarbeitet.

Permissions und Sandbox-Regeln müssen deshalb dieselben vertraulichen Pfade abbilden. Die Deny-Regel verhindert den direkten Read-Aufruf, während die Sandbox den Dateizugriff eines Unterprozesses unterbindet. Nach den Leserechten folgen Befehle mit externen oder zerstörerischen Auswirkungen.

Gefährliche Befehle nur nach Freigabe ausführen

Claude Code wertet Permission-Regeln in der Reihenfolge deny, ask und allow aus. Ein passendes Verbot hat Vorrang. Eine Ask-Regel verlangt eine Freigabe, sofern keine Deny-Regel greift.

Eine Teamrichtlinie sollte für die folgenden Aufrufe je nach Betriebskonzept eine Ask- oder Deny-Regel festlegen:

• git push in gemeinsam genutzte Repositorys
• Deployment-Befehle für gemeinsam genutzte Umgebungen
• terraform destroy
• Löschoperationen mit kubectl
• Befehle mit Zugangsdaten für Produktionssysteme

Breite Allow-Muster für Bash können solche Aufrufe unbeabsichtigt erfassen. Zusammengesetzte Shell-Befehle, Wrapper-Skripte und Aliase verändern außerdem die sichtbare Befehlsform. Ein Hook kann diese Varianten vor der Ausführung prüfen.

Claude-Code-Hooks als verbindliche Prüfstelle

Ein PreToolUse-Hook läuft vor dem Tool-Aufruf und erhält dessen Eingabedaten. Er kann einen Aufruf blockieren, selbst wenn eine Allow-Regel ihn zulassen würde. Das Prüfskript liest die strukturierten Tool-Eingaben und gleicht normalisierte Bash-Kommandos mit einer zentral gepflegten Richtlinie ab.

Projekt-Hooks lassen sich in .claude/settings.json hinterlegen und mit dem Repository versionieren. Das folgende Fragment bindet eine Prüfung vor Bash-Aufrufen und ein Skript nach Dateiänderungen ein:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": ".claude/hooks/guard-bash.sh"
      }]
    }],
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": ".claude/hooks/check-changes.sh"
      }]
    }]
  }
}

Der PostToolUse-Hook kann anhand der geänderten Dateipfade den Formatter, den Linter und betroffene Tests starten. Er macht einen bereits erfolgten Schreibzugriff nicht rückgängig, meldet einen fehlgeschlagenen Check aber unmittelbar. Bash benötigt für Zugriffe außerhalb einzelner Tools zusätzlich eine Sandbox-Grenze.

Dateisystem und Netzwerk mit der Sandbox begrenzen

Tool-spezifische Permissions erfassen nicht automatisch jeden Prozess, den eine Shell startet. Die Claude-Code-Sandbox begrenzt, welche Verzeichnisse Bash lesen oder verändern darf und welche Netzwerkziele erreichbar sind. Ein Projekt kann den Quellcode beschreibbar lassen, Secret-Verzeichnisse sperren und ausgehende Verbindungen auf benötigte Paketquellen oder interne Dienste beschränken.

Bypass-Tests müssen alternative Zugriffswege abdecken:

• cat, sed und awk dürfen gesperrte Dateien nicht lesen
• Python- und Node.js-Prozesse dürfen dieselben Pfade nicht öffnen
• Symbolische Links dürfen keine Verzeichnisgrenze umgehen
• Umgeleitete Shell-Ausgaben dürfen keine geschützten Ziele überschreiben

Wenn diese Grenzen für alle Projekte gelten, dürfen lokal veränderbare Projektdateien sie nicht aufheben. Diese Aufgabe übernehmen Managed Settings.

Verbindliche Vorgaben im Team verteilen

Repository-spezifische Settings und Hooks gehören in Pull Requests, damit das Team Änderungen am Berechtigungsmodell wie Quellcode prüfen kann. Unternehmensweite Anforderungen liegen dagegen in Managed Settings. Administratoren können den Modus zum Umgehen von Permissions deaktivieren, zentral definierte Regeln erzwingen und lokale oder projektbezogene Hooks ausschließen.

Die Organisation muss auch festlegen, ob Entwickler eigene Hooks registrieren dürfen. Ein lokaler Hook kann zusätzliche Prüfungen ausführen, erhält aber möglicherweise vertrauliche Tool-Eingaben. Deshalb gehören die erlaubten Hook-Quellen und Skriptpfade in das zentrale Berechtigungsmodell.

Aus diesen Zuständigkeiten lässt sich eine Basiskonfiguration für neue Repositorys ableiten.

Minimale Teamkonfiguration als Ausgangspunkt

Die konkrete Ausführung hängt von den Repository-Pfaden, den verwendeten Werkzeugen und der eingesetzten Claude-Code-Version ab. Mehrere Kontrollen müssen denselben Zugriffspfad abdecken, wenn ein Tool-Aufruf über einen Unterprozess umgangen werden kann.

• Permissions verweigern Read-Zugriffe auf .env, Verzeichnisse mit Zugangsdaten, private Schlüssel und Secret-Verzeichnisse
• Ask-Regeln verlangen eine Freigabe für git push, Deployments und kritische Shell-Befehle
• Ein PreToolUse-Hook blockiert verbotene Bash-Aufrufe und zusammengesetzte Befehle
• Ein PostToolUse-Hook startet den Formatter, den Linter und betroffene Tests nach Dateiänderungen
• Die Sandbox sperrt vertrauliche Pfade auch für Unterprozesse und begrenzt Netzwerkziele
• Managed Settings verhindern lokale Ausnahmen von unternehmensweiten Vorgaben
• Pull Requests zeigen jede Änderung an Settings, Hooks und Sandbox-Regeln

Eine CODEOWNERS-Regel kann einer festen Rolle die Prüfung von .claude/settings.json und .claude/hooks/ zuweisen. Die CI führt die Tests der Hook-Skripte nach jeder Änderung aus. Damit verschiebt sich die Prüfung von einzelnen Dateien auf vollständige Zugriffspfade.

Security-Review-Checkliste für Claude Code

• Bash und andere Unterprozesse dürfen Read-Sperren nicht umgehen
• Destruktive Befehle und externe Seiteneffekte verlangen eine ausdrückliche Freigabe
• PreToolUse-Hooks blockieren bekannte Umgehungsvarianten anhand definierter Regeln
• Hooks liegen versioniert vor und besitzen Tests für erlaubte sowie verbotene Eingaben
• Lokale Settings dürfen verbindliche Unternehmensregeln nicht überschreiben
• Tests, Code-Reviews und Eingabevalidierung bleiben unabhängig von Claude Code aktiv
• CLAUDE.md enthält keine produktiven Zugangsdaten oder Sicherheitsversprechen ohne technische Kontrolle

Ein aussagekräftiger Review verwendet eine Dummy-Datei ohne echte Secrets und versucht den Zugriff über Read, Bash, Python und einen symbolischen Link. Lege diesen Bypass-Test im Test-Repository an und führe ihn nach jeder Änderung an Permissions, Hooks oder Sandbox-Regeln aus. Mehr erfährst du in usnerem Claude Code Grundkurs und für nicht Entwickler in unserem Claude Cowork Automatisierungskurs.