Was darf Claude eigentlich? Sicherheit und Kontrolle im Unternehmen

Wenn ich Claude Code in Unternehmen vorstelle, kommt nach dem ersten „Wow“ fast immer dieselbe Frage: „Und was, wenn Claude etwas tut, was es nicht soll?“

Berechtigte Frage. Die gute Nachricht: Claude Code bringt mehrere Sicherheitsebenen mit, die sich gezielt einstellen lassen.

🔐 Berechtigungsregeln

In der settings.json legen Sie fest, was erlaubt ist, was nachfragen muss und was verboten ist. Verbote haben Vorrang. Zum Beispiel: Tests jederzeit starten, aber keine .env-Dateien lesen und kein git push ohne Rückfrage.

🧱 Sandbox

Mit /sandbox laufen Shell-Befehle in einer abgeschotteten Umgebung mit begrenztem Datei- und Netzwerkzugriff. Claude kann darin freier arbeiten, ohne dass ein Befehl ausbricht.

🏢 Zentral verwaltete Einstellungen

Für Teams gibt es verwaltete Einstellungen, die einzelne Entwickler nicht überschreiben können. Regeln wie „niemand liest Secrets“ setzen Sie so einmal für alle durch.

🧩 Erweiterungen bewusst zulassen

Plugins, MCP-Server und die neuen Mods (Teil 2) erweitern, was Claude kann. Mods laufen mit denselben Rechten wie Claude Code selbst, also nur aus vertrauenswürdigen Quellen installieren. Admins können festlegen, welche Plugin-Marktplätze erlaubt sind.

👀 Der Mensch bleibt im Loop

Keine Einstellung ersetzt das Review. Code von Claude geht bei uns denselben Weg wie jeder andere Code: Branch, Pull Request, Review.

Meine Faustregel:

• Im Projekt: Regeln ins Repository einchecken, damit alle dieselben Leitplanken haben.
• Im Unternehmen: zentral verwaltete Einstellungen plus eine kurze, klare Liste erlaubter Erweiterungen.

Sicherheit ist dabei kein Bremsklotz. Mit klaren Leitplanken kann man Claude mehr Freiheit geben, nicht weniger.