Enterprise MCP Governance: beheer, controleer en beveilig MCP Server-toegang op schaal

Vraag uw beveiligingsteam hoeveel MCP servers er op dit moment binnen uw organisatie draaien. Als ze dat met zekerheid kunnen beantwoorden, loopt u voor op de meeste ondernemingen. Als ze dat niet kunnen, hebt u een governanceprobleem dat al in productie is.

De adoptie van MCP is snel gegaan. Teams hebben agents verbonden met GitHub, Slack, interne databases en API's van derden via MCP servers, vaak zonder IT-beoordeling, zonder beleid voor authenticatiegegevens en zonder enige mogelijkheid voor het beveiligingsteam om te zien waartoe die servers toegang hadden. Het protocol is juist nuttig omdat het gereedschapsverbindingen eenvoudig maakt. Die eenvoud is ook precies wat niet-beheerde MCP-implementaties tot een echt beveiligingsrisico maakt.

MCP servers zijn geen passieve API's. Ze geven AI-agents directe, programmatische toegang tot gevoelige systemen. Die agents handelen op basis van autonoom redeneren, niet op basis van beoordeelde codepaden. Zoals een leider op het gebied van enterprise security bij Medtronic het verwoordde: "MCP biedt enorm veel mogelijkheden om erg snel heel veel schade aan te richten." Gartner voorspelt dat 70% van de software engineeringteams die multimodale toepassingen bouwen tegen 2028 gebruik zal maken van AI gateways, vergeleken met 25% in 2025. De teams die nu governance opbouwen, zijn de teams die veilig kunnen schalen.

Deze gids behandelt wat enterprise MCP governance vereist, waarom standaard beveiligingstools tekortschieten, hoe u het framework van vier pijlers bouwt waarop complianceteams kunnen vertrouwen, en hoe TrueFoundry dit alles implementeert binnen uw eigen cloud.

Wat Enterprise MCP Governance vereist

Enterprise MCP governance is het volledige operationele kader voor het beheren van welke MCP servers in uw organisatie bestaan, wie er toegang toe heeft, wat ze mogen doen en wat er wordt vastgelegd wanneer ze worden gebruikt. Het is geen beleidsdocument. Het is afgedwongen infrastructuur.

De meeste teams onderschatten de omvang. Governance omvat elke MCP server in de omgeving: tools van derden die ontwikkelaars hebben verbonden zonder IT-beoordeling, interne tools die productteams hebben gebouwd en geïmplementeerd, en MCP servers die zijn ingebed in IDE-configuraties in Cursor, Claude Code en soortgelijke tools. Als een MCP server een productiesysteem kan bereiken, valt deze binnen de scope.

MCP governance verschilt ook van standaard API-governance op een manier die van belang is voor de manier waarop u het opbouwt. Een REST API-call voert een deterministisch codepad uit dat door een ontwikkelaar is geschreven en beoordeeld. Een MCP tool-aanroep is een autonome beslissing die runtime door een AI-agent wordt genomen op basis van zijn redenering. Het dreigingsmodel, de auditvereisten en de controles die nodig zijn om verantwoording te handhaven zijn allemaal anders. Het behandelen van MCP als een conventionele API-integratie is de manier waarop organisaties eindigen met auditgaten die ze niet kunnen uitleggen aan een toezichthouder.

• Scope: Alle MCP servers. Dit omvat interne servers gebouwd door productteams, servers die draaien in CI/CD-pipelines en alles wat een ontwikkelaar lokaal in zijn IDE heeft geconfigureerd.

• Mechanisme: Een gecentraliseerde gateway tussen alle clients en alle MCP servers. De gateway dwingt beleid af. Individuele MCP servers implementeren hun eigen toegangscontroles niet, wat deze aanpak schaalbaar maakt over honderden servers.

