Claude Code sicher konfigurieren: Rechte, Befehle und Dateizugriffe begrenzen

Stell dir vor, du beauftragst einen KI-Assistenten damit, einen kleinen Fehler in deiner Webanwendung zu beheben. Statt nur die betroffene Datei zu ändern, führt er zusätzliche Terminalbefehle aus, liest Konfigurationsdateien und verändert möglicherweise Abhängigkeiten.

Das muss nicht einmal böse Absicht sein. Ein KI-Agent kann einen Auftrag falsch interpretieren, eine riskante Abkürzung wählen oder Anweisungen aus einer manipulierten Projektdatei übernehmen.

Genau deshalb ist es wichtig, Claude Code sicher zu konfigurieren.

Claude Code ist nicht einfach ein Chatbot, der Programmcode vorschlägt. Es ist ein Coding-Agent, der mit entsprechenden Berechtigungen selbstständig Dateien lesen, Änderungen vornehmen, Shell-Befehle ausführen und Entwicklungswerkzeuge verwenden kann.

Das macht ihn leistungsfähig. Gleichzeitig entstehen Sicherheitsrisiken, wenn seine Handlungsmöglichkeiten nicht bewusst eingeschränkt werden. In diesem Praxisleitfaden erfährst du, wie du Berechtigungen kontrollierst, gefährliche Befehle einschränkst, sensible Dateien schützt und Claude Code in Entwicklungsprojekten mit möglichst geringen Rechten betreibst.

Welche Risiken entstehen durch einen Coding-Agenten?

Ein Coding-Agent arbeitet innerhalb einer technischen Umgebung. Je nach Konfiguration kann er auf lokale Dateien, Werkzeuge und externe Dienste zugreifen. Besonders kritisch sind vier Bereiche.

Terminalbefehle: Ein Agent könnte Dateien löschen, Berechtigungen verändern, Pakete installieren oder Dienste beeinflussen. Die Auswirkungen hängen von den Rechten des ausführenden Betriebssystembenutzers ab.

Dateizugriffe: Projektdateien können Zugangsdaten, API-Schlüssel, interne URLs oder andere vertrauliche Informationen enthalten.

Netzwerk und externe Werkzeuge: Über Shell-Tools, MCP-Server oder andere Integrationen können Daten an externe Systeme übertragen oder dort Aktionen ausgelöst werden.

Prompt Injection: Manipulierte README-Dateien, Kommentare oder externe Tool-Ergebnisse können versuchen, dem Agenten unerwünschte Anweisungen unterzuschieben.

Das Sicherheitsziel lautet deshalb nicht, Claude Code möglichst viele Funktionen wegzunehmen. Es geht darum, nur die Fähigkeiten freizugeben, die für eine konkrete Aufgabe tatsächlich benötigt werden. Dieses Prinzip heißt Least Privilege, also minimale Rechtevergabe. Wie dieses Prinzip für KI-Agenten ganz allgemein aussieht – unabhängig vom konkreten Werkzeug – erklärt Welche Rechte darf ein KI-Agent bekommen? Sicherheitsregeln für Agenten (Zum Artikel).

Claude Code Permissions verstehen

Claude Code verwendet ein Berechtigungssystem, mit dem Werkzeugaufrufe erlaubt, abgelehnt oder von einer Bestätigung abhängig gemacht werden können. Ein wesentlicher Bestandteil ist die Datei settings.json.

Die verschiedenen Einstellungsebenen werden nicht einfach als vollständig getrennte Konfigurationen behandelt. Claude Code führt Einstellungen nach definierten Vorrang- und Zusammenführungsregeln zusammen: Verwaltete Richtlinien stehen an oberster Stelle, gefolgt von projektlokalen, geteilten Projekt- und schließlich Benutzereinstellungen. Verwaltete Richtlinien können dabei Grenzen vorgeben, die ein Projekt nicht aufheben darf.

Beispiel: Berechtigungen mit settings.json steuern

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "Bash(npm install *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Edit(./.env)",
      "Edit(./secrets/**)"
    ]
  }
}

Die Konfiguration illustriert drei Entscheidungen: allow erlaubt passende Werkzeugaufrufe ohne zusätzliche Einzelbestätigung, ask fordert für passende Aktionen eine Bestätigung an, und deny lehnt passende Aktionen ab.

