Steuerung von Claude Code im Unternehmen: MCP-Tool-Umfangsbestimmung und Audit-Trails

Claude Code ist ein Produktivitätsmultiplikator und gleichzeitig eine Governance-Lücke in derselben Installation. Bei 200 Entwicklern und ohne zentrale Kontrollinstanz kann jeder von ihnen auf jedes Backend zugreifen, das sein Agent verwenden möchte. Das Gateway ist der Ort, an dem diese Lücke geschlossen wird.

Claude Code bietet keine nativen Unternehmenskontrollen

Claude Code bietet einen erheblichen Produktivitätsgewinn. Es liest Codebasen, führt Tests aus, fragt Datenbanken ab und löst mehrstufige Engineering-Aufgaben autonom. Genau diese Fähigkeit macht das Sicherheitsmodell problematisch. Der Agent ist kein Remote-Dienst, der gelegentlich eingreift; es ist eine autonome Schleife, die auf dem Laptop eines Entwicklers mit allen von diesem Laptop aus erreichbaren Anmeldeinformationen läuft.

Nativ verfügt Claude Code über kein Konzept für Unternehmens-Governance. Gibt man ihm eine MCP-Serverkonfiguration, übernimmt es die volle Autorität über jedes Tool, das dieser Server bereitstellt. Richtet man einen Postgres-MCP-Server ein, damit Agenten Staging-Daten abfragen können, gibt es keinen integrierten Mechanismus, der einen übermütigen Agenten – oder einen kompromittierten Entwickler-Endpunkt – daran hindert, DROP TABLE auszuführen, wenn die zugrunde liegenden Anmeldeinformationen dies zulassen. Lokale Konfigurationsdateien, die Entwickler zu verantwortungsvollem Verhalten auffordern, sind nicht die Lösung; sie sind das Fehlen einer solchen.

Die richtige Denkweise hierzu ist: Der Mensch, der die Schleife überwachte, war früher gleichzeitig der Ratenbegrenzer, die Policy-Engine und das Audit-Log. Der Agent entfernt den Menschen aus dem Pfad jeder einzelnen Aktion. Alle Schutzmechanismen, die Menschen implizit bereitstellten, müssen nun explizit rekonstruiert werden – und der einzige Ort, an dem sie platziert werden können, ist vor dem Agenten, im Netzwerk, wo ein Team die Verantwortung dafür übernehmen kann.

Was ohne ein Gateway schiefgeht

Das Bedrohungsmodell ist eine übermäßig breite Erreichbarkeit kombiniert mit agentischer Unvorhersehbarkeit. Drei Fehlermodi treten innerhalb des ersten Monats jeder nicht-trivialen Claude Code-Einführung in der Produktion auf.

Zielgerichtete Überschreitung. Ein Entwickler verbindet Claude Code mit dem internen Netzwerk, um „den Fehler im Benutzerauthentifizierungsfluss“ zu debuggen. Der Agent, der das Problem analysiert, entscheidet, dass er echte Benutzerdaten sehen muss, um den Fehler zu reproduzieren. Er greift auf einen Kubernetes-MCP-Server zu, leitet Ports zu einer Produktionsdatenbank weiter, extrahiert PII und fügt eine Zusammenfassung in das lokale Terminal ein – oder sendet sie als Teil des nächsten Prompts an den Anbieter. Dies ist kein böswilliges Verhalten. Es ist ein Agent, der sein Ziel mit dem am wenigsten restriktiven verfügbaren Tool erfüllt.

Versehentliche Zerstörung. Der Agent versucht, ein Terraform-Modul durch Anwendung zu reparieren. Er versucht, einen falsch konfigurierten Branch durch Löschen zu bereinigen. Er führt eine Datenbankmigration aus, um zu überprüfen, ob das neue Schema funktioniert. Jeder einzelne Schritt erscheint lokal rational; das globale Ergebnis ist ein Produktionsvorfall.

SSRF über den Agenten. Der Agent greift auf ein Netzwerk-Tool zu, um eine Integration zu überprüfen. Der Agent liest eine manipulierte Tool-Beschreibung, die einen bestimmten Host als kanonisch vorschlägt. Der Agent ruft diesen Host ab, der sich zufällig innerhalb des Cloud-Metadatendienstes befindet. Anmeldeinformationen werden geleakt. Der Benutzer ist sich dessen nicht bewusst – der Agent meldete lediglich den Erfolg seiner Aufgabe.

