Claude Code Sicherheit: Rechte, Sandbox und Secrets

TL;DR

Claude Code Sicherheit beruht auf vier Ebenen: Berechtigungsregeln, der Bash-Sandbox auf Betriebssystemebene, Managed Settings, die Entwickler nicht überschreiben können, und Hooks. Deny-Regeln allein sind keine Grenze. Seit v2.1.283 starten Sitzungen standardmäßig im Auto-Modus. Wir empfehlen eine zentrale Vorgabe mit Pflicht-Sandbox, gesperrten .env-Dateien und deaktiviertem Bypass-Modus.

Wovor schützt Claude Code Sicherheit eigentlich?

Es geht um ein einziges Risiko: einen Agenten mit Shell-Zugriff, der Anweisungen ausführt, die Sie nicht gegeben haben. Dazu zählen Prompt Injection aus Dateien, Webseiten oder MCP-Tools, versehentlich gelesene Secrets und Datenabfluss über das Netzwerk. Die Gegenmittel heißen Berechtigungen, Sandbox, Managed Settings und Hooks. Keines reicht allein.

Die Sicherheitsseite von Anthropic beschreibt die Grundeinstellung. Im Manual-Modus startet Claude Code nur lesend, fragt vor Änderungen und vor Bash-Befehlen, die das System verändern können, und schreibt nur in den Ordner, in dem es gestartet wurde. Befehle wie curl und wget werden nicht automatisch freigegeben. Web-Abrufe laufen in einem eigenen Kontextfenster, damit eine präparierte Seite nicht direkt in die Hauptunterhaltung schreibt. Neue Repositories und neue MCP-Server brauchen eine Vertrauensbestätigung. Für Nachweise verweist Anthropic auf einen SOC-2-Type-2-Bericht und ein ISO-27001-Zertifikat im Trust Center.

Das gilt für einen einzelnen Entwickler. Im Unternehmen kommen drei Probleme hinzu: Entwickler ändern ihre eigenen Einstellungen, CI-Pipelines starten Claude Code ohne Aufsicht, und die Standardwerte ändern sich mit jedem Release. Die Tabelle zeigt, was welche Ebene durchsetzt.

Ebene	Was sie durchsetzt	Was sie nicht abdeckt
Berechtigungsregeln	Welche Tools, Dateien und Domains Claude nutzen darf	Programme in anderer Aufrufform, z. B. sh -c
Bash-Sandbox	Datei- und Netzwerkgrenzen auf OS-Ebene für Shell-Befehle und Kindprozesse	Read-, Edit- und Write-Tools; natives Windows
Managed Settings	Vorgaben, die Benutzer, Projekt und CLI-Flags nicht überschreiben	Rechner ohne MDM-Abdeckung
Hooks	Eigene Prüfungen vor oder nach einem Tool-Aufruf	Alles, was Sie nicht skripten
Dev Container	Eine wegwerfbare Maschinengrenze	Daten, die Sie in den Container mounten

Art. 32 DSGVO verlangt technische Maßnahmen, die dem Risiko angemessen sind, und ein Verfahren zur regelmäßigen Überprüfung ihrer Wirksamkeit. Für einen Coding-Agenten mit Shell-Zugriff heißt das aus unserer Sicht: erzwungene Sandbox, schriftliche Policy-Datei, fester Prüfzyklus. Wo der Claude-Datenverkehr selbst verarbeitet wird, ist eine eigene Frage. Die beantwortet unser Artikel zu Claude Datenschutz im Unternehmen.

Wie funktionieren Berechtigungsmodi und Allow- und Deny-Regeln?

Claude Code prüft Berechtigungsregeln in fester Reihenfolge: zuerst deny, dann ask, dann allow. Der erste Treffer entscheidet, Spezifität spielt keine Rolle. Ein breites Bash(aws *) in deny schlägt ein enges Bash(aws s3 ls) in allow. Ein Deny aus den Managed Settings lässt sich weder über Benutzer- oder Projekteinstellungen noch über --allowedTools aufheben.

Die Berechtigungsreferenz nennt sechs Modi. default (angezeigt als Manual) fragt beim ersten Einsatz jedes Tools. acceptEdits gibt Dateiänderungen und gängige Dateisystembefehle im Arbeitsverzeichnis frei. plan liest und schlägt vor, ohne zu ändern. auto arbeitet ohne Routine-Rückfragen, ein Klassifizierer-Modell prüft die Aktionen. dontAsk lehnt alles ab, was eine Rückfrage auslösen würde. bypassPermissions überspringt Rückfragen, laut Doku nur für isolierte Container oder VMs gedacht.