Wichtig ist die Unterscheidung zwischen Berechtigungsregel und tatsächlicher Sicherheitsgrenze. Eine deny-Regel für Read verhindert nicht automatisch jeden denkbaren Zugriff auf dieselbe Datei über andere Werkzeuge oder indirekte Befehle. Ebenso ist eine Erlaubnis für einen Shell-Befehl keine Garantie dafür, dass dessen Ausführung ungefährlich ist – ein Skript wie npm test kann selbst weitere Programme starten. Deshalb sollten solche Regeln immer mit Betriebssystemrechten und einer kontrollierten Ausführungsumgebung kombiniert werden.

Terminalbefehle gezielt begrenzen

Der Zugriff auf eine Shell gehört zu den mächtigsten Funktionen eines Coding-Agenten. Ein Terminal kann nicht nur Quellcode prüfen, sondern grundsätzlich alles ausführen, was der angemeldete Benutzer ausführen darf. Dazu zählen beispielsweise:

rm -rf ./projektordner
curl https://example.org/script.sh | bash
chmod -R 777 .

Diese Beispiele stehen für potenziell destruktive, unkontrollierte oder unsichere Aktionen. Sie sollten nicht als automatisierte Standardwerkzeuge eines KI-Agenten freigegeben werden.

Für ein typisches Node.js-Projekt könnten zunächst folgende Befehle genügen – eine kleine Positivliste statt pauschaler Freigabe:

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(git status)"
    ]
  }
}

Dadurch werden nur die aufgeführten Befehlsmuster ausdrücklich erlaubt. Andere Befehle werden abhängig vom aktiven Berechtigungsmodus und weiteren Regeln behandelt. Besondere Vorsicht gilt bei Platzhaltern: Eine weit gefasste Regel wie Bash(git *) kann sehr viel mehr Aktionen erfassen als das harmlose Anzeigen des Repository-Status. Auch Befehle, die zunächst lesend wirken, können durch Argumente, Shell-Verknüpfungen oder aufgerufene Skripte unerwartete Nebenwirkungen haben.

Empfehlung: Erlaube automatisiert möglichst nur klar definierte, überprüfte Entwicklungsbefehle. Installationen, Git-Pushes, Deployments und Änderungen an der Systemkonfiguration sollten zusätzliche Freigaben oder getrennte Ausführungswege benötigen.

Sensible Dateien vor Claude Code schützen

In nahezu jedem größeren Entwicklungsprojekt gibt es Dateien, die ein Coding-Agent nicht uneingeschränkt lesen sollte: .env und andere Umgebungsdateien mit Secrets, private SSH-Schlüssel, Cloud-Zugangsdaten und API-Tokens, Datenbank-Dumps mit personenbezogenen Daten sowie Produktionskonfigurationen und Zertifikatsschlüssel.

Eine mögliche Berechtigungsregel lautet:

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

Diese Regeln können direkte Lese- und Bearbeitungsaufrufe einschränken. Sie ersetzen jedoch keine Dateisystemisolation.

Ein häufiger Denkfehler lautet: „Die Datei steht in .gitignore, also kann Claude Code sie nicht lesen." Das stimmt nicht. .gitignore legt hauptsächlich fest, welche Dateien Git bei der Versionsverwaltung ignoriert. Es ist keine allgemeine Zugriffskontrolle für lokale Programme. Auch eine CLAUDE.md mit dem Satz „Lies keine Secrets" ist keine technische Dateisperre. Sie gibt dem Modell eine Arbeitsanweisung, aber keine harte Sicherheitsgrenze.

Für besonders sensible Projekte empfiehlt sich stattdessen eine getrennte Arbeitsumgebung, in der Geheimnisse aus dem eigentlichen Arbeitsbereich entfernt werden:

/workspace/
  webapp/
    src/
    tests/
    package.json
  .claude/
    settings.json

/secure/
  production.env
  private-key.pem
  database-backup.sql

Der Agent sollte nur den benötigten Arbeitsbereich erhalten. Der separate Bereich mit Secrets muss zusätzlich durch Betriebssystemrechte oder Container-Mounts unzugänglich sein. Eine Verzeichnisstruktur allein schützt noch nichts – entscheidend ist, dass der Prozess des Agents tatsächlich keine Berechtigung besitzt, auf /secure zuzugreifen. Wie du Zugangsdaten für KI-Agenten grundsätzlich organisierst – von .env-Dateien bis zu professionellen Secret-Managern wie Vault – zeigt Secrets und API-Keys bei KI-Agenten schützen: .env, Vault und Berechtigungen richtig einsetzen (Zum Artikel).

Sandbox statt Vollzugriff auf den Entwicklerrechner

