Claude Code Sicherheitsleitfaden: Berechtigungen, MCP, Sandboxing

Klassische Chatbots laufen hinter einer API – schlimmstenfalls halluzinieren sie. Ein KI-Coding-Agent sitzt jedoch in deinem Repo, in deinem Terminal und (oft) mit deinen Cloud-Zugangsdaten – also viel näher an privilegierten Entwicklerumgebungen als alles, was wir bisher Chatbot genannt haben.

Die Frage ist: Wie setzt du Claude Code sicher ein, ohne langsamer zu werden? Mit den richtigen Berechtigungen, MCP-Kontrollen und Sandboxing – feinjustiert – kommst du ans Ziel.

In diesem Artikel zeige ich dir, wie das Sicherheitsmodell von Claude Code tatsächlich funktioniert, worauf du achten musst und welche Praktiken es nützlich halten, ohne ihm mehr Zugriff zu geben, als beabsichtigt.

Wenn du ganz neu bei Claude und Claude Code bist, melde dich für unseren kostenlosen Claude Code 101 Kurs an und lerne die Grundlagen an einem Nachmittag.

Das Sicherheitsmodell von Claude Code verstehen

Bevor du eine einzige Regel anpasst, brauchst du ein mentales Modell davon, was Claude Code tatsächlich steuert.

Es gibt fünf Bausteine: ein Berechtigungssystem, das entscheidet, was erlaubt ist; Tool-Zugriffskontrollen, die einzelne Fähigkeiten begrenzen; MCP-Berechtigungen für externe Integrationen; Sandboxing für OS-Isolierung; und Prüfbarkeit zur nachträglichen Auswertung. Jeder Teil löst ein anderes Problem – zusammen ergeben sie die Schutzschichten.

Berechtigungssystem

Das Berechtigungssystem ist die statische Ebene.

Du legst in settings.json mit drei Listen fest, was Claude darf: allow, ask und deny. Regeln werden in der Reihenfolge deny, dann ask, dann allow ausgewertet – und der erste Treffer gewinnt. Eine deny-Regel blockiert den Aufruf, selbst wenn eine weiter gefasste allow-Regel ihn erlauben würde.

Wenn keine Regel greift, fällt Claude auf das defaultMode der Sitzung zurück (mehr zu den Modi im nächsten Abschnitt).

Tool-Zugriffskontrollen

Berechtigungen hängen an Tools – nicht am Agenten als Ganzem.

Claude Code bringt eigene eingebaute Tools mit, zum Beispiel Bash für Shell-Befehle, Read, Edit und Write für Dateisystemaktionen, WebFetch für HTTPS-Requests, WebSearch für Suchen und einige weitere. Jede Regel nennt ein Tool und optional einen Spezifizierer in Klammern, etwa Bash(git commit:*) oder Read(./.env).

So funktioniert Least Privilege in der Praxis. Du kannst Bash(npm run:*) für Tests erlauben, ohne Claude vollen Shell-Zugriff zu geben.

MCP-Berechtigungen

MCP-Server erweitern Claude Code um Tools, für die es ursprünglich nicht gedacht war.

Jeder Server bringt eigene Tools mit (ein GitHub-Server Pull-Request-Tools, ein Datenbankserver Abfrage-Tools usw.). Das Berechtigungssystem deckt sie ebenfalls ab, jedoch mit anderer Syntax – Regeln nutzen das Format mcp__servername__toolname statt eines Klammer-Spezifizierers.

Merke dir: Mit MCP verdoppelt sich die Fragestellung ungefähr. Du entscheidest nicht nur, was Claude in deiner Shell darf, sondern auch, was es in jedem angeschlossenen externen System tun kann.

Sandboxing

Sandboxing ist die Betriebssystem-Schutzschicht unter dem Bash-Tool.

Berechtigungsregeln sagen Claude, was es tun soll. Sandboxing erzwingt, was es tatsächlich darf – durch Beschränkung von Dateisystemzugriff und ausgehenden Netzwerkaufrufen auf OS-Ebene. Auf macOS funktioniert es out of the box über Seatbelt. Unter Linux und WSL2 musst du zuvor bubblewrap und socat installieren.