• Resultaat: Elke tool-aanroep wordt geautoriseerd tegen een geverifieerde identiteit en gelogd in een gestructureerde, doorzoekbare indeling die bestand is tegen compliancebeoordeling en incidentenonderzoek.

MCP-beveiligingsrisico's die bedrijven niet kunnen negeren

MCP servers werken binnen de redeneerlus van een AI-agent. Een traditionele API-call wordt deterministisch geactiveerd door applicatiecode. Een MCP tool-aanroep daarentegen wordt geactiveerd wanneer een agent runtime bepaalt dat een tool geschikt is voor een bepaalde taak. Die beslissing wordt beïnvloed door het redeneren van het model in plaats van een expliciet gedefinieerde controlestroom, wat de zichtbaarheid vermindert die ontwikkelaars doorgaans hebben in hoe en waarom een tool wordt aangeroepen. In dit model wordt redeneren effectief onderdeel van het controlepad, maar het is niet direct waarneembaar via standaard applicatiebeveiligingstools.

Beveiligingsonderzoekers hebben dit in productie gedocumenteerd. Prompt injection-aanvallen die worden geleverd via MCP tool-beschrijvingen sturen agentgedrag om zonder een regel code aan te raken. Blootstelling van authenticatiegegevens via slecht geconfigureerde MCP servers creëert toegangspaden die perimetercontroles nooit waren ontworpen om te monitoren. Dit zijn geen theoretische aanvalsscenario's uit onderzoeksartikelen. Het zijn gedocumenteerde incidenten uit echte enterprise-implementaties.

Schaduw-MCP-serverimplementaties kunnen standaard toegangscontrole omzeilen

Wanneer ontwikkelaars MCP servers implementeren of ermee verbinden zonder IT-beoordeling, slaan ze elke controle over die normaal van toepassing is op een nieuwe systeemintegratie: beveiligingsbeoordeling van leveranciers, classificatie van gegevenstoegang en workflows voor toegangsverlening. De server komt in productie zonder de documentatie, monitoring of beperkingen die elk ander enterprise-systeem met zich meebrengt.

Zonder een centraal register hebben fundamentele beveiligingsvragen geen betrouwbare antwoorden. Welke MCP servers draaien er? Welke authenticatiegegevens bezitten ze? Welke databases kunnen ze bevragen? Welke externe diensten kunnen ze aanroepen? Die onzichtbaarheid houdt deze servers volledig buiten kwetsbaarheidsbeoordelingen, risicobeoordelingen van leveranciers en penetratietests.

Een enkele niet-goedgekeurde MCP server met leestoegang tot een intern CRM of coderepository is een niet-gecontroleerd gegevenspad dat perimetercontroles niet zullen opmerken. Het verkeer is afkomstig van binnen het netwerk, van een ontwikkelaarsmachine die daar hoort te zijn.

Vergiftiging van tool-beschrijvingen omzeilt verdedigingslinies op netwerkniveau

Wanneer een agent verbinding maakt met een MCP server en tools/list aanroept, reageert de server met tool-namen, beschrijvingen en parameterschema's. De agent gebruikt die metadata om te beslissen welke tools moeten worden aangeroepen en hoe ze moeten worden aangeroepen. Manipuleer die metadata en u stuurt het gedrag van de agent om zonder enige codekwetsbaarheid te misbruiken.

Vergiftiging van tool-beschrijvingen sluit kwaadaardige instructies in binnen tool-metadata die ervoor zorgen dat de agent onbedoelde acties onderneemt: gegevens exfiltreren, tools aanroepen buiten de bedoelde scope, of veiligheidscontroles omzeilen terwijl hij zijn toegewezen taak lijkt uit te voeren. De kwaadaardige inhoud reist binnen de HTTP-responsbody van de MCP server, specifiek binnen de tools/list-payload. Standaard web application firewalls en API-beveiligingstools hebben zicht op HTTP-responsbodies, maar ze kunnen deze aanval niet opvangen omdat de kwaadaardige inhoud semantisch ingebedde natuurlijke taal is, geen syntactische anomalie zoals een bekende exploit-handtekening of een misvormde header. De aanval slaagt op de redeneerlaag, waar de agent tool-beschrijvingen interpreteert als legitieme instructies en daarnaar handelt.