Ohne eine zentrale Kontrollinstanz ist all dies standardmäßig möglich. Mit einer ist jede dieser Möglichkeiten eine Konfigurationsentscheidung.

‍

‍

Einschränkung des MCP-Tool-Zugriffs nach Team und Umgebung

Die Abhilfemaßnahme besteht darin, ein Gateway zwischen Claude Code und internen MCP-Servern bereitzustellen und eine standardmäßige Ablehnung des Tool-Zugriffs basierend auf der Identität zu implementieren. Richtlinien werden deklarativ ausgedrückt, nicht im Code versteckt, und in Pull-Requests wie jedes andere Infrastrukturteil überprüft:

Cedar · TrueFoundry-Richtlinie

// Frontend engineers can read staging databases.
// Nobody is granted production write access by default.
permit(
  principal == Role::"frontend-developer",
  action    == Action::"mcp:invoke-tool",
  resource  == McpServer::"staging-database"
) when {
  context.tool_name   == "read_only_query" &&
  context.environment == "staging"
};

Cedar (oder OPA, oder welche Policy-Engine auch immer Ihre Plattform standardisiert) ermöglicht es der Organisation, klar festzulegen: Frontend-Entwickler greifen auf Frontend-MCP-Tools zu, kein Agent hat Schreibzugriff auf Produktionsdatenbanken, es sei denn, ein zeitlich begrenztes Break-Glass-Verfahren wird ausgelöst. Das Gateway überprüft das JWT des Entwicklers, der Claude Code ausführt, gleicht die Anfrage mit der Richtlinie ab und blockiert unautorisierte Aufrufe auf der Netzwerkebene – lange bevor die Logik des Agenten die Datenbank erreicht. Sowohl Cedar Guardrails als auch OPA Guardrails werden in TrueFoundry als integrierte MCP-Guardrails ausgeliefert, wobei die Default-Deny-Semantik am Pre-Tool-Hook durchgesetzt wird.

Cedar vs. OPA – wann man welches wählen sollte

Tabelle 1 – Cedar vs. OPA. Beide werden als integrierte TrueFoundry-Guardrails mit Default-Deny-Semantik ausgeliefert. Cedar ist der einfachere Einstieg; OPA ist das flexiblere Langzeit-Tool. Wählen Sie das, welches Ihr Plattformteam bereit ist zu übernehmen.

Die entscheidende Semantik ist, wann diese Prüfung ausgeführt wird. Die MCP-Guardrails von TrueFoundry bieten zwei Hooks pro Tool-Aufruf: Pre Tool läuft synchron, bevor das Tool ausgeführt wird, und Post Tool läuft, nachdem es zurückkehrt. Cedar/OPA-Entscheidungen erfolgen am Pre Tool-Hook, was bedeutet, dass ein abgelehnter Aufruf niemals die Datenbank, die Cloud-API oder den internen Dienst erreicht. Die Argumentation des Agenten geht weiter; die gefährliche Aktion nicht.

Von OIDC-Claims zum Cedar-Kontext

Die Brücke zwischen Identität und Richtlinie ist unkompliziert. Der Entwickler authentifiziert sich gegenüber dem Unternehmens-IdP (Okta, Azure AD), erhält ein vom IdP signiertes JWT und präsentiert es dem Gateway bei jeder Anfrage. Das Gateway überprüft die Signatur anhand der zwischengespeicherten öffentlichen Schlüssel des IdP (kein Callback pro Anfrage an den IdP – die Schlüssel werden einmal beim Start heruntergeladen und im Prozessspeicher zwischengespeichert). Die verifizierten Claims werden dann in einen Cedar-Kontext abgebildet, den die Policy-Engine auswertet:

Ablauf · OIDC-Claims → Cedar-Kontext

‍

‍

Pro-Entwickler-Ratenbegrenzung auf der Tool-Aufruf-Ebene

Agenten-Schleifen laufen aus dem Ruder. Eine vage Eingabeaufforderung kann dazu führen, dass ein Agent ein Suchwerkzeug Hunderte Male in einer engen Schleife aufruft, interne APIs überlastet und Token in einer Geschwindigkeit verbraucht, die der Mensch vor der Tastatur niemals erzeugen würde. Die Ratenbegrenzung des Gateways ist unerlässlich – und sie muss mit der richtigen Granularität angewendet werden.