Die Änderung, die viele Sicherheitsteams noch nicht bemerkt haben: Ab v2.1.283 ist der Auto-Modus der eingebaute Startmodus für interaktive Terminal- und VS-Code-Sitzungen, auf jedem Plan und bei jedem Provider, also auch auf Bedrock und Google Cloud. Laut Seite zu den Berechtigungsmodi startet claude -p bei Drittanbietern ab v2.1.285 ebenfalls im Auto-Modus. Auf Bedrock, Google Cloud und Foundry braucht der Auto-Modus Sonnet 5 oder neuer, Opus 4.7 oder neuer oder ein Fable-Modell, und jede Klassifizierer-Prüfung zählt zu Ihrer Token-Rechnung. Anthropic selbst warnt: Der Auto-Modus reduziert Rückfragen, garantiert aber keine Sicherheit.

Die zweite Falle ist, worauf eine Bash-Regel greift. Sie prüft den Befehlstext, den Claude schreibt, nicht das Programm.

Deny-Regel	Stoppt	Stoppt nicht
Bash(curl *)	curl https://example.com	/usr/bin/curl ..., sh -c 'curl ...'
Bash(rm *)	rm -rf build/	/bin/rm -rf build/, bash -c 'rm -rf build/'
Bash(git push *)	git push origin main	git -C . push origin main

Bash-Deny-Regeln sind also Leitplanken für normales Verhalten, keine Sicherheitsgrenze. Für Dateien und Netzwerk setzt die Sandbox durch. Allow-Regeln aus der .claude/settings.json eines Repositories greifen erst, wenn ein Entwickler den Vertrauensdialog bestätigt. Deny- und Ask-Regeln greifen sofort, weil sie nur einschränken.

Wie sperren Sie Bash in die Sandbox und Secrets aus?

Die Sandbox setzt Datei- und Netzwerkgrenzen auf Betriebssystemebene für jeden Shell-Befehl und dessen Kindprozesse durch. Auf macOS nutzt sie Seatbelt, auf Linux und WSL2 bubblewrap und socat. Natives Windows wird nicht unterstützt. Schalten Sie die Sandbox ein, machen Sie sie verpflichtend, listen Sie Ihre Credential-Pfade auf und sperren Sie .env zusätzlich für die Datei-Tools.

Die Standard-Leseregel überrascht viele. Die Sandbox-Doku sagt klar, dass Sandbox-Befehle standardmäßig den gesamten Rechner lesen dürfen, inklusive ~/.aws/credentials und ~/.ssh/. Eine eingebaute Deny-Liste für Zugangsdaten gibt es nicht: Geschützt ist nur, was Sie unter sandbox.credentials eintragen. Schreiben darf die Sandbox ins Arbeitsverzeichnis, in hinzugefügte Verzeichnisse und in ein benutzereigenes Temp-Verzeichnis.

Drei Einstellungen machen aus der Sandbox ein Kontrollinstrument:

1. sandbox.failIfUnavailable: true verhindert den Start, wenn bubblewrap fehlt, statt mit Warnung ohne Sandbox weiterzulaufen.
2. sandbox.allowUnsandboxedCommands: false entfernt den Notausgang, über den Claude einen blockierten Befehl außerhalb der Sandbox wiederholt.
3. sandbox.network.allowManagedDomainsOnly: true lässt nur die Domain-Allowlist aus den Managed Settings gelten und blockiert alles andere ohne Rückfrage.

Kennen Sie die Grenzen. Der eingebaute Proxy entscheidet nach Hostname und prüft TLS standardmäßig nicht. Anthropic warnt, dass breite Domains wie github.com Wege zur Exfiltration öffnen können, Domain Fronting eingeschlossen. Für excludedCommands gibt es keine reine Managed-Sperre. Seit v2.1.282 ignoriert Claude Code Einträge aus Projekt- und lokalen Einstellungen, sobald die Managed Settings allowUnsandboxedCommands: false setzen. Die eigenen Benutzereinstellungen eines Entwicklers können aber weiter Befehle außerhalb der Sandbox freigeben. docker läuft nicht in der Sandbox und landet meist dort.

