Bei Claude Code Sicherheit geht es darum, mehrere Schichten bewusst einzustellen, statt sich auf eine zu verlassen. Der Berechtigungsmodus legt fest, was Claude ohne Rückfrage darf; seit Version 2.1.283 startet Claude Code im Terminal laut Anthropic im Modus auto, in dem ein separates Prüfmodell riskante Aktionen blockiert; wer jede Aktion selbst freigeben will, nimmt Manual. Allow-, Ask- und Deny-Regeln in den Einstellungen setzt Claude Code selbst durch, nicht das Modell, und eine Deny-Regel gewinnt immer. Die Sandbox begrenzt Shell-Befehle auf Betriebssystemebene, ist aber standardmäßig aus. Hooks blockieren, was nie passieren darf. Secrets gehören in Umgebungsvariablen oder verschlüsselte Dateien, nie in Prompts, und .env-Dateien sperrst du per Deny-Regel. Fremde Inhalte, MCP-Server und Plugins sind eigene Risiken. Für die Prüfung bietet Anthropic /security-review, zwei Plugins und für Enterprise Claude Security.
Ich betreibe mit Claude Code eine Belegschaft aus KI-Mitarbeitern, teils auf einem eigenen Server, mit echten Zugängen zu Konten und Daten. Alles Technische hier stammt aus der Dokumentation von Anthropic, abgerufen am 26.10.2026; weitere Bausteine meines Setups sammle ich auf der Seite Claude.
Das Grundprinzip: Regeln setzt Claude Code durch, nicht das Modell
Der wichtigste Satz der ganzen Berechtigungs-Doku steht in einem Hinweiskasten: „Permission rules are enforced by Claude Code, not by the model.“ Eine Anweisung in deiner CLAUDE.md oder im Prompt beeinflusst, was Claude versucht. Was Claude Code tatsächlich zulässt, entscheiden die Einstellungen, der Modus, die Sandbox und Hooks.
„Bitte lösch nichts“ in einer Arbeitsanweisung ist also eine Bitte, "deny": ["Bash(rm *)"] in der settings.json eine Grenze. Bei meiner Belegschaft gilt deshalb: Was ein Mitarbeiter nicht darf, sperre ich technisch.
Berechtigungsmodi: wie viel Claude ohne Rückfrage darf
Claude Code kennt laut Anthropic sechs Modi:
Seit Version 2.1.283 ist auto der eingebaute Startmodus für Sitzungen im Terminal und in VS Code, bei claude -p und im Agent SDK bleibt es default. Das Prüfmodell blockiert laut Doku standardmäßig unter anderem curl | bash, das Senden sensibler Daten an fremde Ziele, Produktions-Deploys, Force-Push und das unwiderrufliche Löschen von Dateien, die vor der Sitzung schon da waren. Anthropic schreibt aber selbst: „Auto mode reduces permission prompts but does not guarantee safety.“ Für heikle Arbeit ist Manual der richtige Modus.
bypassPermissions, also der Start mit --dangerously-skip-permissions, gehört laut Doku nur in Umgebungen „like containers or VMs where Claude Code can't cause damage“. Einige Dinge genehmigt Claude Code in keinem Modus automatisch, etwa Löschbefehle auf kritische Pfade wie rm -rf ~; die Prüfung kann laut Doku aber Befehle übersehen. Und Schreibzugriffe auf geschützte Pfade wie .git und .claude werden außer in bypassPermissions nie automatisch freigegeben.
Auf meinem Server starte ich die Sitzungen meiner Mitarbeiter ausdrücklich mit --permission-mode acceptEdits, und Läufe ohne Bildschirm ebenfalls mit festem Modus und mit Budgetgrenze, etwa claude -p --permission-mode acceptEdits --max-turns 60 --max-budget-usd 5. Ich lege den Modus selbst fest, statt mich auf den eingebauten Startmodus zu verlassen. Wie das im Ganzen aussieht, steht in Claude Code auf dem Server betreiben. Gesteuert werden diese Sitzungen per Remote Control. Laut Anthropic bleiben Ausführung und Dateizugriff dabei auf dem eigenen Rechner, das Transkript liegt aber, solange die Verbindung steht, auf Anthropics Servern. Das habe ich bewusst akzeptiert, mit einem Team-Konto unter kommerziellen Bedingungen; mehr dazu in Claude Code Remote Control: vom Handy steuern.
Allow, Ask, Deny: Regeln, die wirklich gelten
Mit Regeln verfeinerst du den Modus. Anthropic zeigt in der Einstellungs-Doku dieses Beispiel für ~/.claude/settings.json:
{
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm run test *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)"
]
}
}
Drei Regeln aus der Doku solltest du kennen:
- Die Reihenfolge ist fest: erst Deny, dann Ask, dann Allow. „An allow rule can't carve an exception out of a deny rule.“ Eine Deny-Regel aus irgendeiner Ebene schlägt eine Allow-Regel aus jeder anderen.
- Deny wirkt in jedem Modus, auch in
bypassPermissions. Allow-Regeln haben in bypassPermissions dagegen keine Wirkung.
- Ein ganzer Werkzeugname nimmt das Werkzeug weg. Eine Deny-Regel wie
Bash entfernt das Werkzeug aus Claudes Kontext, eine eingeschränkte wie Bash(rm *) blockiert nur passende Aufrufe. Achtung: Eine Regel für Bash-Befehle prüft den Befehl so, wie er geschrieben ist; Anthropic verweist für verlässliche Netzwerkgrenzen deshalb auf die Sandbox.
Ein Fall aus meinem Betrieb: Für SE Ranking hat unser Schlüssel laut Anbieter dieselben Rechte wie das ganze Konto. Unter den 236 Werkzeugen des MCP-Servers sind deshalb löschende. 28 davon habe ich per Deny-Regel mit vollem Namen gesperrt, etwa mcp__se-ranking__PROJECT_deleteProject. Warum einzeln und nicht per Muster, steht in Claude SEO: SEO mit Claude Code und MCP.
Eine Sicherheitsfalle betrifft Projekte, die du nicht selbst geschrieben hast. Allow-Regeln aus der .claude/settings.json eines fremden Repositorys wendet Claude Code erst an, wenn du dem Ordner im Vertrauensdialog vertraust; Deny- und Ask-Regeln gelten sofort, weil sie nur einschränken. Hooks aus den Einstellungen eines Repositorys laufen dagegen laut Doku auch dann, wenn du nur einem übergeordneten Ordner vertraut hast, und bei claude -p ganz ohne Dialog. Vor einem claude -p in einem fremden Repository empfiehlt Anthropic deshalb unter anderem --settings '{"disableAllHooks": true}' oder --setting-sources user.
Sandbox: Grenzen auf Betriebssystemebene
Die Sandbox ist laut Anthropic „a boundary that the operating system enforces around the shell commands Claude runs on your machine“. Sie läuft unter macOS, Linux und WSL2, nicht unter nativem Windows, und ist standardmäßig aus. Du schaltest sie mit /sandbox ein oder dauerhaft mit "sandbox": {"enabled": true} in den Einstellungen.
Was sie standardmäßig tut und was nicht, ist wichtig:
- Schreiben nur im Arbeitsordner, in einem Temp-Ordner und in freigegebenen Ordnern.
- Netzwerk nur über einen lokalen Proxy, der jede Adresse gegen deine Liste erlaubter Domains prüft; die Liste ist anfangs leer.
- Lesen dagegen fast überall, ausdrücklich auch
~/.ssh und ~/.aws/credentials, solange du das nicht sperrst.
- Umgebungsvariablen erbt die Sandbox, „including any secrets in its environment“.
Für die letzten beiden Punkte gibt es den Block sandbox.credentials: Dateien und Variablen mit "mode": "deny" sind für Befehle in der Sandbox gesperrt, Variablen werden vor jedem Befehl entfernt. Eine eingebaute Sperrliste gibt es laut Doku nicht, nur was du einträgst, ist geschützt.
Wichtig: Scheitert ein Befehl in der Sandbox, darf Claude ihn laut Doku außerhalb der Sandbox erneut versuchen. Im Modus Manual fragt Claude Code dann nach, im Modus auto entscheidet das Prüfmodell, und eine passende Allow-Regel lässt ihn ohne Rückfrage durch. Soll die Sandbox eine harte Grenze sein, setzt du "allowUnsandboxedCommands": false.
Und die Sandbox umschließt nur Shell-Befehle. Claudes Datei-Werkzeuge folgen den Berechtigungsregeln, und Hooks, lokale MCP-Server und Hilfsbefehle laufen laut Doku „with your full access“. Wer alles hinter eine Grenze bringen will, startet Claude Code als Ganzes in einem Container oder einer VM.
Hooks als Leitplanke
Ein Hook ist ein Befehl, den Claude Code an festen Punkten immer ausführt. Für Sicherheit zählt vor allem PreToolUse: Er läuft vor jedem Werkzeugaufruf und kann ihn ablehnen. Laut Doku gilt: „A blocking hook also takes precedence over allow rules.“ Ein Hook, der mit Exit-Code 2 endet, stoppt den Aufruf, bevor die Berechtigungsregeln geprüft werden. Umgekehrt hebt ein allow aus einem Hook keine Deny- oder Ask-Regel auf.
Anthropics Anleitung zeigt als Beispiel einen Hook, der Änderungen an .env, package-lock.json und allem unter .git/ blockiert. Wie du so etwas aufsetzt, steht in Claude Code Hooks: Regeln, die immer gelten. Ein Hook ist aber selbst Code mit deinen Rechten; lies Hooks aus fremden Projekten und Plugins, bevor du sie laufen lässt.
Secrets: nie im Klartext
Schlüssel, Tokens und Passwörter gehören nicht in Prompts, nicht in die CLAUDE.md und nicht in Dateien, die Claude lesen darf. Drei Gründe aus der Doku:
- Sitzungen liegen lokal im Klartext. Laut Anthropic speichert Claude Code Sitzungen 30 Tage lang „locally in plaintext under
~/.claude/projects/“. Ein Schlüssel, den du in den Chat kopierst, liegt dort mit.
- Die Sandbox erbt deine Umgebung. Ohne
sandbox.credentials sehen Befehle alle Variablen, die du exportiert hast.
.claudeignore gibt es nicht. Laut Doku hat eine solche Datei „no effect“; sperren musst du per Read-Deny-Regel wie Read(./.env) oder Read(./secrets/**).
Claude Code selbst legt seine Zugangsdaten laut Doku im macOS-Schlüsselbund ab, unter Linux in einer Datei mit Rechten 0600. Für deine eigenen Schlüssel gilt die bekannte Regel: Umgebungsvariable statt Code, .env in die Ignore-Liste von Git. Wie das bei einem API-Schlüssel konkret aussieht, steht in Claude API: Key, Kosten und Einstieg.
Bei mir liegen alle Zugänge mit SOPS verschlüsselt im Repository. Der Server hat einen eigenen age-Schlüssel als zweiten Empfänger, mein privater Schlüssel liegt nie dort. Ein Skript entschlüsselt bei der Installation nur die Zugänge des jeweiligen Mitarbeiters in eine .env, die Git ignoriert und nur der Arbeitsbenutzer lesen darf; in Konfigurationsdateien wie der .mcp.json stehen im Repository nur Platzhalter wie ${API_KEY}. Ehrlich dazu: Ein Secret-Scan mit gitleaks vor jedem Push ist bei uns eine Regel im Regelwerk, keine Automatik.
Prompt Injection aus fremden Inhalten
Prompt Injection ist laut Anthropic „a technique where an attacker attempts to override or manipulate an AI assistant's instructions by inserting malicious text“. Das kann in einer Webseite stecken, einem Issue, einer PDF, einer Mail, die Claude liest. Claude Code hat laut Sicherheits-Doku mehrere Schutzschichten: Netzwerkbefehle wie curl und wget werden nicht automatisch freigegeben, WebFetch gibt Claude meist eine Zusammenfassung statt der Rohseite, Befehle, die Claude Code nicht vollständig analysieren kann, lösen im Modus Manual eine Rückfrage aus, und das Prüfmodell im Modus auto blockiert Aktionen, die nach feindlichem Inhalt aussehen.
Anthropics eigene Empfehlungen für fremde Inhalte sind kurz: Befehle vor der Freigabe lesen, fremde Inhalte nicht direkt an Claude weiterleiten, Änderungen an kritischen Dateien prüfen, für Skripte und Werkzeugaufrufe mit externen Diensten VMs nutzen. Und: „no system is completely immune to all attacks.“
Für meine Belegschaft heißt das: Was ein Mitarbeiter nicht darf, sperre ich technisch, etwa löschende Werkzeuge eines MCP-Servers per Deny-Regel. Und was das Haus verlässt oder etwas verändert, ein Mailversand, ein Deploy, eine Anzeige, geht nur mit meinem ausdrücklichen Wort raus, und der Mitarbeiter hält das Wort mit Zeitpunkt im Protokoll fest.
MCP-Server und Plugins: fremder Code mit deinen Rechten
Zu MCP-Servern schreibt Anthropic: „We encourage either writing your own MCP servers or using MCP servers from providers that you trust.“ Anthropic prüft Connectors vor der Aufnahme ins eigene Verzeichnis, „but does not security-audit or manage any MCP server“. Server aus der .mcp.json eines Projekts fragt Claude Code vor dem Verbinden ab; bei claude -p in einem nie vertrauten Ordner verbindet Claude Code sie laut Doku ohne Rückfrage. Wie du Server einrichtest und welche Rechte du ihnen gibst, steht in Claude MCP Server einrichten.
Plugins sind noch weitreichender. Die Plugin-Doku beginnt mit dem Satz: „A Claude Code plugin you install can execute arbitrary code on your machine with your user privileges.“ Ein Plugin kann Hooks, Hintergrundprozesse, MCP-Server und ausführbare Dateien mitbringen, und bei eingeschaltetem Auto-Update ändern sich die Dateien, die du geprüft hast, im Hintergrund. Berechtigungsregeln und Sandbox decken laut Doku die Werkzeugaufrufe von Claude ab, nicht den Code, den ein Plugin selbst startet. Worauf du vor der Installation achtest, steht in Claude Code Plugins: installieren und bauen.
Security Reviews: vier Werkzeuge von Anthropic
Anthropic stellt die Prüfwerkzeuge in der Doku als Schichten dar:
Wichtig sind die ehrlichen Grenzen, die Anthropic selbst nennt. Das Plugin security-guidance lässt Claudes Code von einem getrennten Aufruf „with a fresh context“ prüfen, blockiert aber nichts: „None of the layers block writes or commits.“ /security-review braucht einen Remote namens origin. Und zu Code Review heißt es: „A review with no findings doesn't mean your code is error-free or secure.“ Den Ablauf von Code Review beschreibe ich in Claude Code Review: Kosten, Ablauf, Grenzen.
Das passt zu einer Hausregel, die bei mir für alles gilt: Wer etwas erstellt, prüft es nicht selbst. Bei Sebastian, meinem SEO-Mitarbeiter, liest eine getrennte Prüfrolle den Bericht gegen die Rohdaten, bevor ich ihn sehe. Ein Sicherheitsreview ist dieselbe Idee, angewendet auf Code.
Für Teams und Unternehmen
Für Organisationen empfiehlt Anthropic verwaltete Einstellungen (managed settings), die Nutzer und Projekte nicht überschreiben können. Damit lassen sich etwa bypassPermissions und auto abschalten (permissions.disableBypassPermissionsMode und permissions.disableAutoMode auf "disable"), Berechtigungsregeln zentral vorgeben, erlaubte MCP-Server festlegen und Plugins für alle einschalten. Zur Überwachung nennt die Doku OpenTelemetry-Metriken und ConfigChange-Hooks.
Für Enterprise gibt es zusätzlich Claude Security. Auf claude.com steht dazu: „Claude scans your codebase with Claude Mythos, validates findings, and suggests patches you can review and approve. Available in public beta for Claude Enterprise.“ Das gleichnamige Plugin für Claude Code nutzt dagegen die Modelle deines Kontos, nicht Mythos. Was Enterprise sonst unterscheidet, steht in Claude Enterprise oder Team: Kosten, DSGVO.
Häufige Fragen
Ist Claude Code sicher?
So sicher, wie du es einstellst. Anthropic baut mehrere Schutzschichten ein, sagt aber selbst, dass kein System gegen alle Angriffe immun ist und du für die Prüfung vorgeschlagener Befehle verantwortlich bist. Mit Deny-Regeln für Kritisches, eingeschalteter Sandbox und Secrets außerhalb von Claudes Reichweite senkst du das Risiko.
Was ist der sicherste Berechtigungsmodus?
Für Arbeit, bei der du selbst dabei bist, Manual (default): Claude darf nur lesen und fragt vor allem anderen. Für Skripte und CI ist dontAsk mit einer genauen Erlaubnisliste gedacht. bypassPermissions gehört laut Anthropic nur in Container oder VMs.
Wie verhindere ich, dass Claude Code meine .env liest?
Mit Deny-Regeln wie Read(./.env) und Read(./.env.*) in der settings.json. Für Befehle in der Sandbox sperrst du Dateien und Variablen zusätzlich über sandbox.credentials. Eine .claudeignore wirkt laut Doku nicht.
Was ist Claude Security?
Ein Produkt von Anthropic, das Repositories mit Claude Mythos auf Schwachstellen scannt, Funde prüft und Patches vorschlägt, laut claude.com „available in public beta for Claude Enterprise“. Das Plugin claude-security für Claude Code gibt es dagegen für alle Claude-Code-Nutzer in Beta.
Was macht /security-review?
Er prüft laut Anthropic die Änderungen deines aktuellen Branches gegenüber dem Standard-Branch auf origin, etwa auf Injection, Fehler bei der Authentifizierung und offengelegte Daten. Ein einzelner Durchlauf auf Abruf, kein dauerhafter Schutz.
Wie du weitermachst
Fang mit drei Schritten an: Deny-Regeln für .env und alles, was nie passieren darf, die Sandbox mit /sandbox einschalten und mit "allowUnsandboxedCommands": false dicht machen, deine Secrets aus Prompts und lesbaren Dateien holen. Danach lohnt ein Blick auf Claude Code Hooks: Regeln, die immer gelten und auf die Datenschutzseite, Claude Datenschutz und DSGVO: was gilt. Wenn du Claude Code mit anderen Werkzeugen vergleichst, helfen Claude Code vs Cursor: was passt zu dir? und Claude Code vs GitHub Copilot im Vergleich. Und wie ich Freigaben, Zugänge und Prüfrollen in meiner Belegschaft organisiere, zeige ich in meiner deutschsprachigen Community Claude Practitioners.