Genauer gesagt gehören Ratenbegrenzungen auf die Tool-Aufruf-Ebene, nicht auf die Prompt-Ebene. Ein Entwickler sendet vielleicht fünf Prompts pro Stunde. Der Agent könnte im Dienste dieser Prompts fünftausend Tool-Aufrufe ausführen. Begrenzen Sie nach Tool-Aufruf. Das TrueFoundry-Gateway verwendet unter der Haube einen Sliding-Window-Token-Bucket-Algorithmus – ein 60-Sekunden-Sliding-Window, das aus zwölf 5-Sekunden-Buckets besteht, die alle im Prozessspeicher jedes Gateway-Pods verwaltet werden. Limits werden über NATS über Replikate hinweg synchronisiert, und der Algorithmus bleibt stabil bis zu den dokumentierten ~250 RPS pro Single-CPU-Pod des Gateways.

Das Konfigurationsmodell verwendet statische Regel-IDs in Kombination mit `rate_limit_applies_per`, um Limits auf Entitäten zu beschränken. Ratenbegrenzungen werden in YAML ausgedrückt, versionskontrolliert und wie jede andere Richtlinie überprüfbar:

YAML · Pro-Entwickler- + Pro-Projekt-Limits

name: claude-code-rate-limits
type: gateway-rate-limiting-config
rules:
  # Each developer gets their own per-day token budget.
  - id: "user-daily-tokens"
    when: {}
    limit_to: 1_000_000
    unit: tokens_per_day
    rate_limit_applies_per: ["user"]

  # Each user-model pair gets its own minute-window cap.
  - id: "user-model-minute"
    when: {}
    limit_to: 200
    unit: requests_per_minute
    rate_limit_applies_per: ["user", "model"]

  # Each project (via X-TFY-METADATA) gets its own hourly cap.
  - id: "project-hourly-tokens"
    when: {}
    limit_to: 50_000
    unit: tokens_per_hour
    rate_limit_applies_per: ["metadata.project_id"]

Drei Dinge sind an dieser Konfiguration hervorzuheben. Erstens werden Regeln von oben nach unten ausgewertet, und die erste passende Regel gewinnt – die Reihenfolge kodiert die Priorität. Zweitens ersetzt `rate_limit_applies_per` das ältere dynamische Regel-ID-Format ({user}-daily-limit und so weiter); die Migration ist mechanisch, aber breaking und es lohnt sich, sie einmal durchzuführen. Drittens können Sie bis zu zwei Entitäten pro Regel kombinieren, sodass Limits pro Benutzer pro Modell und pro Projekt pro Umgebung ohne eine Explosion der Regeln ausgedrückt werden können.

Wenn der Bucket erschöpft ist, gibt das Gateway HTTP 429 zurück. Claude Code interpretiert dies als ein Standard-Backoff-Signal und pausiert die Schleife natürlich, anstatt die nachgeschaltete Datenbank zum Absturz zu bringen. Der Agent versucht es erneut, wenn der Bucket wieder aufgefüllt ist, was genau das gewünschte Verhalten ist.

Manipulationssichere Audit-Trails

Wenn etwas schiefgeht – ein Kostenanstieg, ein Sicherheitsvorfall, eine Frage einer Aufsichtsbehörde – benötigen Plattformteams eine forensische Aufzeichnung. Das Gateway stellt eine solche bereit, die sich außerhalb der Maschine des Entwicklers befindet und vom Benutzer nicht manipuliert werden kann. Dies ist der Teil der Architektur, der aus „wir glauben, es war Bobs Agent“ ein „es war Bobs Agent um 14:32:05 UTC, hier ist der Trace“ macht.

Ein TrueFoundry-Logeintrag enthält alles, was ein Analyst benötigt, um Ursache und Wirkung zu rekonstruieren:

Tabelle 2 – Logfelder für eine forensische Aufzeichnung. Die Trace-ID ist das Feld, das Auditoren tatsächlich interessiert – sie ermöglicht es einem Analysten, in einer einzigen Abfrage von „Entwickler fragte X“ über „Modell entschied Y“ bis zu „Tool führte Z aus“ zu navigieren.

Protokolle fließen vom Gateway in ClickHouse (mit Object-Storage-Unterstützung) und von dort in das SIEM, auf das sich die Organisation standardisiert hat. Das Gateway schreibt niemals synchron in den Protokollpfad – es veröffentlicht an NATS, und das Protokollsubsystem ist von Natur aus asynchron. Wenn die Protokollwarteschlange nicht verfügbar ist, schlägt die Anfrage am Gateway nicht fehl. Die Zuverlässigkeit des Anforderungspfads ist wichtiger als dessen Beobachtbarkeit; die Beobachtbarkeit wird wiederhergestellt, sobald die Warteschlange wieder funktioniert.