Für Secrets kombinieren Sie zwei Mechanismen. permissions.deny-Regeln wie Read(.env) blenden passende Dateien aus der Suche aus, sperren das Lesen und blockieren auch Edit und Write auf diesen Pfaden. Sie greifen außerdem bei cat, head und Umleitungen. Die Settings-Referenz stellt klar, dass sie grep -r pattern . und beliebige Unterprozesse nicht erfassen. Deshalb zählen die Sandbox-Einträge denyRead und credentials. Drittens setzen Sie CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1. Die Variable entfernt Anthropic- und Cloud-Zugangsdaten aus der Umgebung von Bash, Hooks und MCP-stdio-Servern, während der Hauptprozess sie für API-Aufrufe behält. Auf Bedrock bleibt so die AWS-Sitzung, die die Tokens bezahlt, außerhalb der Reichweite einer Shell-Expansion.

Wie geht Claude Code mit Prompt Injection um?

Claude Code dämpft Prompt Injection mit Freigabe-Rückfragen, einem eigenen Kontextfenster für Web-Abrufe, Vertrauensdialogen für neue Repositories und MCP-Server sowie der Erkennung verdächtiger Bash-Befehle. Im Auto-Modus blockiert der Klassifizierer zusätzlich Aktionen, die nach feindlichen Inhalten aussehen. Nichts davon hilft, wenn ein Angreifer in einem unbeaufsichtigten Lauf die Repository-Konfiguration kontrolliert.

Der riskanteste Fall ist CI. Mit -p ist die Vertrauensprüfung abgeschaltet. Die Berechtigungsseite listet, was ein Repository bei claude -p oder im SDK in einem nie vertrauten Ordner liefern darf: Hooks in Settings-Dateien, den env-Block, Helper-Befehle und Server aus .mcp.json, alles ohne Rückfrage. Ein Pull Request, der einen Hook hinzufügt, führt also Code auf Ihrem Runner aus. Für Pipelines mit fremdem Code nennt die Doku drei Gegenmittel: --setting-sources user, damit Projekteinstellungen und .mcp.json nicht gelesen werden, --bare, damit keine Projekt-Hooks, Skills oder MCP-Server laden, und --settings '{"disableAllHooks": true}'.

Hooks sind zugleich Ihr eigenes Kontrollwerkzeug. Ein PreToolUse-Hook erhält die Tool-Eingabe als JSON und kann den Aufruf ablehnen. Exit-Code 2 blockiert auch dann, wenn das JSON des Hooks allow sagt, und eine Deny-Regel gewinnt immer gegen eine Hook-Entscheidung. Ein ConfigChange-Hook kann Änderungen an Benutzer-, Projekt- und lokalen Einstellungen während der Sitzung blockieren, nicht aber Änderungen an Managed Policies, die gelten immer. Setzen Sie allowManagedHooksOnly: true, dann laufen nur Hooks aus den Managed Settings und aus zwangsaktivierten Plugins. Nebenwirkung: /goal funktioniert dann nicht mehr.

MCP braucht eine eigene Regel. Anthropic prüft Konnektoren im eigenen Verzeichnis anhand von Aufnahmekriterien, führt aber für keinen MCP-Server ein Sicherheitsaudit durch. Nutzen Sie allowManagedMcpServersOnly mit einer Allowlist. Für Agenten mit --dangerously-skip-permissions gehört der Dev Container dazu. Die Referenzkonfiguration läuft als Nicht-Root-Benutzer und bringt mit init-firewall.sh eine Egress-Allowlist mit. Anthropic weist darauf hin, dass ein bösartiges Projekt auch dann alles im Container abziehen kann, einschließlich der Claude-Code-Zugangsdaten in ~/.claude.

Wie sieht eine gehärtete Managed-Settings-Vorlage aus?

Legen Sie die Vorgaben in managed-settings.json ab und verteilen Sie sie per MDM oder als Datei im Systemverzeichnis. Managed Settings stehen an der Spitze der Rangfolge. Die Vorlage unten erzwingt die Sandbox, schützt Secrets, deaktiviert den Bypass-Modus und beschränkt Hooks. Passen Sie Domain-Liste und Credential-Pfade vor dem Rollout an.

