Claude Code Governance im Unternehmen
KI-Coding sicher einführen – Berechtigungen, Richtlinien und Sandbox im ÜberblickClaude Code im Unternehmen: Governance für KI-Coding
Der Entwicklungsleiter beantragt zwanzig Claude-Code-Zugänge, die Begründung ist ein Satz: „Die Konkurrenz liefert doppelt so schnell.“ Der Sicherheitsbeauftragte liest die Produktbeschreibung und bleibt an einer anderen Stelle hängen: Das Werkzeug liest Repositories, führt Shell-Befehle aus und ändert Dateien. Beide haben recht — und genau zwischen diesen beiden Sätzen entscheidet sich, ob KI-Coding bei euch ein Produktivitätsgewinn wird oder ein Vorfallsbericht.
Die gute Nachricht vorweg: Claude Code ist für genau diese Diskussion gebaut. Es gibt eine zentrale Richtlinienschicht, die Entwickler nicht überschreiben können, ein abgestuftes Berechtigungsmodell und eine Sandbox auf Betriebssystemebene. Dieser Artikel sortiert, welche Leitplanken es gibt, wo sie sitzen — und was trotzdem in eure Coding-Richtlinie gehört, weil Technik es nicht erledigt.
Warum Claude Code andere Governance braucht als der Chat
Ein Agent mit Händen
Der Chat beantwortet Fragen; Claude Code erledigt Aufgaben. Es liest die Codebasis, plant eine Änderung, schreibt sie in Dateien, führt Tests und Befehle aus und bereitet den Commit vor — im Terminal, in der Entwicklungsumgebung oder als Sitzung im Browser. Damit verschiebt sich die Governance-Frage grundlegend: Beim Chat regelt ihr, was Menschen eingeben dürfen. Bei einem Agenten regelt ihr, was das Werkzeug tun darf. Eine Eingaberichtlinie hilft wenig, wenn das eigentliche Risiko ein Befehl ist, den niemand getippt hat.
Die Kontrolle wandert an die Ränder
Dazu kommt ein unbequemer Mengeneffekt: Ein Agent produziert Änderungen schneller, als Menschen sie gründlich lesen können. Wer als Governance-Plan „wir reviewen halt jeden Diff wie bisher“ aufschreibt, plant mit einer Kontrolle, die dem Tempo nicht standhält. Die Konsequenz ist keine Kapitulation, sondern eine Verlagerung: nach vorn in die Voreinstellungen des Werkzeugs — was gar nicht erst passieren kann, muss niemand erkennen — und nach hinten in die automatisierten Prüfungen der CI, die unabhängig davon greifen, wer oder was den Code geschrieben hat. Das menschliche Review bleibt Pflicht, aber es ist die mittlere von drei Verteidigungslinien, nicht die einzige.
Bezug und Betrieb: Sitz, Konsole oder Cloud
Drei Bezugsmuster
Claude Code authentifiziert sich gegen einen von mehreren Wegen, und die Wahl bestimmt Abrechnung, Vertragslage und Funktionsumfang. Der Normalfall ist der Sitz im Team- oder Enterprise-Plan: Chat und Claude Code aus einem Abo, zentral verwaltete Sitze, keine eigene Infrastruktur — Anthropic selbst empfiehlt diesen Weg als Standard. Wer API-orientiert arbeitet oder nach Verbrauch zahlen will, nutzt die Entwicklerkonsole. Und wer Compliance-Rahmen und Abrechnung seines Cloud-Anbieters erben möchte, betreibt Claude Code über Bedrock, die Google-Plattform oder Microsoft Foundry. Ein Detail für die Planung: Einige Komfortfunktionen — etwa die Browser-Variante oder die Fernsteuerung laufender Sitzungen — setzen ein Claude-Konto voraus und stehen über reine API-Schlüssel oder Cloud-Zugänge nicht zur Verfügung.
Die Steuerung folgt dem Bezugsweg
Wichtig für die Architekturentscheidung: Auch die Verteilung eurer Richtlinien hängt am Bezugsweg. Über die Claude-Verwaltung ausgelieferte Einstellungen erreichen die Geräte bei der Anmeldung und aktualisieren sich stündlich — das setzt aber einen Team- oder Enterprise-Plan voraus. Auf den Cloud-Wegen verteilt ihr dieselben Vorgaben stattdessen über eure Geräteverwaltung oder eine geschützte Richtliniendatei auf dem Rechner. Wer Bezugswege mischt, braucht beides, sonst hat ein Teil der Entwickler Regeln und der andere Ratschläge.
|
INFO Der Sitz entscheidet, ob Claude Code überhaupt da ist Im Team- und Enterprise-Plan hängt der Zugang zu Claude Code am Sitztyp — nicht jeder Chat-Sitz bringt ihn automatisch mit. Wenn ein Entwickler beim Start die Meldung sieht, er sei der Organisation noch nicht hinzugefügt, ist das in aller Regel kein Anmeldefehler, sondern ein Sitz ohne Code-Zugang. Plant die Sitztypen deshalb entlang der Rollen und nicht nach dem Gießkannenprinzip — das ist derselbe Hebel, über den ihr später die Kosten steuert. |
|---|
Der Werkzeugkasten: was sich zentral erzwingen lässt
Verwaltete Einstellungen, die niemand überschreibt
Das Fundament ist eine Richtlinienschicht, die Vorrang vor allem hat, was Entwickler lokal oder im Projekt einstellen. Sie kommt wahlweise aus der Claude-Verwaltung, aus eurer Geräteverwaltung oder aus einer Datei, die nur mit Adminrechten beschreibbar ist. Die Logik dahinter ist angenehm kompromisslos: Zentrale Verbote lassen sich auf keiner anderen Ebene wieder aufheben, und bei Listen können Teams ergänzen, aber nichts entfernen. Projekte dürfen also strenger sein als die Organisation, nie großzügiger. Für den Nachweis zeigt ein Statusbefehl im Werkzeug an, welche verwalteten Einstellungen aktiv sind und über welchen Kanal sie ankommen — ein Screenshot davon beantwortet die Revisionsfrage schneller als jedes Konzeptpapier.
Berechtigungen: erlauben, fragen, verbieten
Innerhalb dieser Schicht arbeitet ein dreistufiges Berechtigungsmodell. Erlaubte Aktionen laufen ohne Rückfrage — sinnvoll für harmlose Routinebefehle wie Tests oder Statusabfragen. Alles andere fragt standardmäßig nach, bevor es ausgeführt wird. Und Verbotenes läuft gar nicht: destruktive Befehle, Lesezugriffe auf Geheimnispfade wie Schlüssel- und Umgebungsdateien, unerwünschte Netzwerkwerkzeuge. Dasselbe Modell erfasst auch angebundene Konnektoren und Erweiterungen — welche externen Server und Plugin-Quellen überhaupt zulässig sind, legt ihr zentral fest, statt es dem Zufall der Entwickler-Neugier zu überlassen. Und über Firmenanweisungen, die in jeder Sitzung geladen werden und sich nicht abwählen lassen, bekommt ihr eure Konventionen in den Arbeitskontext des Agenten hinein.
Die Sandbox schließt die Lücke, die Regeln lassen
Berechtigungsregeln haben eine Grenze, die man kennen sollte: Sie steuern die Werkzeuge des Agenten, nicht das Betriebssystem. Wer das Abruf-Werkzeug für Webseiten verbietet, aber Shell-Befehle erlaubt, hat das Netz nicht gesperrt — ein Kommandozeilenabruf erreicht weiterhin jede Adresse. Genau dafür gibt es die Sandbox: Datei- und Netzwerkisolation auf Betriebssystemebene mit einer Positivliste erlaubter Domains. Regeln steuern das Verhalten, die Sandbox erzwingt die Grenze. In sicherheitsbewussten Umgebungen gehören beide zusammen aktiviert, und die Domainliste ist kürzer, als man denkt: Paketquellen, interne Systeme, fertig.
Abb.: Der Entwickler-Workflow mit Leitplanken — vor, während und nach der Agentensitzung.
|
WARNUNG Der Bypass-Schalter gehört zentral abgeschaltet Claude Code kennt einen Modus, der sämtliche Freigabefragen überspringt — praktisch für abgeschottete Testumgebungen, fatal auf dem normalen Entwicklerrechner. Genau dafür existiert eine verwaltete Einstellung, die diesen Modus organisationsweit deaktiviert, und eine zweite, die ausschließlich zentrale Berechtigungsregeln gelten lässt. Beides gehört in eure Grundrichtlinie ab Tag eins. Eine Leitplanke, die sich per Startparameter umfahren lässt, ist Dekoration. |
|---|
|
WARNUNG Schatten-Nutzung läuft über Privatkonten und lose Schlüssel Das größte Loch in vielen KI-Coding-Richtlinien ist nicht das Werkzeug, sondern der Anmeldeweg: Entwickler mit privatem Abo oder einem irgendwo herumliegenden API-Schlüssel arbeiten an jeder Verwaltung vorbei. Dagegen gibt es zwei zentrale Vorgaben — die Anmeldung lässt sich auf eine Methode und auf eure Organisation festlegen, und Sitzungen über fremde Schlüssel werden dann schon beim Start blockiert. Kombiniert mit der Domain-Verifizierung eures Claude-Kontos bleibt vom Schattenpfad wenig übrig. |
|---|
Sichtbarkeit und Kosten
Agentensitzungen verbrauchen ein Vielfaches einer Chatfrage, und deshalb ist Kostentransparenz hier keine Kür. Auf Team- und Enterprise-Plänen liefert das Dashboard Nutzungs- und Beitragskennzahlen, der Ausgabenbericht schlüsselt den Verbrauch je Person auf, und Ausgabengrenzen setzt ihr direkt in der Verwaltung. Auf der Entwicklerkonsole übernehmen Arbeitsbereichs-Limits diese Rolle, auf den Cloud-Wegen die Budgetwerkzeuge des jeweiligen Anbieters. Und unabhängig vom Bezugsweg exportiert Claude Code Telemetrie über den offenen Standard OpenTelemetry — Sitzungen, Werkzeugaufrufe, Token — in eure vorhandene Monitoring-Landschaft. Wer eine aufrufgenaue Protokollierung braucht, setzt zusätzlich ein Gateway zwischen Entwickler und Anbieter.
Ein Rat aus der Praxis: Definiert die zwei, drei Kennzahlen, an denen ihr nach drei Monaten den Nutzen messen wollt — Durchlaufzeit von Tickets, Anteil KI-gestützter Commits, Nacharbeitsquote im Review — bevor die ersten Sitze verteilt sind. Hinterher misst niemand mehr den Ausgangszustand, und dann wird die Verlängerungsentscheidung wieder eine Gefühlsfrage.
Abb.: Vier Steuerungsebenen — Organisation, Gerät, Projekt, Sitzung. Verbote gewinnen auf jeder.
Was in die Coding-Richtlinie gehört
Code ist eine Datenklasse
Für den Datenschutzteil gilt die vertraute Grundlage: Auf Team-, Enterprise-, API- und Cloud-Wegen trainiert Anthropic nicht mit eurem Code und euren Eingaben. Aufbewahrung und Compliance-Rahmen bestimmt der gewählte Bezugsweg; für besonders sensible Umgebungen gibt es auf dem Enterprise-Weg die Option, dass nach Abschluss einer Anfrage nichts gespeichert bleibt. Was das Werkzeug euch nicht abnimmt: die Geheimnishygiene im eigenen Haus. Zugangsdaten in Konfigurationsdateien sind mit einem Agenten im Repo ein größeres Problem als ohne — die Leseverbote auf Geheimnispfade gehören deshalb in die zentrale Richtlinie und ein Secret-Scanner in die CI, unabhängig von jeder KI-Diskussion.
Regeln, die Technik nicht ersetzt
Drei Dinge gehören ins Papier, weil kein Schalter sie erledigt. Erstens die Verantwortung: Wer den Merge freigibt, steht für den Code gerade — der Agent ist Werkzeug, nicht Autor mit Haftung. Zweitens die Eigentümer: Jede Kontrolle braucht einen Namen. Die Entwicklungsleitung verantwortet Arbeitsweise und Repo-Konventionen, die Sicherheit die Grundrichtlinie und Ausnahmen, die Plattform-Mannschaft Verteilung und Telemetrie. Eine Richtlinie ohne Eigentümer verwässert mit der ersten Ausnahme. Drittens der Ausnahmeprozess selbst: Es wird Teams geben, die mehr Freiheit brauchen — ein definierter Weg mit Begründung und Ablaufdatum ist besser als stille Sonderlocken, von denen die Sicherheit nichts weiß. Der Rest ist erfreulich normale Ingenieursdisziplin: Branch-Schutz, Testpflicht, Review — nur eben konsequent, weil jetzt mehr Code in kürzerer Zeit ankommt.
Nicht jedes Repo am ersten Tag
Eine Frage, die in der Richtlinie gern fehlt: An welchen Repositories darf der Agent überhaupt arbeiten? Technisch sieht Claude Code das, worauf der Entwickler Zugriff hat — die Auswahl ist also eine organisatorische Entscheidung, keine Werkzeugeinstellung. Bewährt hat sich eine Staffelung: Los geht es mit Repositories niedriger Sensibilität — interne Werkzeuge, Testprojekte, gut abgedeckte Services —, dann folgt der Produktcode, und Sonderfälle wie Repositories mit regulatorischem Gewicht oder eingekauftem Fremdcode kommen zuletzt und mit eigener Bewertung. Das ist keine Misstrauenserklärung an das Werkzeug, sondern schlichte Lernkurvenplanung: Die ersten Wochen produzieren Erkenntnisse über Konventionen, Prompts und Review-Praxis, und die sammelt man besser dort, wo Fehler billig sind.
Abb.: Vier Risiken aus dem Sicherheitsgespräch — und die technischen Gegenmittel dazu.
|
PRAXIS-TIPP Das Startpaket: fünf Regeln für die erste Woche Wer nicht bei null anfangen will: Bypass-Modus zentral deaktivieren, Leseverbote auf Schlüssel- und Umgebungsdateien setzen, Sandbox mit kurzer Domain-Positivliste aktivieren, Anmeldung auf die eigene Organisation festlegen und eine Mindestversion des Werkzeugs erzwingen. Diese fünf Zeilen decken die häufigsten Sorgen ab, stören keinen einzigen sauberen Arbeitsablauf — und geben euch Ruhe, die restliche Richtlinie mit den Entwicklern statt gegen sie zu bauen. |
|---|
Häufige Fragen (FAQ)
Was ist Claude Code, und wie unterscheidet es sich vom Claude-Chat?
Claude Code ist Anthropics Coding-Agent für Terminal, Entwicklungsumgebung und Browser: Er liest die Codebasis, ändert Dateien, führt Befehle und Tests aus und bereitet Commits vor — der Chat beantwortet dagegen Fragen, ohne selbst zu handeln. Für die Governance heißt das: Beim Chat regelt ihr Eingaben, bei Claude Code regelt ihr Handlungen, über Berechtigungen, zentrale Richtlinien und eine Sandbox. Beides läuft auf denselben Unternehmensplänen und unter denselben Datenzusagen.
Wie verhindern wir, dass Claude Code gefährliche Befehle ausführt?
Über drei Schichten: Das Berechtigungsmodell erlaubt, erfragt oder verbietet einzelne Werkzeuge und Befehle, zentrale Verbote lassen sich von niemandem aufheben, und der Modus zum Überspringen aller Freigaben lässt sich organisationsweit deaktivieren. Darunter erzwingt die Sandbox Datei- und Netzgrenzen auf Betriebssystemebene, inklusive Positivliste erlaubter Domains. Die dritte Linie ist eure CI mit Branch-Schutz und Testpflicht — sie greift, egal wer den Code geschrieben hat.
Trainiert Anthropic mit unserem Quellcode?
Nein — auf den Unternehmens-Bezugswegen, also Team, Enterprise, API und den Cloud-Plattformen, werden euer Code und eure Eingaben standardmäßig nicht für das Modelltraining verwendet. Aufbewahrungsfristen und Compliance-Rahmen hängen am gewählten Bezugsweg; für qualifizierte Enterprise-Konten gibt es zusätzlich die Option, dass nach Abschluss einer Anfrage nichts gespeichert bleibt. Privatkonten spielen in einer anderen Liga und gehören deshalb per Anmeldevorgabe ausgesperrt.
Welche Lizenz brauchen Entwickler für Claude Code?
Der Standardweg ist ein Sitz im Team- oder Enterprise-Plan, der Chat und Claude Code gemeinsam abdeckt — dabei hängt der Code-Zugang am Sitztyp, nicht jeder Sitz bringt ihn mit. Alternativ läuft Claude Code über die Entwicklerkonsole nach Verbrauch oder über Bedrock, die Google-Plattform und Microsoft Foundry, wenn ihr Abrechnung und Compliance-Rahmen eures Cloud-Anbieters nutzen wollt. Einzelne Funktionen wie die Browser-Variante setzen allerdings ein Claude-Konto voraus.
Können Entwickler die zentralen Vorgaben umgehen?
Nicht, wenn die Richtlinie richtig verteilt ist: Verwaltete Einstellungen haben Vorrang vor allem Lokalen, Verbote lassen sich auf keiner Ebene aufheben, und die Auslieferung über Geräteverwaltung oder geschützte Systempfade erfordert Adminrechte zum Ändern. Die realen Umgehungswege sind organisatorisch — Privatkonten und lose API-Schlüssel — und genau dafür gibt es die Anmeldevorgaben samt Blockade fremder Schlüssel. Kontrollieren lässt sich der Zustand jederzeit über den Statusbefehl im Werkzeug.
Weiterlesen
Wie Claude im Unternehmen insgesamt aufgesetzt wird — Lizenzen, Identität, Datenschutz und Microsoft-Umfeld — steht im Überblick Claude im Unternehmen. Und wenn ihr Claude Code gerade einführt und die Grundrichtlinie lieber in einer Woche stehen habt als in einem Quartal: In der Beratung zu Claude und KI-Governance bauen wir Richtlinie, Verteilweg und Kennzahlen zusammen mit eurer Entwicklung auf.