Anomalieerkennung bei Tool-Nutzungsmustern

Statische Regeln können nicht jede Bedrohung antizipieren, und die manuelle Überprüfung jeder Zeile eines Audit-Logs ist keine Skalierungsstrategie. Der Audit-Stream dient auch als Verhaltensgrundlage. Ein Entwickler, der normalerweise git-mcp und jira-mcp verwendet und plötzlich fünfzig Mal pro Sekunde auf aws-iam-mcp zugreift, ist ein Signal – möglicherweise ein kompromittierter Laptop, möglicherweise ein falsch konfigurierter Agent, definitiv einen Blick wert.

Plattformteams konfigurieren Schutzschalter (Circuit Breaker) für diese Muster. Oberhalb eines konfigurierbaren Z-Score-Schwellenwerts isoliert das Gateway den agentischen Zugriff des Entwicklers und benachrichtigt den Bereitschaftsdienst für Sicherheit. Der Entwickler arbeitet in seiner IDE weiter; seine Agenten-Schleife bleibt untätig, bis sie überprüft wurde. Die Anomalieerkennung erfolgt nach dem Audit-Log, nicht im Anforderungspfad, sodass die Latenzkosten im stabilen Zustand null sind – die Anomaliebewertung läuft auf dem aggregierten Metrik-Stream, den das Gateway bereits veröffentlicht.

Die Verhaltensweisen, die eine Warnung auslösen sollten, geordnet nach ihrer tatsächlichen Häufigkeit in realen Implementierungen, sind: plötzliche Spitzen in der Aufrufrate (feststeckender Agent), Tool-Aufrufe mit Parameterformen, die der Entwickler noch nie erzeugt hat (kompromittierte Anmeldeinformationen), Lücken von mehreren Sekunden, gefolgt von Bursts (bot-ähnliche Zugriffsmuster), und der Zugriff auf Tools außerhalb des normalen Arbeitsbereichs des Entwicklers (laterale Bewegung). Die Merkmale, die den Z-Score bestimmen, sind einfach – Aufrufe pro Minute, unterschiedliche Tools pro Stunde, Verteilung der Nutzlastgröße – und die Mathematik ist eine einfache gleitende Mittelwert- und Standardabweichungsberechnung. Komplexität schadet hier meistens; wichtig ist, dass die Warnung zuverlässig ausgelöst wird und bei einem Fehlalarm leicht stummgeschaltet werden kann.

Verknüpfung des Tool-Geltungsbereichs mit der SSO-Identität

Die strukturelle Eleganz dieser Architektur besteht darin, dass alles auf den zentralen Identitätsanbieter des Unternehmens zurückgeführt wird – Okta, Azure AD, oder was auch immer die Organisation verwendet. Die Authentifizierung erfolgt über OAuth/SAML/OIDC; das Gateway speichert die öffentlichen Schlüssel des IdP im Prozessspeicher und verifiziert jedes eingehende JWT lokal ohne externen Aufruf. Die Autorisierung ist eine Richtlinienbewertung anhand der OIDC-Claims, ebenfalls im Speicher. Es gibt keinen Callback pro Anfrage an den IdP; das Gateway ist schnell, weil all diese Prüfungen im RAM des Pods und nicht über das Netzwerk erfolgen.

Wenn ein Entwickler das Team wechselt, ändern sich seine Gruppenzugehörigkeiten im IdP. Da das Gateway Richtlinien dynamisch anhand aktueller OIDC-Claims bewertet, verliert der Claude Code des Entwicklers sofort den Zugriff auf sensible MCP-Server, ohne dass lokale Konfigurationsänderungen erforderlich sind. Das Offboarding wird zu einer einzigen IdP-Änderung. Rollenänderungen, Teamwechsel und die Beendigung von Auftragnehmerverträgen verbreiten sich auf die gleiche Weise. Das Gateway ist die Schnittstelle, an der die Unternehmensidentität auf die Agenten-Schleife trifft, und an dieser Schnittstelle wird Governance operativ handhabbar, anstatt dauerhaft ein Wunschtraum zu bleiben.

Claude Code wird in Ihrem Unternehmen zum Einsatz kommen – wenn nicht in diesem Quartal, dann im nächsten. Die Frage ist, ob es über eine Schnittstelle ausgeliefert wird, die Ihr Plattformteam kontrolliert, oder über tausend einzelne Konfigurationsdateien, die Ihr Plattformteam nicht kontrolliert. Nur eine dieser Antworten besteht ein Audit.

