Claude Code Security Best Practices für Teams im Jahr 2026

Zuletzt aktualisiert: June 28, 2026

Ein AI-Coding-Agent, der Ihr Repo lesen, Shell-Befehle ausführen und externe Dienste aufrufen kann, ist genau deshalb nützlich, weil er Reichweite hat. Diese gleiche Reichweite ist das Risiko. Ein falsch interpretiertes Prompt, eine nachlässige Allowlist oder ein nicht vertrauenswürdiger MCP-Server können einen Token durchsickern lassen oder einen Branch löschen. Dieser Leitfaden richtet sich an Entwickler oder Plattformleiter, die Claude Code im täglichen Gebrauch und in CI verwenden möchten, ohne ihm die Schlüssel zur Produktion zu übergeben.

Kurze Antwort: Wie halten Teams Claude Code sicher?

Der Agent sollte mit dem geringsten Privileg ausgeführt werden, und es muss überprüft werden, was er tut. In der Praxis bedeutet das fünf Dinge:

• Starten Sie im restriktiven Modus und gewähren Sie Tools über eine enge Allowlist, nicht durch ein pauschales „immer erlauben“.
• Halten Sie Secrets aus dem Kontext des Modells: keine eingefügten Schlüssel und eine deny-Regel für .env und Secret-Pfade.
• Überprüfen Sie jeden MCP-Server, bevor Sie ihn verbinden, da ein nicht vertrauenswürdiger Server Daten lesen und in Ihrem Namen handeln kann.
• Behandeln Sie abgerufene Webinhalte als nicht vertrauenswürdige Eingaben, die Prompt-Injection-Anweisungen enthalten können.
• In CI geben Sie dem Agenten einen kurzlebigen, read-scoped Token und legen niemals Produktionsanmeldeinformationen frei.

Der Rest dieses Artikels wandelt jedes dieser Punkte in konkrete Einstellungen um, zusammen mit einer Risiko-Tabelle, einem Berechtigungsreferenzblatt und einem CI-Szenario, das Sie kopieren können.

Wie funktionieren Berechtigungsmodi und Allowlists eigentlich?

Claude Code fragt, bevor es ein Tool zum ersten Mal ausführt. Sie entscheiden, ob diese Entscheidung gespeichert, eingeschränkt oder übersprungen wird. Der Berechtigungsmodus legt die Basis fest:

• default fordert bei der ersten Nutzung jedes Tools oder Befehls Prompts an.
• plan ist schreibgeschützt (read-only): Der Agent kann Dateien lesen und einen Plan vorschlagen, aber keine Befehle bearbeiten oder ausführen. Verwenden Sie ihn zur Überprüfung.
• acceptEdits akzeptiert Datei-Bearbeitungen automatisch, fordert aber weiterhin Prompts für Shell-Befehle an.
• bypassPermissions überspringt jeden Prompt. Behandeln Sie dies nur als Sandbox.

Die dauerhaften Kontrollen befinden sich in .claude/settings.json unter permissions, mit allow, ask und deny-Regeln. Regeln sind nach Tool und Muster eingeschränkt, sodass Sie genau das gewähren, was eine Aufgabe benötigt:

{
  "permissions": {
    "allow": ["Read", "Edit", "Bash(npm test:*)", "Bash(git diff:*)"],
    "ask": ["Bash(git push:*)", "WebFetch"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(curl:*)", "Bash(rm -rf:*)"]
  }
}

Eine deny-Regel hat immer Vorrang vor einer allow-Regel, weshalb die oben genannten Secret-Pfade auch dann nicht lesbar bleiben, wenn eine breite Read-Regel existiert. Anthropic dokumentiert die vollständige Syntax und Präzedenz der Regeln in den Claude Code identity and access management docs.

Vermeiden Sie --dangerously-skip-permissions außerhalb eines einwegigen Containers. Es entfernt den einen menschlichen Kontrollpunkt, der einen fehlerhaften rm oder einen unerwarteten Netzwerkaufruf abfängt. Wenn Sie Geschwindigkeit ohne dieses Risiko wünschen, bevorzugen Sie eine enge Allowlist, damit routinemäßige Befehle unbeaufsichtigt laufen, während alles Neue immer noch für Sie pausiert.

Referenz zu Risiken und Abhilfemaßnahmen

Die meisten Vorfälle lassen sich auf eine Handvoll Muster zurückführen. Ordnen Sie jedes einem Kontrollmechanismus zu, bevor Sie den Agenten über ein Team skalieren.

Die Strukturierung folgt dem OWASP Top 10 for LLM Applications, das Prompt Injection, unsichere Ausgabebehandlung und übermäßige Agentur als führende Agentenrisiken nennt.

Referenz zu Berechtigungen und Scope

Diese Tabelle ist der Leitfaden, den ich neuen Teammitgliedern gebe. Sie behandelt die Einstellungen, die den Schadensradius eines einzelnen Laufs verändern können.

Überprüfung von MCP-Servern vor der Verbindung

MCP-Server erweitern den Agenten mit neuen Tools: einem Datenbankclient, einer Ticket-Integration, einem Browser. Jedes hinzugefügte Element ist Code, der Kontext lesen und Aktionen ausführen kann. Ein nicht vertrauenswürdiger Server ist der schnellste Weg, einen hilfreichen Agenten in einen Datenexfiltrationspfad zu verwandeln, daher muss die Schwelle für eine Verbindung dieselbe sein wie bei jeder Abhängigkeit mit Netzwerkzugriff.

Bevor Sie einen Server hinzufügen, beantworten Sie fünf Fragen:

1. Wer veröffentlicht ihn und ist die Quelle öffentlich und gewartet?
2. Welche Scopes fordert er an: nur Lesezugriff oder Schreib- und Netzwerkzugriff?
3. Welche Daten kann er sehen, sobald er verbunden ist: nur dieses Repo oder Ihre gesamte Maschine?
4. Sind Anmeldeinformationen eingeschränkt und kurzlebig, oder handelt es sich um einen langfristigen Admin-Token?
5. Können Sie eine Version festlegen (pin), damit ein Update nicht stillschweigend seinen Zugriff erweitert?

Verbinden Sie Server mit dem geringsten Scope, der die Aufgabe erfüllt, und halten Sie schreibfähige oder produktionsbezogene Server aus geteilten oder CI-Konfigurationen fern. Für Setup-Mechaniken und einen tiefergehenden Durchgang sehen Sie sich unseren Claude Code MCP integration guide an. Der Beitrag Claude Code productivity tips behandelt, wie man den Fußabdruck klein hält, ohne sich selbst zu verlangsamen.

Secrets aus der Reichweite des Modells halten

Das sauberste Secret ist das, das das Modell nie sieht. Fügen Sie API-Schlüssel nicht in den Prompt ein und bitten Sie den Agenten nicht, „den Schlüssel aus der Konfiguration zu lesen und zu verwenden“. Lassen Sie Anmeldeinformationen in der Umgebung leben und referenzieren Sie sie nach Namen, damit der Wert außerhalb des Transkripts bleibt.

Drei Gewohnheiten decken das meiste Risiko ab:

• Fügen Sie eine deny-Regel für .env, *.pem und jedes secrets/-Verzeichnis hinzu, damit der Agent sie nicht einmal versehentlich lesen kann.
• Verwenden Sie einen Pre-Commit Secret Scanner (wie gitleaks oder git secrets), damit ein durchrutschender Schlüssel den Commit fehlschlagen lässt, nicht das Audit.
• Rotieren Sie alles, was doch offengelegt wird, sofort und überprüfen Sie dann die Logs und Historie. Die Rotation ist der einzige Fix, der das Fenster tatsächlich schließt.

Wenn ein Schlüssel bereits ein Transkript oder einen Commit erreicht hat, gehen Sie davon aus, dass er kompromittiert ist, und rotieren Sie ihn. Das Durchsuchen des git-Verlaufs mit git log -S hilft Ihnen herauszufinden, wo er gelandet ist.

Szenario: Claude Code in CI ohne Produktionsanmeldeinformationen aktivieren

Ein Team möchte, dass Claude Code Pull Requests in GitHub Actions überprüft. Ziel sind automatisierte Überprüfungs-Kommentare bei null Fähigkeit zu deployen, auf main zu schreiben oder auf die Produktionsdatenbank zuzugreifen.

Hier ist das Setup, das den Job nützlich, aber eingegrenzt hält:

• Führen Sie headless mit claude -p im plan-Modus aus, damit der Agent den Diff liest und einen Kommentar schreibt, aber niemals Dateien bearbeitet oder Build-Befehle ausführt.
• Gewähren Sie dem Workflow nur contents: read und pull-requests: write. Kein Deploy-Job, kein Infrastruktur-Scope.
• Verwenden Sie den kurzlebigen GITHUB_TOKEN des Jobs, keinen persönlichen Token, und legen Sie niemals Datenbank- oder Cloud-Produktionsschlüssel in die Umgebungsvariablen dieses Jobs.
• Fügen Sie eine deny-Liste für Secret-Pfade und ausgehenden curl hinzu, damit ein Prompt-Injection-Versuch innerhalb des PR-Diffs nichts exfiltrieren kann.
• Legen Sie die Action- und Claude Code Version fest (pin), und begrenzen Sie jeden Deploy-Schritt hinter einer separaten, menschlich genehmigten Umgebung.

permissions:
  contents: read
  pull-requests: write
steps:
  - run: claude -p "Review the diff for security issues" --permission-mode plan
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Der Überprüfungsjob sieht den Code und postet Feedback. Er kann nicht auf die Produktion zugreifen, da Produktionsanmeldeinformationen niemals im Scope sind. Anthropic's Claude Code security overview beschreibt diese least-privilege Haltung für automatisierte und headless Läufe.

Was sollten Sie niemals in einen AI Coding Agent einfügen?

Einige Eingaben gehören nirgendwo in die Nähe eines Transkripts, denn alles im Kontextfenster kann wiederholt, protokolliert oder darauf gewirkt werden:

• Live API-Schlüssel, Datenbank-URLs mit Passwörtern oder Cloud-Root-Anmeldeinformationen.
• Kundendaten PII oder regulierte Daten, die Sie nicht in einem Support-Ticket angeben würden.
• Private Signierungsschlüssel, Zertifikate oder .pem-Dateien.
• Vollständige Produktions-Verbindungszeichenketten, wenn ein Read Replica oder ein lokaler Fixture ausreichen würde.

Wenn der Agent Zugriff benötigt, geben Sie ihm einen Pfad zu einer eingeschränkten Anmeldeinformation über die Umgebungsvariablen und nicht das Secret selbst. Gleiches Ergebnis, viel kleinerer Schadensradius.

Auditing, Hooks und laufende Überprüfung

Least privilege setzt den Boden; die Überprüfung hält Sie dort. Lesen Sie den Plan des Agenten, bevor Sie einen riskanten Schritt genehmigen, und lesen Sie den Diff, bevor Sie committen. Bei größeren Änderungen gilt dieselbe Disziplin, die AI-assisted refactoring sicher macht: kleine, überprüfbare Schritte schlagen einen riesigen unbeaufsichtigten Lauf.

Fügen Sie deterministische Guardrails mit Hooks hinzu. Ein PreToolUse-Hook kann einen Befehl inspizieren und ihn blockieren, bevor er ausgeführt wird – so erzwingen Sie Regeln, die das Modell niemals überschreiben sollte, wie z. B. die Ablehnung jeglicher Schreibvorgänge an einem geschützten Pfad. Kombinieren Sie dies mit einem Prüfprotokoll (audit trail), damit Sie antworten können, was der Agent getan hat, wann und in wessen Namen.

Eine schnelle, wiederkehrende Checkliste für das Team:

• Überprüfen Sie die allow und deny-Listen in .claude/settings.json regelmäßig, nicht nur bei der Einrichtung.
• Überprüfen Sie MCP-Server nach größeren Versionssprüngen erneut.
• Bestätigen Sie, dass CI-Jobs immer noch im plan-Modus laufen und keine Produktionsgeheimnisse enthalten.
• Rotieren Sie Tokens in einem festen Rhythmus und nach jeder vermuteten Offenlegung.
• Behalten Sie eine CLAUDE.md bei, die die nicht verhandelbaren Punkte festlegt: kein Force-Push auf main, kein direkter Prod-DB-Zugriff, keine Secrets im Prompt.

Für den breiteren Workflow rund um all dies führt der Claude Code ultimate guide von der Konfiguration bis zum Ende durch.

Kernbotschaft

Die Sicherheit für AI Coding Agents ist das gleiche least-privilege Denken, das Sie bereits auf Service Accounts anwenden, niedergeschrieben als Berechtigungsregeln. Beginnen Sie restriktiv, erweitern Sie mit einer engen Allowlist, verweigern Sie Secret-Pfade, überprüfen Sie MCP-Server wie Abhängigkeiten, behandeln Sie abgerufene Inhalte als nicht vertrauenswürdig und halten Sie Produktionsanmeldeinformationen aus jedem Job, den der Agent erreichen kann. Tun Sie das, und Claude Code bleibt ein schneller Paar Hände, kein offenes Tor.