TrueFoundry's MCP Pre Tool guardrails inspecteren tool-parameters en call-argumenten vóór de uitvoering met behulp van modelgebaseerde Prompt Injection-detectie. Als argumenten van de tool-aanroep omgeleide instructies bevatten, wordt de uitvoering geblokkeerd voordat de tool draait en wordt de detectie gelogd in de request trace.

Gedeelde MCP Server-authenticatiegegevens elimineren compliance-verantwoording

MCP servers die gedeelde API-sleutels of service account tokens gebruiken, kunnen geen toewijsbare auditrecords produceren die compliance-frameworks vereisen. Als tien agents één set authenticatiegegevens delen, is er geen manier om een specifieke tool-call te koppelen aan een specifieke gebruiker, agentinstantie of team. In een gereguleerde omgeving is dat gat geen ongemak. Het is een direct compliance-tekortkoming.

HIPAA vereist audittrails die kunnen worden toegeschreven aan een identificeerbare gebruiker of dienst voor elke toegang tot beschermde gezondheidsinformatie. SOC2 CC6 vereist toegangscontroles met bewijs van handhaving. Het verantwoordelijkheidsbeginsel van de GDPR/AVG vereist dat organisaties aantonen dat gegevensverwerking geautoriseerd en gedocumenteerd was. MCP-implementaties met gedeelde authenticatiegegevens kunnen aan geen van deze eisen voldoen. TrueFoundry vervangt gedeelde authenticatiegegevens door Personal Access Tokens gekoppeld aan individuele gebruikers en Virtual Account Tokens voor toegang op applicatieniveau, zodat elke tool-call een verifieerbare identiteit draagt.

De vier pijlers van Enterprise MCP Governance

Een compleet enterprise MCP governance-framework vereist vier functionaliteiten die samenwerken: een gecentraliseerde catalogus, op identiteit gebaseerde toegangscontroles, gestructureerde auditlogging en realtime beleidshandhaving. Elk is afhankelijk van de andere. U kunt geen toegangsbeleid afdwingen voordat u weet welke servers er bestaan. U kunt geen audittrail bouwen zonder identiteitstoewijzing. En achteraf opgestelde auditlogs zonder realtime handhaving zijn forensische records, geen beveiligingscontroles.

Vier pijlers: kernfunctie, TrueFoundry-implementatie en compliance-dekking

Pijler 1: Een gecentraliseerde MCP Server-catalogus

De catalogus is het gezaghebbende register van elke goedgekeurde MCP server in uw organisatie. Elke vermelding bevat de informatie die beveiligingsteams nodig hebben om risico's te beoordelen: servernaam, eigenaarsteam, scope van gegevenstoegang, authenticatiemethode, goedkeuringsstatus, verbindingsparameters en eventuele gebruiksbeperkingen zoals goedgekeurde gebruikersgroepen of rate limits.

Nieuwe servers komen binnen via een screening-workflow. Beoordeling van tool-beschrijvingen controleert op vergiftigingsrisico's voordat de server de ontwikkelomgevingen bereikt. Beoordeling van gegevenstoegang bepaalt wat de server kan bereiken. Een expliciete goedkeuringsondertekening regelt de distributie. Niets hiervan vereist wijzigingen aan de MCP server zelf. Het gebeurt op de cataloguslaag, en individuele serverimplementaties blijven ongewijzigd.

