Claude Code beheren in de onderneming: MCP Tool Scoping en Audit Trails

Claude Code is een productiviteitsvermenigvuldiger én een tekortkoming in governance binnen dezelfde installatie. Met 200 ontwikkelaars en geen centraal controlepunt kan elk van hen elke backend bereiken die hun agent besluit te gebruiken. De gateway is de plek waar die kloof wordt gedicht.

Claude Code heeft geen native enterprise-besturingselementen

Claude Code levert een aanzienlijke productiviteitswinst op. Het leest codebases, voert tests uit, raadpleegt databases en lost zelfstandig meerstaps engineeringtaken op. Die capaciteit is precies wat het beveiligingsmodel oncomfortabel maakt. De agent is geen externe service die af en toe een beurt neemt; het is een autonome loop die op de laptop van een ontwikkelaar draait met alle credentials die vanaf die laptop bereikbaar zijn.

Van nature heeft Claude Code geen begrip van enterprise governance. Geef het een MCP server-configuratie en het gaat uit van totale autoriteit over elke tool die die server beschikbaar stelt. Zet een postgres-mcp-server op zodat agents stagingdata kunnen bevragen, en er is geen ingebouwd mechanisme om te voorkomen dat een overmoedige agent — of een gecompromitteerd eindpunt van een ontwikkelaar — DROP TABLE uitvoert als de onderliggende credentials dat toestaan. Lokale configuratiebestanden die ontwikkelaars vragen zich verantwoordelijk te gedragen zijn niet het antwoord; ze zijn het ontbreken daarvan.

De juiste manier om hierover na te denken: de mens die toezicht hield op de loop was voorheen de rate limiter, de policy engine én het audit logboek tegelijk. De agent haalt de mens uit het pad per actie. Welke guardrails mensen ook impliciet boden, moeten nu expliciet worden gereconstrueerd — en de enige plek om ze te plaatsen is stroomopwaarts van de agent, op het netwerk, waar één team ze kan beheren.

Wat er misgaat zonder een gateway

Het dreigingsmodel is een te brede bereikbaarheid gecombineerd met de onvoorspelbaarheid van agents. Drie faalmodi doen zich voor in productie binnen de eerste maand van elke serieuze Claude Code-uitrol.

Doelgerichte overschrijding. Een ontwikkelaar verbindt Claude Code met het interne netwerk om "de bug in de gebruikersauthenticatie-flow" te debuggen. De agent, redenerend door het probleem, besluit dat hij echte gebruikersdata moet zien om de bug te reproduceren. Hij pakt een kubernetes-mcp-server, maakt een port-forward naar een productiedatabase, extraheert PII en plakt een samenvatting in de lokale terminal — of stuurt het naar de provider als onderdeel van de volgende prompt. Dit is geen kwaadwillig gedrag. Het is een agent die zijn doel vervult met behulp van de meest permissieve tool die beschikbaar is.

Per ongeluk toegebrachte schade. De agent probeert een Terraform-module te repareren door deze toe te passen. Hij probeert een verkeerd geconfigureerde branch op te schonen door deze te verwijderen. Hij voert een databasemigratie uit om te verifiëren of het nieuwe schema werkt. Elke individuele stap lijkt lokaal rationeel; het globale resultaat is een productie-incident.

SSRF via de agent. De agent pakt een netwerktool om een integratie te verifiëren. De agent leest een manipulated (poisoned) toolbeschrijving die suggereert dat een bepaalde host canoniek is. De agent haalt die host op, die zich toevallig in de cloud metadata service bevindt. Credentials lekken. De gebruiker is zich er niet van bewust dat dit allemaal is gebeurd — de agent rapporteerde simpelweg succes bij zijn taak.

Zonder een centraal controlepunt is elk van deze scenario's standaard mogelijk. Met een controlepunt is elk ervan een configuratiebeslissing.

‍

‍

MCP tool-toegang scopen per team en omgeving

De mitigerende maatregel is het implementeren van een gateway tussen Claude Code en interne MCP servers, en het uitvoeren van default-deny tool scoping op basis van identiteit. Beleid wordt declaratief uitgedrukt, niet begraven in code, en beoordeeld in pull requests zoals elk ander onderdeel van de infrastructuur:

Cedar · TrueFoundry-beleid