Beide Schichten ähneln sich, decken aber unterschiedliche Szenarien ab. Berechtigungen hindern Claude am Versuch, und Sandboxing verhindert, dass ein Versuch gelingt – etwa wenn eine Prompt-Injection Claude dennoch dazu bringt.

Prüfbarkeit

Der letzte Baustein ist die Nachvollziehbarkeit.

Der Befehl /permissions listet alle aktiven Regeln und deren Ursprungsdateien auf – so beantwortest du die Frage „Warum hat Claude das ausgeführt?“. Hooks (PreToolUse, PostToolUse und weitere) erlauben dir, jeden Tool-Aufruf in dein eigenes System zu loggen. Für Teams senden OpenTelemetry-Exporte Nutzungs- und Tool-Call-Daten in den bestehenden Observability-Stack.

Claude Code: Berechtigungen und Zugriffskontrolle

Der Großteil der Sicherheit kommt aus den Berechtigungseinstellungen – hier wirst du am meisten feinjustieren.

Dateizugriff

Claude kann standardmäßig Dateien im Verzeichnis lesen und bearbeiten, aus dem du es startest.

Lesen wird über das Tool Read gesteuert, Bearbeiten über Edit und Write. Jedes akzeptiert ein Pfadmuster in Klammern – gitignore-Stil. Zum Beispiel passt Read(**/.env) auf jede .env-Datei in beliebiger Tiefe und Edit(src/**) auf alles unter src/.

Ein deny auf Read deckt die Dateitools von Claude Code (Read, Grep, Glob, LS) ab – ist aber nur „best effort“. Ein über Bash gestartetes Python- oder Node-Skript kann die Datei trotzdem öffnen, weil das Lesen über die Shell statt über Claudes Read-Tool passiert. Wenn ein Geheimnis wichtig ist, kombiniere das Read-deny mit einem Bash-deny auf cat, head und tail für diese Pfade.

Um den Zugriff über das Arbeitsverzeichnis hinaus zu erweitern, nutze additionalDirectories in settings.json. So gibst du Claude Zugriff auf eine gemeinsame Bibliothek außerhalb deines Repos oder auf eine Konfigurationsdatei im Home-Verzeichnis – ohne die Grenze des Arbeitsverzeichnisses komplett aufzuheben.

Befehlsausführung

Das Bash-Tool musst du am sorgfältigsten eingrenzen.

Eine nackte Bash-Regel erlaubt jeden Befehl. Eine eingeengte Regel wie Bash(npm run:*) erlaubt nur passende Aufrufe. Das Doppelpunkt-Stern-Muster ist hier nötig, und Claude Code versteht Shell-Operatoren – eine Regel wie Bash(safe-cmd:*) matcht also nicht auf safe-cmd && rm -rf /.

Einige Befehle laufen in jedem Modus ohne Rückfrage, weil sie standardmäßig als read-only gelten. Auf der Liste stehen ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd und read-only-Formen von git. Du kannst diese Liste nicht verkleinern, aber du kannst für jeden davon eine ask- oder deny-Regel setzen, um den Standard zu überschreiben.

Für alles, was nicht vorab freigegeben ist, fragt Claude im default-Modus nach. Der Prompt zeigt den exakten Befehl und lässt dich einmalig freigeben, zukünftige passende Aufrufe generell erlauben oder ablehnen.

Berechtigungsmodi

Regeln sind statisch, aber Modi steuern, wie nicht übereinstimmende Aufrufe behandelt werden.

Es gibt fünf:

• default: Fragt bei der ersten Nutzung jedes Tools.

• acceptEdits: Bestätigt Datei-Edits im Arbeitsverzeichnis automatisch, steuert aber weiterhin Shell-Befehle. Nützlich, wenn du den Edits vertraust, der Shell aber nicht.

• plan: Claude darf lesen und analysieren, aber keine Dateien bearbeiten oder Befehle ausführen. Der richtige Modus für Code-Reviews oder Planungssessions.

• dontAsk: Lehnt alles ab, was nicht explizit in allow steht.

• bypassPermissions: Überspringt jede Rückfrage. Nur in vollständig isolierten Umgebungen wie Container oder VM sicher.

Du kannst die drei Hauptmodi mit Shift+Tab in der Sitzung durchschalten oder in settings.json einen Standard setzen:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Für Teams liefern Managed Settings eine Ebene, die der User nicht überschreiben kann. Die Datei hat dasselbe JSON-Format und liegt in einem Systempfad:

• /Library/Application Support/ClaudeCode/managed-settings.json auf macOS

• /etc/claude-code/managed-settings.json unter Linux

• C:\ProgramData\ClaudeCode\managed-settings.json unter Windows

Deny-Regeln in Managed Settings gelten projektübergreifend auf der Maschine – so erzwingst du unternehmensweit Regeln wie „niemand liest .env-Dateien“ oder „niemand nutzt bypassPermissions“.

Das zugrunde liegende Prinzip ist Least Privilege – genau wie bei jedem Service-Account. 

Starte mit dem kleinstmöglichen Satz an Berechtigungen, der die Arbeit ermöglicht, und erweitere erst, wenn du an Grenzen stößt. Auch Anthropics Leitlinien gehen in diese Richtung: Prüfe Claudes Änderungen, auditiere deine Regeln mit /permissions und checke projektspezifische Einstellungen in die Versionskontrolle ein, damit sich das Team über Claudes Arbeitsbereich einig ist.

Claude Code Sandboxing

Je autonomer Claude laufen darf, desto sinnvoller ist Sandboxing.

Das Bash-Tool hat die größte Angriffsfläche, da Shell-Befehle jede Datei lesen können, die du lesen kannst, und alles ändern, wofür Schreibrechte bestehen. Sandboxing erzwingt OS-Grenzen für jeden Bash-Befehl und dessen Kindprozesse, sodass Claude innerhalb der Grenze freier laufen kann – ohne dass du jeden Aufruf abnicken musst. Anthropic hat das gezielt für sicherere autonome Läufe eingebaut.

Wichtig: Die Sandbox deckt nur Bash und Kindprozesse ab. Read, Edit und Write werden nicht eingeschränkt – sie laufen weiter durch das Berechtigungssystem.

Natives Sandboxing

Die native Sandbox ist in Claude Code integriert und wird mit /sandbox aktiviert.

Auf macOS nutzt sie Seatbelt, du musst nichts installieren. Unter Linux und WSL2 installierst du bubblewrap für Dateisystemisolierung und socat für den Netzwerk-Proxy. Native Windows-Unterstützung gibt es nicht – nutze Claude Code in einer WSL2-Distribution.

Die Dateisystemgrenze ist leicht verständlich: Lesen funktioniert überall außer auf verbotenen Pfaden, Schreiben nur im Arbeitsverzeichnis und den zusätzlich erlaubten Pfaden. Versuchst du aus der Sandbox ~/.bashrc zu schreiben, erhältst du „Operation not permitted“, bevor Claude den Fehler überhaupt sieht.

Die Netzwerkgrenze funktioniert etwas anders: Ausgehender Traffic läuft über einen Proxy-Server außerhalb der Sandbox, der jede Anfrage gegen deine allowedDomains prüft. Neue Domains lösen eine Berechtigungsabfrage aus – so siehst du genau, wohin Claude möchte.

Eine funktionierende Konfiguration sieht so aus:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

In Anthropics interner Nutzung reduziert Sandboxing Berechtigungsabfragen um 84%.

Development-Container

Dev-Container sind der nächste Isolationsschritt.

Anthropic bietet einen Referenz-Devcontainer für Claude Code, der eine Ubuntu-Umgebung aufsetzt, dein Repo mountet und dem Agenten eine Shell gibt. Vorteil gegenüber nativem Sandboxing ist die Reproduzierbarkeit: Alle im Team arbeiten in derselben Umgebung – mit denselben Tools und Einstellungen.

Der Nachteil ist der Overhead. 

Du fügst Container-Build, Datei-Mounts und (manchmal) einen langsameren Feedback-Loop hinzu. Für Einzelentwickler reicht meist die native Sandbox. Für Teams oder CI lohnt sich das Setup.

Docker-basierte Isolation

Für langlaufende, autonome Agentensitzungen kann Docker die Sandbox-Grenze weiter verstärken.

Das Setup sieht typischerweise so aus:

• Minimales Basis-Image: Entferne Paketmanager und Netzwerktopols, die die Aufgabe nicht braucht.
• Nicht-Root-User: Claude läuft niemals als Root, kann also keine Systemdateien ändern oder globale Pakete installieren.
• Read-only Root-Dateisystem: Hänge das Container-Root schreibgeschützt ein, mit nur bestimmten beschreibbaren Output-Verzeichnissen.
• Egress-Proxy: Route ausgehendes Netzwerk über einen Proxy, der die Paket-Registry (npm, PyPI) erlaubt und alles andere blockiert – so funktioniert npm install, ein beliebiges curl jedoch nicht.
• Ressourcenlimits: Begrenze CPU, Speicher und I/O, damit kein Prozess den Host lahmlegt.

Docker Sandboxes geben jeder Sandbox ihre eigene MicroVM mit privatem Docker-Daemon. Der Host-Daemon sieht die Sandboxes nicht einmal in docker ps. Die Grenze ähnelt eher einer VM als einem Container – damit sind die meisten Container-Escape-Pfade, die Entwickler beschäftigen, geschlossen.

Sandboxing-Strategien im Enterprise

Für Organisationen geht es darum, Sandbox-Techniken zu schichten – nicht ob man sie nutzt.

So gehen die meisten vor:

• Berechtigungsregeln liegen in managed-settings.json und können von Entwickler:innen nicht überschrieben werden.

• Natives Sandboxing läuft unter der Berechtigungsebene.

• Dev-Container oder Docker darunter.

• Für höchste Vertrauensstufen (Produktionszugriff, Umgang mit Secrets) bildet eine dedizierte VM ohne Host-Dateisystem-Mount die letzte Schicht.

Claude Code im Web ist die gemanagte Variante derselben Idee. Jede Sitzung läuft in einer von Anthropic verwalteten VM, sensible Zugangsdaten wie Git-Tokens liegen außerhalb der Sandbox in einem Proxy, und die Grenze wird durch die Infrastruktur erzwungen.

MCP-Sicherheit in Claude Code

MCP ist der Teil von Claude Code, der am schnellsten wächst.

Jeder verbundene MCP-Server vervielfacht grob, was Claude kann – und vergrößert die Angriffsfläche, die eine Prompt-Injection oder eine kompromittierte Abhängigkeit erreichen kann. 

Zum Beispiel:

• Ein GitHub-MCP-Server gibt Claude Zugriff auf Pull Requests.
• Ein Datenbank-MCP-Server gibt ihm Schema und Abfragen.
• Ein Slack-Server gibt ihm deine Channels.

Das ist kein Problem an sich – bedeutet aber, dass MCP eigene Governance braucht. Inhalte, die ein MCP-Tool holt (Webseite oder API-Response), können injizierte Anweisungen enthalten, die Claude ausführt, als hättest du sie getippt. Außerdem fügt jeder Server ein Credential und einen separaten Authentifizierungspfad hinzu, der verwaltet werden muss.

Tool-Berechtigungen

MCP-Tools nutzen eine andere Namenskonvention als eingebaute Tools.

Das Regel-Format ist mcp__servername__toolname – ohne Klammer-Spezifizierer. Beispiel: mcp__github__create_pull_request erlaubt genau dieses Tool; ein deny auf mcp__github__delete_repo blockiert das gefährliche. Allow-, Ask- und Deny-Listen funktionieren wie bei Bash oder Read.

Die gleiche Priorität gilt: erst deny, dann ask, dann allow. Ein deny in Managed Settings auf mcp__github__delete_* gilt projektübergreifend auf der Maschine.

Ressourcenberechtigungen

MCP-Server können neben Tools auch Ressourcen bereitstellen.

Eine Ressource ist ein Datenelement, das der Server zum Lesen anbietet (z. B. eine Datei in einem Projektmanagement-Server oder eine Zeile in einem Datenbankserver). Der Ressourcenzugriff läuft durch denselben Vertrauenscheck wie Tool-Aufrufe, und die erste Verbindung zu einem MCP-Server durchläuft einen Trust-Verify-Schritt, bevor Tools oder Ressourcen erreichbar sind.

Behandle Ressourcen standardmäßig wie ein weiteres Tool. Wenn du das Credential nicht vergeben würdest, gewähre auch keinen Ressourcenzugriff.

Genehmigte MCP-Server

Das Anthropic Directory listet Connectoren, die Anthropic nach festgelegten Kriterien geprüft hat.

Für Organisationen ist eine interne Allowlist ein gutes Muster. Zwei Einstellungen geben dir die Kontrolle:

• allowedMcpServers: Ein Glob-Muster von Servern, die Entwickler:innen zu Projekten hinzufügen dürfen (z. B. company-* nur für intern gepflegte Server).

• deniedMcpServers: Ein Muster von Servern, die nicht hinzugefügt werden können – selbst wenn jemand es versucht.

Für obligatorische Server, die in jeder Sitzung vorhanden sein sollen, lieferst du sie über eine managed-mcp.json im Managed-Settings-Pfad aus. Entwickler:innen können die Einträge nicht entfernen oder ändern.

Eine Einstellung, die du in geteilten Repos vermeiden solltest, ist enableAllProjectMcpServers, die jeden in .mcp.json definierten MCP-Server automatisch freigibt. Für Solo-Arbeit bequem, für eingecheckte Repos riskant – ein bösartiger PR kann einen neuen Server in .mcp.json hinzufügen, der dann ohne Rückfrage läuft.

Least-Privilege-Toolzugriff

Gleiches Prinzip wie bei Bash-Berechtigungen – nur auf MCP angewendet.

Die Ausgangsfrage lautet: Welches Credential hat jeder Server? Ein Datenbank-MCP-Server sollte sich an eine Read-Replica mit Nur-Lese-Rechten hängen, nicht an den Primary mit Schreibrechten. Ein API-MCP-Server sollte ein Token mit minimal nötigem Scope nutzen, nicht ein persönliches Token mit vollem Orgreichweite. Und so weiter.

Subagenten sind ein weiterer Weg, MCP-Zugriff zu begrenzen. Eine Subagent-Definition in .claude/agents/ kann genau angeben, welche Tools verfügbar sind (Syntax mcp:<server>:<tool>) – ein „deploy-agent“ bekommt den Infrastrukturerserver, ein „review-agent“ nur Read, Grep und Glob. Der Agent kann keine Tools aufrufen, die er nicht erhalten hat.

MCP-Governance

Für Teams oder Organisationen, die Claude Code im großen Maßstab betreiben, braucht MCP die gleiche Governance wie jede andere Produktionsintegration.

Das bedeutet: Ein Register genehmigter Server mit benannten Ownern, durchgängige Audit-Trails der Tool-Aufrufe (welche MCP-Tools, von wem, mit welchen Parametern) und eine regelmäßige Überprüfung der Genehmigungsliste. OpenTelemetry-Exporte in Claude Code liefern Auditing-Daten in einem Format, das in deinen bestehenden Observability-Stack passt.

Für größere Organisationen ist ein zentralisiertes MCP-Gateway die sauberste Lösung. 

Entwickler:innen verbinden sich mit dem Gateway statt einzelne Server zu registrieren. Das Gateway übernimmt Authentifizierung, erzwingt rollenbasierten Zugriff auf Tool-Ebene und erzeugt einen einheitlichen Audit-Trail. Es verhindert auch Credential-Sprawl, weil ein Credentialsatz am Gateway alle verteilten API-Keys ersetzt.

Secrets Management und sensible Daten

Claude Code kann alles lesen, was du lesen kannst – damit sind Secrets erreichbar.

Standardmäßig kann Claude Code jede Datei lesen, auf die dein Benutzerkonto Zugriff hat. Dazu zählen .env-Dateien im Projekt, AWS-Credentials in ~/.aws/, SSH-Private-Keys in ~/.ssh/, GitHub-Tokens in deiner Shell-RC-Datei und Umgebungsvariablen in allen Subprozessen, die Claude startet. Das ist beabsichtigt und normal.

Halte Secrets aus dem Workspace heraus

Der erste Schritt: Sorge dafür, dass Secrets nicht im Verzeichnis liegen, das Claude liest.

.env-Dateien sind die häufigsten. Sie liegen im Projekt-Root, werden von jedem Dev-Tool geladen und enthalten genau die Werte, die du nicht im Claude-Kontext haben willst (Datenbank-URLs, API-Keys). 

Zwei Muster, die du nutzen kannst:

• Verschiebe Secrets in ein Verzeichnis außerhalb des Arbeitsbaums, z. B. ~/.config/myapp/secrets.env, und lade sie über einen Environment-Manager oder ein direnv-Setup, das auf die externe Datei zeigt.

• Für Container-Arbeit: Lege einen .secrets/-Ordner außerhalb des Bind-Mounts an, damit die Datei im Container unsichtbar ist.

• Füge Read(**/.env) und Read(**/.env.*) zu permissions.deny hinzu und kombiniere das mit Bash(cat:*/.env)-Denies, damit Shell-Skripte nicht lesen, was das Read-Tool nicht lesen darf.