FAQ

Wie funktionieren Break-Glass-Verfahren für den Notfallzugriff auf die Produktion?

Dauerhafter Zugriff auf die Produktion ist die falsche Standardeinstellung; eine zeitlich begrenzte Erhöhung der Berechtigungen ist die richtige. Das in der Produktion funktionierende Muster: eine separate Cedar/OPA-Regel, die einem erfahrenen Ingenieur eine 30-minütige erhöhte Rolle gewährt, wenn er eine begründete Anfrage über einen Genehmigungsworkflow einreicht (ein Slack-Bot, ein PagerDuty-Vorfall, ein JIRA-Ticket). Die Berechtigungserhöhung wird selbst über das Gateway protokolliert, die Rolle läuft automatisch ab, und das Audit-Log erfasst sowohl die Anfrage als auch die darunter ausgeführten Aktionen. Das Gateway verfügt über keinen speziellen Break-Glass-Code – es ist derselbe JWT-Claim-zu-Cedar-Kontext-Fluss, nur mit einer anderen Rolle und einer vom IdP erzwungenen Ablaufzeit.

Was passiert, wenn ein Entwickler einer Richtlinienentscheidung im Moment widerspricht?

Das Gateway gibt einen strukturierten 403-Fehler mit der Regel-ID zurück, die den Aufruf verweigert hat. Diese Regel-ID ist der Ausgangspunkt für eine Diskussion: Sie verweist auf die Cedar/OPA-Datei im Plattform-Repository, die in einem normalen Pull Request überprüft werden kann. Wenn die Richtlinie falsch ist, ist die Korrektur ein PR. Wenn die Richtlinie korrekt ist, hat der Entwickler den Nachweis, den er benötigt, um über einen separaten Kanal eine Ausnahme zu beantragen. Es gibt absichtlich keinen entwicklerseitigen Überschreibschalter – dieser Schalter ist genau das, was das Gateway eliminieren soll.

Wie interagiert dies mit den eigenen Berechtigungsaufforderungen von Claude Code?

Die lokalen Berechtigungsaufforderungen von Claude Code sind nützlich für die Benutzerfreundlichkeit, stellen aber keine Sicherheitsgrenze dar – sie befinden sich auf dem Rechner des Entwicklers und können deaktiviert oder automatisch akzeptiert werden. Das Gateway sitzt unterhalb dieser Aufforderungen und steuert den tatsächlichen Tool-Aufruf. Die beiden Schichten ergänzen sich: Aufforderungen geben dem Entwickler eine Plausibilitätsprüfung; das Gateway gibt der Organisation eine Richtlinie. Betrachten Sie die Aufforderungen als Defense-in-Depth, nicht als tragende Schicht.

Wie halten Sie Richtlinien wartbar, wenn die Organisation wächst?

Richtlinien sollten die IdP-Gruppenstruktur widerspiegeln, anstatt jedes (Benutzer, Tool)-Paar aufzulisten. Gruppieren Sie Entwickler in Rollen im IdP – Frontend-Entwickler, Backend-Entwickler, SRE, Auftragnehmer – und schreiben Sie Richtlinien gegen diese Rollen. Neue Mitarbeiter erben den Zugriff am ersten Tag durch ihre Gruppenzugehörigkeit; das Offboarding ist eine IdP-Bearbeitung. Die Anzahl der Richtlinienregeln sollte mit der Anzahl der MCP-Server-/Tool-Kategorien wachsen, nicht mit der Anzahl der Entwickler.

Ist das Gateway ein Single Point of Failure?

Es befindet sich im Anforderungspfad, daher ist die Entwicklung für Hochverfügbarkeit nicht optional. Die Gateway-Ebene ist zustandslos, läuft als mehrere Replikate und dient weiterhin mit der zuletzt bekannten Konfiguration, falls die Steuerungsebene kurzzeitig unerreichbar ist. Neue Konfigurationen werden über NATS abgeglichen und alle 10 Minuten vollständig neu veröffentlicht, als Sicherheitsnetz. In Produktionsumgebungen sollten mindestens drei Gateway-Replikate über Verfügbarkeitszonen hinweg betrieben und hinter einem normalen HTTP-Lastverteiler platziert werden; der Ausfallmodus, gegen den Sie entwickeln müssen, ist „ein Pod startet während eines Ausfalls der Steuerungsebene neu“, nicht „alle Pods starten gleichzeitig neu“, was selten genug ist, um akzeptabel zu sein.

‍