Met Cedar (of OPA, of de policy engine waarop jouw platform standaardiseert) kan de organisatie duidelijk vastleggen: frontend engineers bereiken frontend MCP tools, geen enkele agent heeft schrijftoegang tot productiedatabases tenzij een tijdgebonden break-glass-procedure wordt ingeroepen. De gateway inspecteert het JWT van de ontwikkelaar die Claude Code uitvoert, vergelijkt het verzoek met het beleid en blokkeert onbevoegde calls op de netwerklaag — lang voordat de redenering van de agent de database bereikt. Zowel Cedar Guardrails als OPA Guardrails worden in TrueFoundry geleverd als ingebouwde MCP guardrails, met default-deny semantiek die wordt afgedwongen bij de Pre Tool hook.

Cedar vs OPA — wanneer kies je welke

Tabel 1 — Cedar vs OPA. Beide worden geleverd als ingebouwde TrueFoundry guardrails met default-deny semantiek. Cedar is de eenvoudigste instap; OPA is de flexibelere tool voor de lange termijn. Kies de optie die jouw platformteam wil beheren.

De semantiek die er toe doet is wanneer deze controle draait. TrueFoundry's MCP guardrails bieden twee hooks per tool call: Pre Tool draait synchroon voordat de tool wordt uitgevoerd, en Post Tool draait nadat deze resultaat teruggeeft. Cedar/OPA-beslissingen bevinden zich bij de Pre Tool hook, wat betekent dat een geweigerde call de database, de cloud-API of de interne service nooit bereikt. De redenering van de agent gaat door; de gevaarlijke actie niet.

Van OIDC claims naar Cedar-context

De brug tussen identiteit en beleid is eenvoudig. De ontwikkelaar authenticeert bij de enterprise IdP (Okta, Azure AD), ontvangt een JWT ondertekend door de IdP en presenteert dit bij elk verzoek aan de gateway. De gateway verifieert de handtekening aan de hand van de gecachte publieke sleutels van de IdP (geen callback per verzoek naar de IdP — de sleutels worden eenmalig gedownload bij het opstarten en gecacht in het procesgeheugen). De geverifieerde claims worden vervolgens gemapped naar een Cedar-context die de policy engine evalueert:

flow · OIDC claims → Cedar-context

‍

‍

Rate limiting per ontwikkelaar op de tool-call-laag

Agentic loops kunnen op hol slaan. Een vage prompt kan ervoor zorgen dat een agent een zoek-tool honderden keren aanroept in een strakke loop, wat interne API's overbelast en tokens verbruikt in een tempo dat de mens voor het toetsenbord nooit zou genereren. Gateway rate limiting is essentieel — en het moet op de juiste granulariteit worden toegepast.

Specifiek horen rate limits thuis op de tool-call-laag, niet op de prompt-laag. Een ontwikkelaar stuurt misschien vijf prompts per uur. De agent voert mogelijk vijfduizend tool calls uit ter ondersteuning van die prompts. Limiteer per tool call. De TrueFoundry gateway gebruikt op de achtergrond een sliding-window token-bucket algoritme — een sliding window van 60 seconden opgebouwd uit twaalf buckets van 5 seconden, allemaal bijgehouden in het procesgeheugen op elke gateway pod. Limieten worden gesynchroniseerd over replica's via NATS, en het algoritme blijft stabiel tot de gedocumenteerde ~250 RPS van de gateway per single-CPU pod.

Het configuratiemodel gebruikt statische regel-ID's gecombineerd met rate_limit_applies_per om limieten af te bakenen tot entiteiten. Rate limits worden uitgedrukt in YAML, staan onder versiebeheer en zijn net als elk ander beleid te reviewen:

YAML · limieten per ontwikkelaar + per project

Drie dingen zijn het vermelden waard over deze configuratie. Ten eerste worden regels van boven naar beneden geëvalueerd en de eerste overeenkomende regel wint — de volgorde bepaalt de prioriteit. Ten tweede vervangt rate_limit_applies_per het oudere dynamische regel-ID-formaat ({user}-daily-limit enzovoort); migratie is mechanisch maar breaking, en de moeite waard om eenmalig uit te voeren. Ten derde kun je tot twee entiteiten per regel combineren, zodat limieten per gebruiker per model én per project per omgeving beide kunnen worden uitgedrukt zonder dat het aantal regels explodeert.

Wanneer de bucket leeg is, retourneert de gateway HTTP 429. Claude Code leest dat als een standaard backoff-signaal en pauzeert de loop van nature, in plaats van dat de stroomafwaartse database crasht. De agent probeert het opnieuw wanneer de bucket weer is gevuld, wat precies het gedrag is dat je wilt.

Knoeibestendige audit trails