Nutze einen Secret-Manager

Für alles jenseits von Demo-Projekten gehören Secrets in einen Secret-Manager.

Das Muster ist unabhängig vom Anbieter gleich (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical): Secrets liegen im Manager. Deine Shell bzw. Runtime holt sie bedarfsgerecht und gibt sie nur an den Prozess weiter, der sie braucht. Claude sieht den eigentlichen Wert nie.

Für Claude Code konkret bedeutet das, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB zu setzen, um Anthropic- und Cloud-Provider-Credentials aus Subprozessen zu entfernen, oder sandbox.credentials zu nutzen, um bestimmte Variablen für Sandbox-Befehle zu unsetten. Ersteres verhindert, dass Claude deinen ANTHROPIC_API_KEY in ein Build-Skript durchreicht; Zweiteres deckt den allgemeineren Fall sensibler Umgebungsvariablen ab, die in Shell-Befehle gelangen könnten.

Repository-Zugriff einschränken

Die dritte Option liegt auf Repo-Ebene.

Wenn ein Entwickler keine Schreibrechte für produktionsspezifische Konfiguration braucht, dann braucht seine Claude-Code-Sitzung sie auch nicht. Klingt offensichtlich, doch meist haben Entwickler breitere Rechte als nötig – und Claude erbt sie alle.