De catalogus verwerkt ook de distributie. Ontwikkelaars halen vooraf goedgekeurde serverconfiguraties rechtstreeks naar hun IDE-integraties in plaats van servers handmatig te configureren. Alleen door de catalogus goedgekeurde servers bereiken de machines van ontwikkelaars. TrueFoundry's Virtual MCP Server-functie breidt dit uit: platformteams stellen gecureerde subsets van tools samen uit meerdere geregistreerde servers, waarbij alleen wordt blootgesteld wat een specifiek team of use-case vereist, zonder nieuwe infrastructuur te implementeren.

Pijler 2: SSO en MCP Server-toegangscontrole op de gatewaylaag

MCP-toegang moet via dezelfde identity provider verlopen die al het andere in de organisatie beheert. TrueFoundry ondersteunt OAuth2 two-legged en three-legged flows, SAML 2.0 en directe integratie met Okta, Azure Active Directory, Auth0, Cognito en elke IdP die compatibel is met JWKS. MCP-toegang wordt toegewezen en ingetrokken via dezelfde onboarding- en offboardingworkflows die e-mail, repositories en cloudconsoles dekken. Wanneer een ontwikkelaar vertrekt, vervalt de MCP-toegang automatisch mee.

De gateway ondersteunt drie inkomende authenticatiemethoden, afhankelijk van wie er aanroept. Personal Access Tokens (PAT's) worden gegenereerd via Settings > API Keys in de TrueFoundry UI, gekoppeld aan individuele gebruikers, en zijn de standaardkeuze voor ontwikkelingsworkflows. Virtual Account Tokens (VAT's) zijn service accounts met gedefinieerde rechten, geschikt voor productie-agents en server-to-server workflows. External IdP tokens stellen gebruikers zonder TrueFoundry-account in staat zich te authenticeren met hun eigen identity provider, wat B2B SaaS en klantgerichte agent-implementaties dekt.

Voor uitgaande authenticatie naar downstream MCP servers beheert TrueFoundry de volledige levenscyclus van authenticatiegegevens over zes patronen. OAuth Authorization Code-flows verwerken toegang per gebruiker tot diensten zoals GitHub en Slack, waarbij de gateway toestemming, tokenopslag en automatische vernieuwing beheert. OAuth Client Credentials-flows verwerken server-to-server toegang. Gedeelde en individuele API-sleutelmodi dekken eenvoudigere gevallen waarin de gateway het juiste authenticatiegegeven per verzoek invoegt. Token Passthrough stuurt het inkomende token ongewijzigd door wanneer de MCP server het rechtstreeks kan valideren. Token Forwarding via de header x-tfy-mcp-headers verwerkt scenario's waarin de MCP server een afzonderlijk authenticatiesysteem gebruikt.

MCP Server-toegangscontrole: authenticatiepatronen in veelvoorkomende enterprise-scenario's

RBAC-beleid bepaalt welke teams of individuen welke servers en tools kunnen aanroepen. Dit beleid bevindt zich op de gateway, niet binnen individuele MCP servers, dus een beleidsupdate wordt onmiddellijk van kracht op alle clients zonder dat servers opnieuw hoeven te worden geïmplementeerd. Een data science-team krijgt toegang tot analysetools, maar niet tot implementatieservers. Een beveiligingsteam krijgt alleen-lezen toegang tot alle servers voor auditdoeleinden.

Pijler 3: Gestructureerde auditlogging gekoppeld aan elke tool-call

Elke MCP tool-call moet een logvermelding hebben die de volledige aanroepcontext vastlegt: timestamp, identiteit van de aanroeper, MCP server-ID, tool-naam, invoerparameters, samenvatting van de respons, beleidsbeslissing met reden, guardrail-resultaten per hook met uitvoeringstijd en bevindingen, en totale latentie. Deze velden moeten gestructureerde JSON zijn, zodat SIEM-systemen en compliance-rapportagetools ze kunnen bevragen.