Eine der wirksamsten Schutzmaßnahmen ist eine isolierte Ausführungsumgebung. Dabei arbeitet Claude Code nicht direkt mit sämtlichen Rechten des persönlichen Benutzerkontos, sondern innerhalb einer begrenzten Umgebung – etwa einem Container, einer separaten virtuellen Maschine oder geeigneten Sandbox-Funktionen.

Für die praktische Absicherung sind insbesondere diese Maßnahmen sinnvoll: ein dedizierter Benutzer ohne Administratorrechte, nur benötigte Projektverzeichnisse einbinden, nicht benötigte Verzeichnisse gar nicht bereitstellen, Netzwerkzugriffe auf erforderliche Ziele begrenzen, keine produktiven SSH-Schlüssel oder Cloud-Tokens einbinden sowie Änderungen vor der Übernahme in produktive Systeme überprüfen.

Bei Docker ist beispielsweise zu beachten, dass die Einbindung des Docker-Sockets häufig weitreichende Kontrolle über den Host ermöglicht. Ein vermeintlich isolierter Container kann dadurch einen wesentlichen Teil seiner Schutzwirkung verlieren. Auch eine Sandbox muss gegen Umgehungen geprüft werden – sie sollte nicht allein aufgrund ihres Namens als vollständig sicher betrachtet werden.

Die richtigen Berechtigungsmodi auswählen

Claude Code unterstützt unterschiedliche Betriebsmodi, die festlegen, wann ein Agent Aktionen selbstständig durchführen darf.

Die genaue Verfügbarkeit und Wirkung einzelner Modi kann sich zwischen Claude Code CLI, Desktop-App, IDE-Erweiterungen und Agent SDK unterscheiden.

Im Plan-Modus kann Claude Code zunächst untersuchen, wie eine Änderung umgesetzt werden sollte, beispielsweise mit einer Anweisung wie „Analysiere die Authentifizierung unserer Anwendung. Erstelle einen Plan zur Behebung möglicher Sicherheitsprobleme. Nimm noch keine Änderungen vor und führe keine Installation durch." Du erhältst zunächst einen Vorschlag, den du überprüfen kannst. Der Plan-Modus ist allerdings keine vollständige Datenschutz- oder Dateisystem-Sandbox – auch lesende Werkzeuge können vertrauliche Inhalte verarbeiten. Deshalb gelten die zuvor beschriebenen Zugriffsbeschränkungen weiterhin.

Claude Code bietet außerdem eine Möglichkeit, reguläre Berechtigungsabfragen vollständig zu überspringen:

claude --dangerously-skip-permissions

Dieser Aufruf ist gleichbedeutend mit claude --permission-mode bypassPermissions und sollte nicht auf einem normalen Entwicklerrechner mit persönlichen Zugangsdaten, produktiven Konfigurationen oder weitreichenden Benutzerrechten eingesetzt werden. Für automatisierte Workflows ist eine explizite Werkzeugfreigabe in Kombination mit einer isolierten Ausführungsumgebung wesentlich sinnvoller.

MCP-Server und externe Integrationen absichern

Claude Code kann über das Model Context Protocol (MCP) zusätzliche Werkzeuge verwenden. Damit entstehen neue Möglichkeiten: Ein Agent kann beispielsweise auf GitHub-Repositories, Datenbanken, Ticketsysteme oder interne APIs zugreifen. Gleichzeitig vergrößert sich die Angriffsfläche, denn ein MCP-Server kann Berechtigungen besitzen, die über den Zugriff auf lokale Projektdateien hinausgehen.

Deshalb sollten Administratoren vor jeder Integration prüfen, welche Aktionen ein MCP-Server tatsächlich ermöglicht. Besonders wichtig sind: Werkzeugfreigaben (nur benötigte MCP-Tools zulassen), Authentifizierung (individuelle, möglichst kurzlebige Zugangsdaten), Berechtigungsumfang (Schreib- und Löschrechte nur wenn erforderlich), Netzwerkzugriff (erreichbare Systeme begrenzen) sowie die Vertrauenswürdigkeit des Servers selbst. Wie eine solche Authentifizierung über OAuth und Tokens konkret abläuft, erklärt MCP-Authentifizierung erklärt: OAuth, Tokens und sichere Zugriffe (Zum Artikel). Eine umfassendere Übersicht über Rechte, Tools und Risiken beim Betrieb eigener MCP-Server liefert MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel).