Zwei Schritte helfen:

• Trenne Produktionskonfiguration in ein separates Repo mit strengeren Rechten, sodass die Dev-Umgebung, in der Claude arbeitet, Produktions-Secrets gar nicht enthält.

• Nutze Scoped Tokens für jeden Dienst, mit dem Claude interagiert. Ein GitHub-Token für Code-Review braucht z. B. kein repo:delete.

Claude Code Sicherheit für Teams

Einzelentwickler können settings.json nach Belieben ändern. Ein Team nicht – die Gesamtsicherheit ist nur so stark wie die schwächste Config auf der schwächsten Maschine. Für Teams und Unternehmen hat Claude Code daher eine eigene Control-Ebene, die Admins ausrollen und die Nutzer nicht überschreiben können.

Managed Settings

Managed Settings sind die Grundlage.

Die Datei liegt in einem Systempfad, der Admin-Rechte zum Schreiben erfordert:

• /Library/Application Support/ClaudeCode/managed-settings.json auf macOS

• /etc/claude-code/managed-settings.json unter Linux

• C:\ProgramData\ClaudeCode\managed-settings.json unter Windows

Einstellungen in dieser Datei haben Vorrang vor Nutzer- und Projekteinstellungen. Ein deny hier gilt für alle Projekte der Maschine – und Entwickler:innen können es nicht mit ihrer eigenen settings.json entfernen. Die meisten Organisationen verteilen die Datei per MDM (Mobile Device Management) oder dem gleichen Kanal wie andere Dev-Tools.

