Claude Code sicher einsetzen

16. Juni 2026 · von Melchior Limacher · KI-Sicherheit

KI-Coding-Agenten wie Claude Code sind aus manchen Umgebungen kaum noch wegzudenken. Sie analysieren und schreiben Dateien, oft schneller und konsistenter als ein Mensch. Das macht sie produktiv - es schafft aber auch neue Angriffsfläche. Intuitiv ist den meisten Nutzern klar, dass über einen bösartigen Agenten Informationen abfliessen oder verfälscht werden können. Man gibt ja schliesslich einem Agenten innerhalb definierter Verzeichnisse faktisch Lese- und Ausführungsrechte. Nicht auf Anhieb klar ist die Frage, wie Claude Code damit umgeht, wenn in neu heruntergeladenen Dateien wie beispielsweise Git-Repositories sich Instruktionen wie CLAUDE.md befinden. Dieser Beitrag zeigt Möglichkeiten, wie man in Claude Code Restriktionen konfigurieren kann, um das entsprechende Risiko zu reduzieren.

Claude Code bringt verschiedene Schutzmechanismen mit. Ein Teil davon sei hier vorgestellt.

Anweisungen sind nicht gleich Kontrolle

Claude Code liest beim Start sogenannte CLAUDE.md-Dateien ein – Projektanweisungen, die das Verhalten des Agenten steuern. Wichtig ist, wie diese Dateien wirken: CLAUDE.md-Inhalte sind Kontext, keine erzwungene Konfiguration. Der Agent versucht, ihnen zu folgen, aber sie sind keine harte Schranke.

Daraus folgt das eigentliche Risiko: Eine CLAUDE.md aus einem fremden, geklonten Repository ist nicht vertrauenswürdiger als der Code darin. Sie ist von Dritten verfasst und kann Anweisungen enthalten, die nicht in Ihrem Interesse sind – Stichwort Prompt Injection. Klont man ein Repository mit eigener CLAUDE.md in ein Arbeitsverzeichnis, gelangt deren Inhalt in den Kontext des Agenten:

Die gute Nachricht: Man kann beides eingrenzen und – wo nötig – theoretisch auch hart durchsetzen. Sinnvoll ist ein gestaffelter Ansatz aus mehreren Schichten. Davor steht aber ein Grundprinzip, das über allem liegt.

Grundprinzip: minimale Rechte (Least Privilege)

Alle folgenden Massnahmen bauen auf einem altbekannten Prinzip auf: Least Privilege. Eine Komponente – auch ein KI-Agent – soll nur jene Rechte besitzen, die sie für ihre Aufgabe zwingend braucht, und nicht mehr. Eine Claude-Instanz mit weitreichenden Rechten ist das attraktivste Angriffsziel und der grösste Single Point of Failure. Für Claude Code heisst das konkret:

Eng damit verbunden ist die Separation of Privileges: Rechte nicht in einer einzigen, allmächtigen Instanz bündeln, sondern nach Vertrauens- und Aufgabenbereich trennen. Eine Claude-Instanz, die fremden Code analysiert, sollte nicht dieselben Rechte haben wie eine, die in Ihr Produktivsystem deployt. Getrennte Instanzen, getrennte Benutzer, getrennte Tokens – so führt eine kompromittierte Sitzung nicht zur Kompromittierung der gesamten Umgebung. Die folgenden Schichten setzen dieses Prinzip technisch um.

Schicht 1 – Fremde Anweisungen ausschliessen

Mit claudeMdExcludes legt man fest, welche CLAUDE.md-Dateien übersprungen werden. Bewährt hat sich, fremde Repositories konsequent in einen festen Unterordner (z. B. external/) zu klonen und genau diesen auszuschliessen. Am besten lokal in .claude/settings.local.json:

{
  "claudeMdExcludes": [
    "/pfad/zum/projekt/external/**/CLAUDE.md",
    "/pfad/zum/projekt/external/**/.claude/rules/**"
  ]
}

Die Regel wirkt auf Benutzer-, Projekt- und lokaler Ebene; die Listen werden über die Ebenen zusammengeführt. Verwenden Sie enge Muster (dedizierter external/-Pfad) statt pauschal **/CLAUDE.md, damit nicht versehentlich Ihre eigene Projekt-Datei stummgeschaltet wird.

Schicht 2 – Dateizugriff sperren

Berechtigungen steuern, welche Tool-Aufrufe überhaupt erlaubt sind. Mit Read-Regeln in permissions.deny verhindert man, dass der Agent bestimmte Dateien liest – breiter als nur das Memory:

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

Das schützt eigene Geheimnisse. Es kann aber auch verhindern, dass bestimmte nicht vertrauenswürdige Daten gelesen werden und so in das Kontextfenster gelangen.

Schicht 3 – Verhalten erzwingen: PreToolUse-Hook

Die Schichten 1 und 2 steuern Kontext und Zugriff. Soll eine Aktion unabhängig davon blockiert werden, was im Text steht oder was der Agent «entscheidet», braucht es einen Hook. Ein PreToolUse-Hook läuft vor jedem Tool-Aufruf und ist client-seitig erzwungen. Somit ist der PreToolUse-Hook eine deterministische und damit zuverlässige Sicherheitsschicht. 

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "/home/user/.claude/hooks/bashguard.sh" }
        ]
      }
    ]
  }
}