TrueFoundry regelt logging op twee niveaus. Op verzoekniveau legt de X-TFY-LOGGING-CONFIG header met enabled: true het volledige verzoek vast. Op gatewayniveau bij self-hosted implementaties stelt de omgevingsvariabele REQUEST_LOGGING_MODE het globale gedrag in: ALWAYS logt elk verzoek, ongeacht headers, wat de juiste instelling is voor gereguleerde productieomgevingen. HEADER_CONTROLLED wijkt uit naar instellingen per verzoek. NEVER onderdrukt alle logging voor omgevingen waar dat passend is.

Verzoeklogs zijn zichtbaar in de TrueFoundry UI onder AI Gateway > Monitor > Requests. Individuele uitvoeringssporen van guardrails verschijnen in AI Gateway > Monitor > Request Traces, waar te zien is welke guardrails op welke hook zijn uitgevoerd, de geslaagd/mislukt-status, uitvoeringstijd en toegepaste mutaties. Voor organisaties die logs naar hun eigen infrastructuur routeren, meent TrueFoundry de export via OpenTelemetry naar Grafana, Datadog, Splunk en elke bestemming die compatibel is met OTLP. Bij self-hosted implementaties worden loggegevens geschreven naar uw eigen AWS S3, GCS of Azure Blob-opslag in Parquet-indeling, doorzoekbaar via Spark, DuckDB of Athena.

HIPAA vereist het bewaren van beveiligingsgerelateerde documentatie gedurende zes jaar. In de praktijk worden auditlogs vaak voor een vergelijkbare duur bewaard om compliance en incidentenonderzoek te ondersteunen. Veel financiële records volgen een bewaartermijn van zeven jaar. Logs moeten onbetwistbaar zijn, met toegangscontroles die wijziging door de teams die ze genereren voorkomen. TrueFoundry’s opties voor self-hosted implementatie houden alle loggegevens binnen het cloudaccount van de klant, wat zowel bewaar- als onbetwistbaarheidsvereisten ondersteunt.

Pijler 4: Realtime MCP-beleidshandhaving voordat de tool draait

Het loggen van wat er is gebeurd is niet hetzelfde als het voorkomen ervan. Beleidshandhaving moet handelen op het moment van aanroepen, voordat de tool-call de MCP server bereikt, zodat ongeautoriseerde toegang wordt geblokkeerd in plaats van achteraf gedocumenteerd.

Het guardrail-systeem van TrueFoundry implementeert twee hooks per tool-call. MCP Pre Tool guardrails draaien voordat de tool wordt uitgevoerd. Als een daarvan mislukt, draait de tool nooit, waardoor de kosten, bijwerkingen en gegevensblootstelling van een slechte call volledig worden vermeden. Ingebouwde pre-tool guardrails omvatten: SQL Sanitizer, die DROP, TRUNCATE, DELETE en UPDATE zonder WHERE opvangt, evenals string-interpolatiepatronen die duiden op een injectierisico; Prompt Injection-detectie met behulp van modelgebaseerde analyse voor jailbreak- en injectiepogingen in parameters van de tool-call; Secrets Detection die API-sleutels, AWS-authenticatiegegevens, JWT-tokens en privésleutels opvangt voordat ze backend-diensten bereiken; en Cedar- en OPA-beleidsguardrails voor declaratieve, fijndradige toegangscontrole tot op specifieke tool-argumenten.

MCP Post Tool guardrails draaien nadat de tool terugkeert, voordat het resultaat de agent bereikt. Ingebouwde post-tool guardrails omvatten Code Safety Linter, die eval, exec, os.system, subprocess-calls en gevaarlijke shell-commando's in tool-output markeert; PII Detection, die persoonlijke informatie zoekt en redigeert met configureerbare entiteitscategorieën; en Regex Pattern Matching voor aangepaste patronen die betaalkaarten, interne ID's en domeinspecifieke gevoelige gegevens dekken. Externe providers waaronder AWS Bedrock Guardrail, Azure Content Safety, Azure Prompt Shield, CrowdStrike en Google Model Armor integreren allemaal via hetzelfde hook-systeem.