Nützliche Einstellungen auf der Managed-Ebene:

• permissions.deny-Regeln für sensible Pfade und gefährliche Befehle

• defaultMode auf default oder plan (nie bypassPermissions)

• allowManagedPermissionRulesOnly: true, um das Berechtigungsset zu sperren

• enableAllProjectMcpServers: false, um explizite MCP-Genehmigung zu verlangen

• OpenTelemetry-Exporter-Konfiguration fürs Logging

Geteilte Berechtigungsrichtlinien

Ein Team, das sich einig ist, was Claude darf, sollte diese Einigung versionieren.

Projekteinstellungen liegen in .claude/settings.json im Repo-Root. Alles, was hier eingecheckt ist, gilt für alle, die Claude in diesem Repo nutzen. Die Datei ist der richtige Ort für projektspezifische Allows und Denys.

Beachte die Trennung zwischen Managed- und Projektebene:

• Managed Settings enthalten Unternehmenspolicy (niemand nutzt bypassPermissions, niemand liest .env).

• Projekteinstellungen enthalten Workflow-Konventionen (Tests laufen mit npm test; Deploy-Skript ist tabu).

Team-Governance

Für den Team-Rollout braucht die Policy-Ebene eine Verantwortung.

Meist kümmert sich ein kleines Team – typischerweise Security und Platform Engineering – um Managed Settings, MCP-Allowlist, Hook-Skripte und die OpenTelemetry-Pipeline. Diese Gruppe prüft Ausnahmen und passt die Policy an neue Use Cases an.