Ein Agent, der lediglich Datenbankabfragen analysieren soll, benötigt beispielsweise normalerweise keine Berechtigung zum Löschen von Tabellen. Ein entsprechender Datenbankbenutzer sollte ausschließlich lesende Zugriffe erhalten. So bleibt eine kritische Aktion auch dann gesperrt, wenn der Agent sie aufgrund einer fehlerhaften Anweisung versucht.

CLAUDE.md ist keine Sicherheitsrichtlinie

Die Datei CLAUDE.md dient dazu, Claude Code Projektkontext und Arbeitsanweisungen bereitzustellen. Darin lassen sich beispielsweise Entwicklungsregeln festlegen:

# Projektregeln

- Verwende ausschließlich die bestehende Projektstruktur.
- Führe vor Änderungen zunächst die Tests aus.
- Verändere keine produktiven Konfigurationen.
- Installiere keine Pakete ohne Freigabe.
- Erstelle keine Git-Commits ohne Bestätigung.
- Dokumentiere sicherheitsrelevante Änderungen.

Solche Anweisungen sind hilfreich, weil sie das erwartete Verhalten beschreiben. Aber sie sind keine verbindliche Zugriffssperre. Wenn ein Coding-Agent technisch die Möglichkeit besitzt, eine Datei zu verändern, verhindert eine Textanweisung allein nicht zuverlässig jede unerwünschte Änderung. Das gilt insbesondere bei Prompt-Injection-Angriffen.

Für technische Prüfungen können stattdessen Claude Code Hooks eingesetzt werden. Beispielsweise kann ein PreToolUse-Hook einen Werkzeugaufruf vor seiner Ausführung untersuchen und unter bestimmten Bedingungen blockieren – etwa bestimmte Deployment-Befehle, bevor eine externe Freigabe vorliegt. Wichtig ist dabei, dass auch Hooks sorgfältig implementiert und gegen Manipulation geschützt werden müssen: Ein Hook, dessen Skript der Agent selbst verändern kann, ist keine belastbare Sicherheitsgrenze. Wie du eigene Hooks für genau solche Regeln aufbaust – von blockierten Befehlen bis zu erzwungenen Tests – zeigt Claude Code Hooks erklärt: Regeln und Automatisierungen im Projekt erzwingen (Zum Artikel).

Praxisbeispiel: Claude Code in einem Unternehmen absichern

Angenommen, ein Unternehmen entwickelt eine Webanwendung mit React, Node.js und einer MariaDB-Datenbank. Claude Code soll Entwickler bei Fehleranalysen, Tests und Codeänderungen unterstützen. Gleichzeitig sollen produktive Datenbanken, Zugangsdaten und Deployments geschützt bleiben. Dafür eignet sich ein mehrstufiges Sicherheitskonzept.

Diese Trennung reduziert das Risiko erheblich, weil Claude Code nicht dieselben Rechte benötigt wie ein Administrator oder ein produktiver Deployment-Dienst.

Checkliste: Ist deine Claude Code Installation sicher?

Mit der folgenden Checkliste kannst du deine Entwicklungsumgebung überprüfen:

• Claude Code läuft ohne Administrator- oder Root-Rechte.
• Berechtigungsregeln in settings.json sind überprüft.
• Automatisch erlaubte Shell-Befehle sind auf das Nötige begrenzt.
• Secrets befinden sich außerhalb des zugänglichen Arbeitsbereichs.
• Produktive Datenbanken und Server sind technisch abgeschottet.
• MCP-Server verwenden minimale Berechtigungen.
• Unsichere Permission-Bypass-Modi sind deaktiviert.
• Kritische Änderungen erfordern eine menschliche Freigabe.
• Projekt-Hooks und Sicherheitsregeln sind gegen Manipulation geschützt.
• Änderungen werden vor Commit, Merge und Deployment geprüft.

Häufige Fehler bei der Claude Code Sicherheit

Selbst mit einer vorhandenen settings.json können Sicherheitslücken entstehen. Ein typischer Fehler ist die Annahme, dass eine Positivliste automatisch alle nicht genannten Werkzeuge verbietet – das hängt vom aktiven Berechtigungsmodus und weiteren Regeln ab.

Ebenso problematisch ist es, einen Agenten innerhalb eines Containers auszuführen und ihm gleichzeitig Zugang zu produktiven Secrets oder privilegierten Host-Schnittstellen zu geben. Ein weiterer häufiger Fehler besteht darin, ausschließlich gefährlich aussehende Befehle zu sperren: Eine Blacklist einzelner Shell-Kommandos lässt sich unter Umständen über andere Programme, Skripte oder Befehlsvarianten umgehen.