Handhavingsstrategieën zijn configureerbaar per guardrail. Enforce blokkeert bij een overtreding en bij een guardrail-fout. Enforce But Ignore On Error blokkeert bij een overtreding, maar laat verzoeken door als de guardrail-provider niet beschikbaar is, wat de aanbevolen standaard is voor productie. Audit logt overtredingen zonder te blokkeren, de juiste modus tijdens de initiële uitrol. De aanbevolen volgorde is eerst Audit, dan Enforce But Ignore On Error, en vervolgens volledige Enforce naarmate het vertrouwen groeit.

Een Enterprise MCP Gateway implementeren: een stappenplan in vier fasen

MCP governance is een geformatteerd programma. Elke stap bouwt voort op de vorige. U kunt geen toegangsbeleid afdwingen voordat u weet welke servers er bestaan. U kunt geen zinvolle audittrail bouwen voordat identiteitstoewijzing aanwezig is.

Stap 1: Inventariseer alle bestaande MCP-implementaties

Begin met een volledige audit van elke draaiende MCP server in ontwikkelomgevingen, CI/CD-pipelines, productie-agentimplementaties en IDE-configuraties. Dit omvat servers die ontwikkelaars lokaal in Cursor of Claude Code hebben geconfigureerd zonder betrokkenheid van IT. Het combineren van geautomatiseerd scannen van cloudomgevingen met een proces van zelfrapportering voor lokale ontwikkelaarsconfiguraties geeft het meest complete beeld voor grote organisaties.

Leg voor elke server het volgende vast: naam en doel, eigenaarsteam, scope van gegevenstoegang, eventuele authenticatiemethode en hoe lang deze al draait. Het doel is een nauwkeurig beeld van wat er bestond voordat er governance was, geen gecureerde lijst van zaken die al goedgekeurd zijn.

Stap 2: Bouw de catalogus met goedgekeurde MCP servers

Definieer het metadataschema en de goedkeuringsworkflow voordat u servers migreert. Belangrijke beslissingen: wie goedkeuringsbevoegdheid heeft voor verschillende risiconiveaus, wat de controlelijst omvat en welke bevindingen catalogusregistratie blokkeren. Stel deze criteria vast voordat u servers categoriseert, zodat ze consistent worden toegepast.

Werk de inventarisatie af en categoriseer elke server als goedgekeurd voor catalogus, in afwachting van beoordeling, of geblokkeerd in afwachting van herstel. Stel een harde datum in waarop alle productieservers in de catalogus geregistreerd moeten zijn en communiceer duidelijk dat niet-gecatalogiseerde servers na die datum bij de gateway worden geblokkeerd. De deadline creëert de urgentie die teams ertoe aanzet actie te ondernemen.

Stap 3: Implementeer de MCP Gateway en dwing SSO af

Routeer al het MCP-verkeer via de gateway voordat u blokkeringsbeleid afdwingt. Begin met REQUEST_LOGGING_MODE ingesteld op ALWAYS. Al het verkeer passeert, alle aanroepen worden vastgelegd, er wordt nog niets geblokkeerd. Twee tot vier weken in deze modus draaien geeft u een nulmeting van echte verkeerspatronen voordat handhaving begint.

Integruur de gateway met uw enterprise IdP via Access > External Auth > Identity Provider in de TrueFoundry UI. Voor Okta die de standaard autorisatieserver gebruikt, is de JWKS URI https://your-org.okta.com/oauth2/v1/keys. Organisaties die een aangepaste Okta-autorisatieserver gebruiken, moeten in plaats daarvan https://your-org.okta.com/oauth2/{authServerId}/v1/keys gebruiken. Voor Azure AD is dit https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys, met tenant-ID en client-ID geconfigureerd als issuer en audience. Controleer of elke aanroep in de auditlog een specifieke gebruikers- of agentidentiteit toont voordat u overgaat tot handhaving. Gedeelde service account-identiteiten in de logs betekenen dat de identiteitstoewijzing onvolledig is.