Diese Punkte solltest du schriftlich festhalten:

• Welche Repos in Scope sind und welche nicht – mit risikobasierten Modi (ein Repo mit regulierten Daten läuft wahrscheinlich in plan, während eine Marketing-Site in acceptEdits laufen kann).
• Wer Ausnahmen genehmigen darf und wie diese dokumentiert werden.
• Eine Review-Kadenz (quartalsweise ist üblich), bei der das Team Berechtigungsregeln, MCP-Server und Vorfälle prüft.

Audit-Logging

Claude Code erzeugt OpenTelemetry-Events für jede Tool-Entscheidung, MCP-Server-Verbindung, Modusänderung und API-Anfrage. Es fließen erst Daten, wenn ein Admin den OTLP-Endpunkt in den Managed Settings konfiguriert.

Ein minimales Managed-Settings-Block für Telemetrie sieht so aus:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Standardmäßig sind Prompt-Inhalte und Tool-Parameter vom Export ausgeschlossen – die Events sind Metadaten, nicht der volle Verlauf. Um Prompt-Text einzuschließen, setze OTEL_LOG_USER_PROMPTS=1. Um Tool-Argumente einzuschließen (für Audits meist gewünscht), setze OTEL_LOG_TOOL_DETAILS=1. Beide Entscheidungen haben Datenschutzimplikationen – viele Teams behandeln sie als bewusste Policy-Option und filtern/redigieren in der Telemetrie-Pipeline vor der Speicherung.