{
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "blockReadsOutsideWorkingDirectories": true,
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(./secrets/**)",
      "Read(~/.aws/**)",
      "Read(~/.ssh/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": ["Bash(git push *)"]
  },
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    },
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["git.example.internal", "registry.npmjs.org"]
    }
  },
  "env": { "CLAUDE_CODE_SUBPROCESS_ENV_SCRUB": "1" },
  "cleanupPeriodDays": 14
}

defaultMode: "default" startet Sitzungen im Manual-Modus statt im Auto-Modus. Entwickler können weiterhin auf Auto wechseln. Verbietet Ihre Richtlinie den Klassifizierer ganz, ergänzen Sie "disableAutoMode": "disable" unter permissions. cleanupPeriodDays: 14 ist unsere Wahl. Standardmäßig liegen lokale Transkripte 30 Tage im Klartext unter ~/.claude/projects/. blockReadsOutsideWorkingDirectories setzt v2.1.257 oder neuer voraus.

Rollout in dieser Reihenfolge:

1. Datei ablegen unter /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux und WSL) oder C:\Program Files\ClaudeCode\managed-settings.json (Windows).
2. Auf einem Testrechner /status ausführen. Die Zeile Setting sources muss Enterprise managed settings (file) zeigen.
3. Einen normalen Build- und Testzyklus in Claude Code fahren und die benötigten Hosts in allowedDomains eintragen. docker und manche Go-basierten CLIs brauchen meist excludedCommands.
4. Erst ein Pilotteam, dann die ganze Flotte. MDM-Profile werden alle 30 Minuten neu gelesen, Dateien bei jeder Änderung.

Zwei Punkte für Nutzer von Bedrock und Google Cloud. Erstens erreichen Server-managed Settings aus der claude.ai-Konsole keine Sitzungen, die eine CLAUDE_CODE_USE_*-Provider-Variable exportieren. Nutzen Sie MDM, die Datei oder ein selbst betriebenes Claude Apps Gateway. Zweitens sind laut Seite zur Datennutzung Metriken, Fehlerberichte und /feedback-Uploads auf Bedrock und Google Cloud standardmäßig aus. Sitzungsumfragen und der WebFetch-Domain-Check laufen weiter. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC und skipWebFetchPreflight schalten sie ab. Verteilmechanik und OpenTelemetry verdienen einen eigenen Rollout-Plan. Das EU-Routing selbst beschreibt unser Leitfaden Claude Code mit Bedrock in der EU einrichten.

Selbst betreiben oder auslagern?

Wer Claude Code Sicherheit selbst betreibt, pflegt eine Policy-Datei, die sich mit dem Produkt ändert. Allein für September 2026 listet das Changelog 27 Releases, mehrere davon mit geändertem Verhalten bei Berechtigungen oder Sandbox. Jemand muss sie lesen, die Vorlage testen und Updates per MDM ausrollen. Auslagern lohnt sich, wenn bei Ihnen niemand Endpoint-Policies verantwortet.

Die wiederkehrenden Aufgaben aus unserer Sicht:

Aufgabe	Häufigkeit	Typische Rolle
Release Notes lesen, Änderungen an Berechtigungen und Sandbox markieren	Wöchentlich	Platform- oder Security-Engineer
Vorlage auf macOS, Linux, WSL2 neu testen	Je relevantem Release	Platform-Engineer
Anträge für Domain-Allowlist und excludedCommands prüfen	Wöchentlich	Security-Engineer
Prüfen, ob die Policy greift (/status, claude doctor)	Monatliche Stichprobe	IT oder MDM-Team
Vorfälle: geleakter Schlüssel, auffällige Agenten-Aktion	Bei Bedarf	Security-Team, Datenschutzbeauftragter
CI-Pipelines mit claude -p reviewen	Je neuer Pipeline	DevOps

Unsere Schätzung, keine belegte Zahl: Bei 50 bis 200 Entwicklern sind das zwei bis vier Stunden pro Woche eines sicherheitsaffinen Platform-Engineers, plus Zeit für Vorfälle. Vorfälle haben eine harte Frist. Gelangen durch einen Agenten personenbezogene Daten nach außen, verlangt Art. 33 DSGVO die Meldung an die Aufsichtsbehörde möglichst binnen 72 Stunden.

Behalten Sie das Thema intern, wenn Sie bereits MDM betreiben, ein Endpoint-Security-Team haben und Policies als Code im Repository pflegen. Dieses Team ist schneller als jeder Externe. An einen Managed-Service-Provider auslagern sollten Sie, wenn Entwicklerrechner nicht im MDM sind, niemand die Release Notes sichtet oder Claude Code in vielen unbeaufsichtigten Pipelines läuft.

Wenn Sie auslagern, gehört das in den Vertrag:

• SLA: eine schriftliche Frist für die Bewertung jedes Claude-Code-Releases und für Policy-Korrekturen nach sicherheitsrelevanten Änderungen.
• AVV nach Art. 28 DSGVO: Der Dienstleister sieht bei Vorfällen Transkripte, Logs und eventuell Code. Das ist Auftragsverarbeitung.
• Liste der Unterauftragsverarbeiter: wer sonst Ihre Logs oder Telemetrie sieht, und wo.
• Zugriffsmodell: Änderungen laufen über Ihr MDM mit Ihrer Freigabe, kein dauerhafter Admin-Zugriff auf Entwicklerrechner.
• Exit: Die Policy liegt als reines JSON mit Änderungshistorie in Ihrem Repository, damit Sie sie ohne Neuaufbau zurückholen.

Was die Lizenzen pro Platz kosten, steht in unserem Überblick Claude Code Kosten für Teams.

FAQ

Ist Claude Code für Firmencode sicher genug?

Mit erzwungener Policy, ja. Ohne Anpassung starten Sitzungen inzwischen im Auto-Modus, und Sandbox-Befehle dürfen die ganze Festplatte lesen. Mit Managed Settings, die die Sandbox aktivieren, .env und Zugangsdaten sperren und den Bypass-Modus abschalten, sind die Hauptrisiken abgedeckt. Das Review bleibt Ihre Aufgabe.

Stoppt eine Deny-Regel für .env jeden Lesezugriff?

Nein. Read(.env) sperrt die Datei-Tools von Claude und erkannte Befehle wie cat, aber nicht grep -r oder beliebige Unterprozesse. Tragen Sie dieselben Pfade unter sandbox.filesystem.denyRead oder sandbox.credentials ein und aktivieren Sie die Sandbox, damit das Betriebssystem die Sperre durchsetzt.

Was kostet die Härtung von Claude Code?

Die Einstellungen kosten nichts. Kosten entstehen durch Personal und Tokens. Im Auto-Modus auf Bedrock, Google Cloud oder Foundry zählt jede Klassifizierer-Prüfung zum Token-Verbrauch. Für die Policy-Pflege schätzen wir zwei bis vier Stunden pro Woche bei 50 bis 200 Entwicklern. Die Zahl stammt von uns, nicht von Anthropic.

Sandbox oder Dev Container: Was brauchen wir?

Die Sandbox gehört auf Entwickler-Laptops. Sie begrenzt Shell-Befehle, ohne die Arbeitsweise zu ändern. Den Dev Container nutzen Sie, wenn Claude unbeaufsichtigt oder mit --dangerously-skip-permissions läuft. Der Container ist die stärkere Grenze, aber alles, was hineingemountet ist, kann trotzdem abfließen.

Sendet Claude Code mit Bedrock Telemetrie an Anthropic?

Standardmäßig keine Metriken, Fehlerberichte oder Feedback-Uploads. Sitzungsumfragen und der WebFetch-Domain-Check laufen weiter, für den Check wird nur der Hostname übertragen. Mit CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC und skipWebFetchPreflight: true schalten Sie beides ab.

Können Entwickler Managed Settings überschreiben?

Bei Berechtigungsregeln und booleschen Sandbox-Schaltern nicht. Managed Settings haben den höchsten Rang, auch gegenüber Kommandozeilen-Flags. Array-Schlüssel wie excludedCommands werden aus allen Ebenen zusammengeführt, Entwickler können sie also erweitern. Mit allowManagedDomainsOnly und allowManagedReadPathsOnly sperren Sie Netzwerk- und Leselisten.

Quellen

1. Claude Code Doku: Security (1. Oktober 2026)
2. Claude Code Doku: Configure permissions (1. Oktober 2026)
3. Claude Code Doku: Permission modes (1. Oktober 2026)
4. Claude Code Doku: Sandboxing (1. Oktober 2026)
5. Claude Code Doku: Settings reference (1. Oktober 2026)
6. Claude Code Doku: Environment variables (1. Oktober 2026)
7. Claude Code Doku: Hooks reference (1. Oktober 2026)
8. Claude Code Doku: Deploy managed settings (1. Oktober 2026)
9. Claude Code Doku: Server-managed settings (1. Oktober 2026)
10. Claude Code Doku: Data usage (1. Oktober 2026)
11. Claude Code Doku: Development containers (1. Oktober 2026)
12. Claude Code Changelog (1. Oktober 2026)
13. DSGVO (Verordnung (EU) 2016/679), EUR-Lex (1. Oktober 2026)