Stap 4: Schakel handhaving in en configureer waarschuwingen

Schakel na de nulmetingsperiode beleidshandhaving in: blokkeer niet-gecatalogiseerde MCP servers, activeer RBAC-beleid en pas rate limits toe. Communiceer de handhavingsdatum naar ontwikkelaarsstteams met voldoende doorlooptijd om legitieme tools snel via catalogusregistratie goed te laten keuren.

Stel alarmering in op de geëxporteerde OpenTelemetry-data voor anomale patronen: ongebruikelijke oproepvolumes van een enkele agent-identiteit, toegang tot hooggevoelige tools buiten goedgekeurde uren, beleidsschendingen van identiteiten die geen MCP-toegang zouden moeten hebben. De guardrail-resultaten in AI Gateway > Monitor > Request Traces bieden de details die nodig zijn om drempelwaarden in de loop van de tijd af te stemmen. Beoordeel alarmeringsregels elk kwartaal naarmate je MCP-implementatie groeit.

MCP Security Enterprise Requirements per industrie

Drie vereisten komen consistent naar voren in alle gereguleerde omgevingen: toewijsbare toegangsrecords gekoppeld aan geverifieerde identiteiten, controle op dataresidentie die gevoelige data binnen gedefinieerde grenzen houdt, och leveranciersrisicodocumentatie voor de governance-infrastructuur zelf.

• Gezondheidszorg (HIPAA): Elke MCP-server die beschermde gezondheidsinformatie (PHI) kan ontvangen in parameters of responsen, vereist een VPC-geïsoleerde gateway. Tool-aanroepen met PHI vereisen logs waarin patiëntidentificatoren zijn vervangen door referentietokens, en toegang moet worden verleend via klinisch identiteitsbeheer. De self-hosted-implementatie van TrueFoundry op AWS GovCloud ondersteunt workloads die zijn afgestemd op HIPAA. Innovaccer verwerkt maandelijks ongeveer 17 miljoen klinische AI-inferentieverzoeken volledig binnen hun AWS GovCloud-grens met behulp van TrueFoundry, waarbij OpenTelemetry Grafana-dashboards voedt en er geen gevoelige data hun cloudperimeter verlaat.

• Financiële diensten (SOC2, FINRA): MCP-governance-infrastructuur valt binnen de scope voor SOC2 Type II-audits als deze financiële data verwerkt of toegang heeft tot adminstratieve systemen (systems of record). Vereiste controles omvatten encryptie in rust en in transit, driemaandelijkse toegangsbeoordelingen met gedocumenteerd bewijs en incidentrespons-procedures voor MCP-specifieke storingsmodi. TrueFoundry beschikt over een SOC2 Type II-certificering en exporteert gestructureerde MCP-auditlogs in het formaat dat auditors vereisen om CC6-controlebewijs te leveren.

• Verzekeringen en wereldwijde ondernemingen (GDPR, Data Residency): Organisaties die onder de GDPR vallen, moeten een verwerkingsregister bijhouden op grond van Artikel 30 dat AI-ondersteunde verwerking dekt, inclusief MCP-tool-aanroepen. Dit register is een gestructureerd compliance-document dat verwerkingsdoeleinden, datacategorieën, doorgiften en waarborgen beschrijft. MCP gateway-auditlogs leveren de onderliggende gebeurtenisdata die dit register voeden, maar het verwerkingsregister zelf moet afzonderlijk worden bijgehouden door de gegevensbeschermingsfunctie van de organisatie. Gateway-logs moeten ook voldoende metadata vastleggen om verzoeken van betrokkenen te ondersteunen en eventuele grensoverschrijdende doorgiften te documenteren die plaatsvinden via tool-aanroepen. Dateresidentievereisten kunnen verbieden dat MCP-verkeer specifieke geografische regio's verlaat, wat regionale gateway-implementaties vereist.