Nutzungsmonitoring

Der gleiche OpenTelemetry-Stream, der fürs Audit dient, treibt auch das Nutzungsmonitoring.

Claude Code exportiert Metriken zu Tokenverbrauch, Kosten pro Request, Sitzungsanzahl und Tool-Entscheidungsraten. Aggregiert zeigen sie, welche Teams den größten Nutzen ziehen, welche Workflows die meisten Ablehnungen erzeugen und welche Modelle Kosten treiben. Backends wie Datadog, Honeycomb, SigNoz, Elastic und Splunk verarbeiten das standardisierte OTLP-Format.

Ein Spike bei permission_decision-Events mit decision=deny kann heißen, dass Claude zu viel versucht – oder dass die Allow-Regeln zu eng sind.

Häufige Sicherheitsfehler mit Claude Code

Ein kleines Set an Fehlkonfigurationen taucht in den meisten Claude-Code-Vorfällen auf. Hier sind sie – und was du dagegen tust.

Zu breite Berechtigungen

Am schnellsten stumpfst du das Berechtigungssystem ab, indem du zu viel erlaubst.

Prompts pro Befehl kosten Zeit; die vermeintlich einfache Lösung ist ein breites Bash(*)-allow oder defaultMode: bypassPermissions. Beides hebelt den Großteil des Systems aus.