Darum ist die Kombination aus minimalen Rechten, kontrollierten Werkzeugen und isolierter Infrastruktur wesentlich zuverlässiger als eine lange Liste verbotener Befehle.

Claude Code sicher konfigurieren bedeutet, Kontrolle zu behalten

Claude Code kann Entwicklungsprozesse erheblich beschleunigen. Der entscheidende Punkt ist jedoch, dass ein leistungsfähiger Coding-Agent nicht automatisch unbegrenzte Rechte benötigt.

Mit einer sorgfältig aufgebauten settings.json, klaren Berechtigungsregeln und einer kontrollierten Entwicklungsumgebung lassen sich viele Risiken reduzieren. Für Unternehmen sollte außerdem gelten: Produktive Zugangsdaten, Datenbanken und Deployments gehören nicht in den uneingeschränkten Aktionsbereich eines KI-Agenten.

Wer Claude Code sicher konfigurieren möchte, sollte daher nicht nur einzelne Befehle verbieten, sondern eine durchdachte Sicherheitsarchitektur aufbauen. So bleibt die KI ein leistungsfähiges Entwicklungswerkzeug, während die Kontrolle über kritische Systeme und Daten beim Menschen und bei technisch durchgesetzten Sicherheitsmechanismen liegt.

Weitere verständliche Anleitungen rund um KI, Coding und Systemadministration findest du im KI-Buster Blog.

Häufige Fragen zur sicheren Claude Code Konfiguration

Kann Claude Code Dateien außerhalb meines Projekts lesen?

Je nach Konfiguration, Werkzeug und Berechtigungen kann Claude Code auch auf Dateien außerhalb des ursprünglichen Projektverzeichnisses zugreifen. Deshalb sollten sensible Verzeichnisse zusätzlich über Betriebssystemrechte oder eine isolierte Umgebung geschützt werden.

Wie verhindere ich gefährliche Bash-Befehle?

Mit den Permissions in settings.json lassen sich bestimmte Befehlsmuster erlauben, ablehnen oder bestätigungspflichtig machen. Für einen belastbaren Schutz sollten zusätzlich Shell-Zugriffe und Betriebssystemrechte eingeschränkt werden.

Reicht eine CLAUDE.md für die Sicherheit aus?

Nein. CLAUDE.md beschreibt Regeln und Projektkonventionen für den Agenten. Technisch durchgesetzte Sicherheitsgrenzen entstehen erst durch Berechtigungen, Hooks, Betriebssystemrechte und geeignete Isolation.

Ist Claude Code in Unternehmen sicher einsetzbar?

Claude Code kann in Unternehmensumgebungen eingesetzt werden, wenn Zugriffe, Datenverarbeitung, Integrationen und Freigabeprozesse angemessen geregelt sind. Ob ein konkreter Einsatz sicher und datenschutzkonform ist, hängt von der jeweiligen Infrastruktur, Konfiguration und den verarbeiteten Daten ab.

Sollte Claude Code mit Root-Rechten laufen?

Im normalen Entwicklungsbetrieb ist das nicht empfehlenswert. Ein Coding-Agent sollte grundsätzlich nur die Rechte erhalten, die er für seine Aufgabe benötigt.

Können Claude Code Hooks Sicherheitsregeln erzwingen?

Hooks können Werkzeugaufrufe prüfen und unter bestimmten Bedingungen blockieren. Sie bieten damit eine zusätzliche technische Kontrollmöglichkeit, ersetzen aber weder sichere Betriebssystemberechtigungen noch eine isolierte Ausführungsumgebung.

Quellen und weiterführende Dokumentation

Redaktioneller Stand: 6. November 2026. Primärquellen: [1] Claude Code: Configure permissions – Permission-System, allow/ask/deny-Syntax und Settings-Vorrang. [2] Claude Code: Settings files and precedence – Speicherorte von settings.json und Konfigurationsebenen. [3] Claude Code: Security – Sicherheitsmodell und Schutzmaßnahmen. [4] Claude Code: Sandboxing – Isolierte Ausführungsumgebungen. [5] Claude Code: Hooks reference – Hook-Events und technische Kontrollmechanismen. Die Konfigurationsbeispiele sind eigene Beispiele zu Demonstrationszwecken; konkrete Berechtigungsregeln sollten vor produktivem Einsatz anhand der Dokumentation der jeweils installierten Claude-Code-Version überprüft und getestet werden.