Hoe TrueFoundry Enterprise MCP Governance levert

De MCP Gateway van TrueFoundry levert alle vier de governance-pijlers vanuit één enkel control plane dat is geïmplementeerd binnen het eigen cloudaccount van de klant. Platformteams beheren de volledige governance-stack via één interface zonder individuele MCP-serverimplementaties te wijzigen. Er verlaat geen MCP-verkeer de ondernemingsperimeter.

Ondernemingen waaronder NVIDIA, Zscaler, Siemens Healthineers en Automation Anywhere gebruiken TrueFoundry om over te stappen van ad-hoc MCP-implementaties naar gecontroleerde, beheerde omgevingen. Voor ondernemingen die AI-agent-workloads op schaal uitvoeren, hebben de door beleid afgedwongen kostenbeheersingen, budgetlimieten en cachinglaag van TrueFoundry geleid tot substantiële reducties in de maandelijkse uitgaven voor inferentie en tool-aanroepen. Neem contact op met TrueFoundry voor casusspecifieke cijfers op basis van jouw werkelijke aanroepvolume en modelmix.

• Gecentraliseerde MCP-catalogus met screening-workflow: Het TrueFoundry control plane onderhoudt het geautoriseerde register van goedgekeurde MCP-servers met metadata, goedkeuringsstatus en verbindingsparameters. Nieuwe servers komen binnen via een screeningsproces dat een beoordeling van de tool-beschrijving op poisoning-risico's omvat voordat ze worden gedistribueerd naar ontwikkelaars-IDE-configuraties. Met de functie Virtual MCP Server kunnen platformteams gecureerde tool-subsets samenstellen uit meerdere geregistreerde servers, waarbij alleen wordt blootgesteld wat een specifiek team nodig heeft, zonder nieuwe infrastructuur te implementeren.

• OAuth2 en RBAC bij elke tool-aanroep: Elke MCP-aanroep wordt geauthenticeerd via OAuth2 met de ondernemingsidentiteit van de aanroeper. De gateway ondersteunt alle zes de uitgaande authenticatiepatronen en beheert de volledige token-levenscyclus voor Authorization Code flows, Client Credentials flows en API key-injectie. RBAC-beleid dat op de gateway wordt afgedwongen, is na bijwerking direct van toepassing op alle clients, zonder dat de server opnieuw hoeft te worden geïmplementeerd.

• Configureerbaar metadatabeleid per aanroep: TrueFoundry past datamaskering toe via PII Detection- en Regex-guardrails, rate limits per team, kostenlimieten per agent-sessie en blokkeringsregels voor beperkte tool-categorieën via Cedar- of OPA-beleid. Alles geconfigureerd in de beheerinterface. Geen wijzigingen in de MCP-servercode vereist.

• Auditlogs gestreamd naar je SIEM: Gestructureerde JSON-auditlogs voor elke MCP-aanroep worden via OpenTelemetry geëxporteerd naar Grafana, Datadog, Splunk of elke OTLP-compatibele bestemming. Bij self-hosted-implementaties worden logs in Parquet-formaat naar je eigen AWS S3-, GCS- of Azure Blob-storage geschreven, bevragen via Spark, DuckDB of Athena. REQUEST_LOGGING_MODE: ALWAYS zorgt voor volledige vastlegging voor gereguleerde omgevingen.

• VPC-geïsoleerde implementatie met vier opties: Volledig beheerde SaaS zonder infrastructuur-overhead; SaaS-gateway met eigen datastorage van de klant; self-hosted gateway plane met TrueFoundry control plane tegen ongeveer $ 600 per maand aan infrastructuurkosten; volledig self-hosted control plane plus gateway tegen ongeveer $ 800 tot $ 1.000 per month. De laatste twee opties zorgen ervoor dat er geen MCP-aanroepverkeer je perimeter verlaat om de TrueFoundry-infrastructuur te bereiken.

‍