Lege allow-Regeln auf die Tools und Kommandos, die du wirklich nutzt (z. B. Bash(npm test:*) und Bash(git status)), und lass alles andere per Prompt laufen. Anfangs kommen mehr Rückfragen – nach wenigen Sessions hast du die genutzten Kommandos auf der Allowlist, und die Prompts versiegen weitgehend.

Unbeschränkter MCP-Zugriff

Der zweite Fehler: MCP-Server verbinden, ohne zu prüfen, welche Credentials sie nutzen oder worauf sie zugreifen können.

Oft passiert das, weil jemand enableAllProjectMcpServers aktiviert, ein paar Server aus dem öffentlichen MCP-Verzeichnis anschließt und sie nie wieder prüft. Wenn dann ein Server mit schwachem Credential etwas Leck schlägt, liegt die Freigabe so weit zurück, dass sich niemand erinnert.

Die Lösung entspricht der für Berechtigungen: Nutze eine explizite Allowlist via allowedMcpServers, ein internes managed-mcp.json für Server, die alle brauchen, und eine regelmäßige Review der Liste.

Kein Sandboxing

Ohne Sandboxing ist das Berechtigungssystem die einzige Barriere zwischen Claude und deinem Dateisystem.

Für kurze, interaktive Sessions okay, in denen du jeden Befehl bestätigst. Nicht okay für autonome Läufe, Sitzungen mit breiteren allow-Regeln oder Arbeit mit Code aus externen Quellen.

/sandbox schaltet es ein. Fehlen Abhängigkeiten, zeigt dir das Menü, welche du für deine Plattform installieren musst. Einmal aktiv, sinkt die Zahl der Prompts – und das OS fängt Fälle ab, die deine allow-Regeln nicht abdecken.

Änderungen blind akzeptieren

acceptEdits ist zugleich bequem und riskant.

Wenn Claude eine Funktion umschreibt und du zusiehst, ist Auto-Akzept okay. Wenn Claude eine Stunde lang über 30 Dateien iteriert, liest du die Diffs irgendwann nicht mehr – und beginnst, dem Agenten zu vertrauen. Genau dort entstehen Probleme.

Zwei Gewohnheiten helfen:

• Committe immer, bevor du Claude autonom laufen lässt – der Rollback ist dann nur ein git reset entfernt.

• Prüfe den Diff vor jedem Commit von Claude – nicht nur den Gesamtdiff am Ende der Session.

Audit-Trails ignorieren

Ein Team, das Claude Code ohne Telemetrie betreibt, kann die Frage „Welche Sitzung war das?“ nicht beantworten. Events sammeln sich lokal und bleiben dort. Der erste Audit-Fall ist der schlechteste Zeitpunkt, um festzustellen, dass nichts konfiguriert ist.

Das Mindestmaß: tool_decision-, permission_decision- und api_request-Events in den bestehenden Observability-Stack exportieren. Darauf aufbauend erstellst du Dashboards und Alerts.

Fazit

Das Worst-Case-Szenario für einen Chatbot ist eine falsche Antwort. Für einen Coding-Agenten ist es ein Shell-Befehl, der mit deinen Credentials gegen die Produktion läuft.

Darum zählen die drei Säulen:

• Berechtigungen entscheiden, was Claude ausführen darf
• MCP-Kontrollen entscheiden, welche externen Systeme es erreicht
• Sandboxing entscheidet, was passiert, wenn die ersten beiden nicht ausreichen

Jede Schicht deckt einen Ausfallmodus ab, den die anderen nicht abdecken. Zusammen definieren sie die reale Grenze, innerhalb derer Claude arbeitet.

Wenn du dich für Zertifizierungen in generativer KI interessierst, findest du hier Vergleiche, Top-Kurse, Vorbereitungstipps und FAQs zu den Best Generative AI Certifications in 2026.