Wanneer er iets misgaat — een kostenpiek, een beveiligingsincident, een vraag van een toezichthouder — hebben platformteams een forensisch dossier nodig. De gateway biedt er een, extern aan de machine van de ontwikkelaar en onmogelijk door de gebruiker te wijzigen. Dit is het deel van de architectuur dat "we denken dat het de agent van Bob was" verandert in "het was de agent van Bob om 14:32:05 UTC, hier is de trace."

Een TrueFoundry-logregel bevat alles wat een analist nodig heeft om oorzaak en gevolg te reconstrueren:

Tabel 2 — Logvelden voor een forensisch dossier. Het trace ID is het veld waar auditors daadwerkelijk om geven — dit stelt een analist in staat om binnen één query te navigeren van "ontwikkelaar vroeg X" via "model besloot Y" naar "tool voerde Z uit".

Logs stromen van de gateway naar ClickHouse (met object-storage backing) en van daaruit naar de SIEM waar de organisatie op standaardiseert. De gateway schrijft nooit synchroon naar het logpad — hij publiceert naar NATS, en het logsubsysteem is by design asynchroon. Als de log-queue uitvalt, laat de gateway het verzoek niet mislukken. Betrouwbaarheid van het verzoekpad gaat boven de observabiliteit van het verzoekpad; observabiliteit wordt hersteld wanneer de queue weer online is.

Anomaliedetectie op patroon van toolgebruik

Statische regels kunnen niet elke dreiging voorzien, en het menselijk controleren van elke regel in het audit logboek is geen schaalbare strategie. De auditstream dient ook als een gedragsbaseline. Een ontwikkelaar die normaal gesproken git-mcp en jira-mcp gebruikt en plotseling aws-iam-mcp vijftig keer per seconde begint aan te roepen geeft een signaal af — mogelijk een gecompromitteerde laptop, mogelijk een verkeerd geconfigureerde agent, in ieder geval de moeite waard om te bekijken.

Platformteams configureren circuit breakers op deze patronen. Boven een configureerbare z-score drempelwaarde isoleert de gateway de agentic toegang van de ontwikkelaar en roept de dienstdoende security responder op. De ontwikkelaar blijft werken in zijn IDE; zijn agent-loop blijft inactief totdat deze is beoordeeld. Anomaliedetectie bevindt zich stroomafwaarts van het audit logboek, niet in het verzoekpad, dus de latentiekosten in normale staat zijn nul — de anomalie-evaluatie draait op de geaggregeerde metriekenstream die de gateway al publiceert.

De gedragingen die een waarschuwing waard zijn, gerangschikt op hoe vaak ze daadwerkelijk afgaan in echte uitrollen, zijn: plotselinge pieken in de aanroepsnelheid (agent die vastzit in een loop), tool calls met parameterstructuren die de ontwikkelaar nog nooit heeft gegenereerd (gecompromitteerde credentials), pauzes van meerdere seconden gevolgd door piekuitbarstingen (bot-achtige toegangspatronen), en toegang tot tools buiten de normale werkcontext van de ontwikkelaar (laterale verplaatsing). De kenmerken die de z-score aansturen zijn eenvoudig — aanroepen-per-minuut, unieke-tools-per-uur, payload-grootte-verdeling — en de wiskunde is een eenvoudig voortschrijdend gemiddelde en standaarddeviatie (rolling-window mean-and-stddev). Te veel complexiteit werkt hier meestal tegen je; het gaat erom dat de waarschuwing betrouwbaar afgaat en eenvoudig te onderdrukken is bij een vals-positief resultaat.

Koppeling van tool-scope aan SSO-identiteit

De structurele elegantie van deze architectuur is dat alles terugleidt naar de enterprise identity provider — Okta, Azure AD, wat de organisatie ook gebruikt. Authenticatie is OAuth/SAML/OIDC; de gateway cacht de publieke sleutels van de IdP in het procesgeheugen en verifieert elk inkomend JWT lokaal zonder een externe call. Autorisatie is beleidsevaluatie tegen de OIDC-claims, eveneens in het geheugen. Er is geen callback per verzoek naar de IdP; de gateway is snel omdat al deze controles plaatsvinden in het RAM van de pod, niet over het netwerk.