Das Skript erhält den geplanten Aufruf als JSON auf stdin (tool_name, tool_input, …) und entscheidet: exit 2 blockiert, und die Ausgabe auf stderr wird dem Agenten als Begründung zurückgegeben. Alternativ steuert man feingranular per JSON mit permissionDecision: allow, deny oder ask.

Beispiel bashguard.sh – blockiert destruktive Befehle und naheliegende Datenabflüsse:

#!/bin/bash
# PreToolUse-Hook: blockiert netcat und "rm -rf" in jeder Flag-Schreibweise.
cmd=$(jq -r '.tool_input.command // ""')

# Whitespace normalisieren (Tabs/Umbrueche -> ein Leerzeichen)
norm=$(printf '%s' "$cmd" | tr '\t\n\r' '   ' | tr -s ' ')

block() { echo "Blockiert durch Sicherheits-Hook ($1): $cmd" >&2; exit 2; }

# netcat: als eigenes Wort, mit optionalem Pfad und Suffix
# (nc, ncat, netcat, /bin/nc, nc.traditional ...)
printf '%s' "$norm" | grep -Eqi '(^|[ |&;(])(/[^ ]*/)?(nc|ncat|netcat)([ .]|$)' \
  && block "netcat"

# rm nur, wenn es wirklich als Befehl aufgerufen wird ...
if printf '%s' "$norm" | grep -Eqi '(^|[ |&;(])(/[^ ]*/)?rm( |$)'; then
  # ... und rekursiv UND force gesetzt sind (Reihenfolge/Kurz-/Langform egal)
  printf '%s' "$norm" | grep -Eqi '(-[a-z]*r|--recursive)' \
    && printf '%s' "$norm" | grep -Eqi '(-[a-z]*f|--force)' \
    && block "rm -rf"
fi
exit 0

Diese Variante fängt netcat (auch ncat, netcat, mit vorangestelltem Pfad oder als nc.traditional) sowie rm mit rekursiv und force in beliebiger Flag-Reihenfolge und in Kurz- wie Langform (-rf, -fr, -r -f, --recursive --force) ab. Sie ist damit deutlich robuster als eine starre Zeichenkette. Ehrlich bleiben muss man trotzdem: Eine textbasierte Prüfung hat prinzipielle Grenzen. Verschleierung über Variablen, Aliasse, Kodierung oder alternative Werkzeuge lässt sich so nicht restlos verhindern. Der Hook ist deshalb eine Ergänzung zu Least Privilege und Sandbox, kein Ersatz.

Wichtig: Hooks laufen mit Ihren Rechten und werden erst nach Bestätigung aktiv. Der Code des Hooks ist Ihre Verantwortung – er ist Teil der Vertrauensbasis, nicht ausserhalb davon.

Schicht 4 – Imports kontrollieren

Eine CLAUDE.md kann über @pfad weitere Dateien importieren. Beim ersten Auftreten externer Imports zeigt Claude Code einen Bestätigungsdialog. Lehnt man ab, bleiben diese Imports dauerhaft deaktiviert. Im Zweifel: ablehnen.

Schicht 5 – Organisationsweite Vorgaben

In Unternehmen lässt sich eine zentral verwaltete CLAUDE.md ausrollen, die für alle Sessions auf einer Maschine gilt und von einzelnen Nutzern nicht ausgeschlossen werden kann. Sie liegt am Managed-Policy-Ort (unter Linux z. B. /etc/claude-code/CLAUDE.md) bzw. wird über managed-settings.json verteilt. Für technische Durchsetzung gehören Regeln wie permissions.deny oder sandbox.enabled in die Managed Settings – CLAUDE.md bleibt für Verhaltensleitlinien.

Laufende Kontrolle

Zusammengefasst

Sicherheit bei KI-Agenten ist kein einzelner Schalter, sondern eine Staffelung:

  1. Least Privilege & Separation of Privileges – dem Agenten nur die nötigen Rechte geben und Aufgaben auf getrennte Instanzen verteilen.
  2. claudeMdExcludes – fremde Anweisungen gar nicht erst laden.
  3. permissions.deny – Zugriff auf sensible Pfade sperren.
  4. PreToolUse-Hook – kritische Aktionen erzwungen blockieren.
  5. Import- und Trust-Dialoge – bewusst entscheiden statt durchklicken.
  6. Managed Policy – organisationsweite Leitplanken.

Keine dieser Massnahmen ist für sich vollständig. Anweisungsbasierte Steuerung (CLAUDE.md) und erzwungene Steuerung (Berechtigungen, Hooks) erfüllen unterschiedliche Aufgaben – erst zusammen ergeben sie ein belastbares Bild. Die Grundregel bleibt: Fremder Code und fremde Anweisungen sind nicht vertrauenswürdige Eingaben. Behandeln Sie sie auch so.

Weiterführende Links

  1. https://code.claude.com/docs/en/memory
  2. https://code.claude.com/docs/en/settings
  3. https://code.claude.com/docs/en/hooks
Alle Beiträge