Wanneer een ontwikkelaar van team verandert, wijzigen de groepslidmaatschappen in de IdP. Omdat de gateway beleidsregels dynamisch evalueert tegen verse OIDC-claims, verliest de Claude Code van de ontwikkelaar onmiddellijk toegang tot gevoelige MCP servers, met nul lokale configuratiewijzigingen. Deactivatie wordt een enkele aanpassing in de IdP. Rolwijzigingen, overstappen naar andere teams en het beëindigen van contractor-contracten worden op dezelfde manier doorgevoerd. De gateway is de naad waar bedrijfsidentiteit de agent-loop ontmoet, en die naad is waar governance operationeel haalbaar wordt in plaats van permanent een streven te blijven.

Claude Code wordt binnenkort uitgerold in jouw onderneming — zo niet dit kwartaal, dan het volgende. De vraag is of dit gebeurt via een naad die jouw platformteam beheert, of via duizend individuele configuratiebestanden die jouw platformteam niet beheert. Er is slechts één van die antwoorden die een audit overleeft.

Veelgestelde vragen (FAQ)

Hoe werken break-glass-procedures voor noodtoegang tot productie?

Permanente toegang tot productie is de verkeerde standaardinstelling; tijdgebonden verhoging van rechten is de juiste. Het patroon dat werkt in productie: een afzonderlijke Cedar/OPA-regel die een senior engineer een verhoogde rol geeft voor 30 minuten wanneer deze een gemotiveerd verzoek indient via een goedkeuringsworkflow (een Slack-bot, een PagerDuty-incident, een JIRA-ticket). De verhoging zelf wordt gelogd via de gateway, de rol verloopt automatisch en de audit log legt zowel het verzoek als de acties die eronder zijn uitgevoerd vast. De gateway bevat geen speciale break-glass-code — het is dezelfde stroom van JWT-claim naar Cedar-context, alleen met een andere rol en een verlooptijd die door de IdP wordt afgedwongen.

Wat als een ontwikkelaar het op dat moment niet eens is met een beleidsbeslissing?

De gateway retourneert een gestructureerde 403-foutmelding met het regel-ID dat de call heeft geweigerd. Dat regel-ID is het adres van een gesprek: het verwijst naar het Cedar/OPA-bestand in de platform-repository, dat in een normaal pull request kan worden beoordeeld. Als het beleid onjuist is, is de oplossing een PR. Als het beleid juist is, heeft de ontwikkelaar het bewijs dat nodig is om via een afzonderlijk kanaal een uitzondering aan te vragen. Er is bewust geen knop voor de ontwikkelaar om dit te omzeilen — die knop is immers precies wat de gateway hoort te verwijderen.

Hoe verhoudt dit zich tot de eigen permissieprompts van Claude Code?

De lokale permissieprompts van Claude Code zijn nuttig voor de gebruikerservaring, maar vormen geen beveiligingsgrens — ze bevinden zich op de machine van de ontwikkelaar en kunnen worden uitgeschakeld of automatisch worden geaccepteerd. De gateway bevindt zich onder die prompts en controleert de daadwerkelijke uitvoering van de tool. De twee lagen vullen elkaar aan: prompts bieden de ontwikkelaar een controlepunt; de gateway biedt de organisatie beleid. Zie de prompts als defense-in-depth, niet als de drager van de beveiliging.

Hoe houd je beleidsregels onderhoudbaar naarmate de organisatie groeit?

Beleidsregels moeten de groepsstructuur van de IdP weerspiegelen in plaats van elk paar van (gebruiker, tool) op te sommen. Groepeer ontwikkelaars in rollen binnen de IdP — frontend-developer, backend-developer, sre, contractor — en schrijf beleidsregels op basis van die rollen. Nieuwe medewerkers krijgen vanaf dag één toegang via hun groepslidmaatschap; deactivatie is één aanpassing in de IdP. Het aantal beleidsregels moet meegroeien met het aantal categorieën MCP-servers / tools, niet met het aantal ontwikkelaars.

Is de gateway een single point of failure?

De gateway bevindt zich in het verzoekpad, dus het ontwerpen op hoge beschikbaarheid is niet optioneel. Het gateway-vlak is stateless, draait in meerdere replica's en blijft verzoeken verwerken op basis van de laatst bekende configuratie als het control plane tijdelijk onbereikbaar is. Nieuwe configuratie wordt gesynchroniseerd via NATS en elke 10 minuten als veiligheidsnet opnieuw volledig gepubliceerd. Draai in productieomgevingen ten minste drie gateway-replica's verspreid over availability zones en plaats ze achter een normale HTTP load balancer; de faalmodus waarvoor je moet ontwerpen is "één pod herstart tijdens een storing in het control plane", niet "alle pods herstarten gelijktijdig", wat zeldzaam genoeg is om acceptabel te zijn.

‍