Enterprise MCP-toegangsbeheer: beheren van tools, servers en agents

Hier is een scenario dat op dit moment plaatsvindt in productieomgevingen.

Je implementeert de standaard, open-source GitHub MCP-server. Het doel is simpel: je wilt dat je engineering support-agent reacties op issues leest en deze samenvat voor het team. Het werkt perfect. De agent maakt verbinding, voert een list_tools handshake uit en begint gegevens op te halen.

Twee dagen later hallucineert diezelfde agent. In plaats van een thread samen te vatten, besluit hij op basis van een verkeerd begrepen reactie dat de repository "deprecated" is en roept hij delete_repo aan.

Waarom gebeurde dit? Het was geen prompt injection-aanval. Het was geen kwaadwillende insider. Het was een fundamentele architectonische fout.

De standaard GitHub MCP-server, net als de Stripe-, Postgres- en Kubernetes-servers die je op GitHub vindt, is binair. Het stelt elk API-eindpunt beschikbaar dat het omvat. Als de server delete_repo ondersteunt, en je geeft de agent de verbindingsreeks, dan heeft de agent delete_repo. Er is geen systeemeigen .gitignore voor toolfunctionaliteiten. Er is geen chmod voor JSON-RPC-tooldefinities.

Toch implementeren we routinematig agents met "Root Access" tot onze meest kritieke infrastructuur, omdat de standaard MCP-implementatie granulariteit mist.

Dit is een onoverkomelijk probleem voor enterprise-adoptie. We hebben geen behoefte aan meer "AI-beleidsdocumenten" of strenge waarschuwingen in system prompts. We hebben een architectonisch patroon nodig dat MCP-servers opdeelt in veilige, afgebakende interfaces.

We noemen dit de Virtual MCP Server.

Architectuur: Aggregators vs. Proxies

Om dit op te lossen, moeten we kijken naar hoe we verkeer routen tussen de LLM en de tools. Op dit moment ontstaan er twee dominante patronen in het ecosysteem (vaak aangehaald in documentatie van Gartner en TrueFoundry): de Aggregator en de Proxy.

• Het Aggregator-patroon Dit is de "aan de slag"-benadering. Je zet één enkel eindpunt op dat uitwaaiert naar meerdere onderliggende servers.
  
  • Verkeersstroom: Agent -> Aggregator -> [Server A, Server B, Server C]
  • Het probleem: Hoewel het eenvoudig in te stellen is, wordt het een single point of failure. Erger nog, het geeft meestal gewoon de volledige lijst met functionaliteiten van alle verbonden servers terug aan de agent. Het creëert een "God Mode"-agent die elke tool in je stack ziet.
• Het Proxy-patroon (De Enterprise-standaard) Dit is waar we moeten zijn. De Proxy fungeert als een slimme sidecar of gateway die zich bevindt tussen de agent en de uitvoeringslaag. Het creëert een strikte 1:1 of 1:N-mapping, maar met een cruciaal verschil: het stuurt niet alleen pakketten door.

De Proxy voert payload-inspectie uit voordat verzoeken de backend bereiken, waardoor onveilige tools al tijdens het ontdekken kunnen worden verwijderd. Het stelt ons in staat om de tools/list JSON-RPC-respons te onderscheppen en chirurgisch de tools te verwijderen waarvan de agent niet mag weten dat ze bestaan.

Implementatie: Het "Virtual Server"-patroon

Dit brengt ons bij het kernimplementatiepatroon: de Virtual MCP Server.

Een Virtual MCP Server is een logische constructie. Het verwijst naar specifieke tools van fysieke MCP-servers zonder hun uitvoeringslogica te dupliceren of infrastructuur opnieuw te implementeren. Dit is waar MCP vs API praktisch wordt voor enterprise-teams: traditionele API's beperken de toegang meestal op eindpuntniveau, terwijl MCP ook moet beslissen welke tools zichtbaar zijn tijdens discovery voordat een agent ooit een aanroep doet. Denk eraan zoals een VIEW in SQL: het stelt je in staat om een beperkte subset van gegevens (of in dit geval functionaliteiten) te presenteren aan een specifieke gebruiker (de agent) zonder de onderliggende tabel (de fysieke server) te wijzigen.

Hier is hoe je dit patroon implementeert in een productie-Gateway-architectuur:

Stap 1: De backend-verbinding (Het "Service Account") Eerst verbind je je ruwe MCP-servers met hoge rechten met de Gateway.

• Verbinding: De Gateway brengt een permanente verbinding tot stand met de postgres-master of github-admin MCP-server.
• Credential-beheer: De Gateway beheert het "Service Account" of de Admin-credentials die nodig zijn om bij deze servers te authenticeren.
• Isolatie: Cruciaal is dat de Agent deze credentials nooit ziet. De Agent verbindt met de Gateway, niet met de tool. De Gateway fungeert als de kluis.

Stap 2: De slice (Het Manifest) Vervolgens definieer je een Virtual Server-manifest. Dit is een configuratiebestand (meestal YAML of JSON) dat exact definieert welke tools van de fysieke servers worden blootgesteld aan een specifieke agent-scope.

In plaats van toegang te verlenen tot github-all, maak je een slice. Hier is hoe een typische Virtual Server-configuratie eruitziet:

Stap 3: De client-weergave (De Handshake) Wanneer de Agent zijn verbinding initialiseert, voert hij de standaard JSON-RPC tools/list handshake uit met de Gateway.

Omdat de Agent is verbonden met de support-agent-scope Virtual Server, onderschept de Gateway dit verzoek. Hij filtert de masterlijst tegen het manifest dat in Stap 2 is gedefinieerd en geeft een opgeschoonde lijst terug.

Het resultaat? Het is technisch onmogelijk voor de agent om een aanroep naar delete_repo te hallucineren. Die functie bestaat simpelweg niet in zijn context window. Je hebt het model niet alleen verteld "doe het niet", je hebt de handen weggehaald die het zou gebruiken om het te doen.

Waar TrueFoundry past 

Dus waar bevindt TrueFoundry zich daadwerkelijk in deze architectuur?

Niet als een hostinglaag, en niet als een handige wrapper. In een productie-MCP-stack fungeert TrueFoundry als de protocol-gateway en het control plane. Het bevindt zich direct in het uitvoeringspad tussen de LLM-runtime en de tools, waar handhaving nog steeds mogelijk is.

Deze positionering is van belang. Omdat de gateway de MCP-verbinding beëindigt, kan hij de JSON-RPC-payload in real-time parseren en analyseren. Hij stuurt verzoeken niet zomaar door. Hij interpreteert intentie, identiteit en scope voordat een tool ooit wordt uitgevoerd.

Dat maakt drie concrete engineering-functionaliteiten mogelijk.

• Identiteitsinjectie (uitvoering namens de gebruiker).

De meeste DIY-agent-stacks hebben last van het "generieke sleutel"-probleem. Agents draaien met een gedeelde API-token, dus wanneer er iets misgaat, zie je in de logs alleen "de agent heeft het gedaan". Er is geen verantwoording. De gateway van TrueFoundry inspecteert het inkomende client-JWT, koppelt dit aan de geauthenticeerde menselijke gebruiker en injecteert stroomafwaarts de juiste OAuth- of servicetoken. Als Alice geen repository kan verwijderen, kan de agent die namens haar handelt dat ook niet. De autoriteit van de agent is niet langer theoretisch. Het is cryptografisch gebonden.

• Virtual server runtime-handhaving.

De gateway is waar Virtual MCP Servers werkelijkheid worden. TrueFoundry onderhoudt de routingtabellen die een virtual server-scope koppelen aan fysieke MCP-servers en toegestane tools. Als een agent probeert iets aan te roepen buiten zijn gedeclareerde slice, geeft de gateway een gestructureerde JSON-RPC-fout terug. Het model krijgt geen stille mislukking. Het krijgt een duidelijke "tool niet gevonden", wat het helpt zichzelf te corrigeren in plaats van te hallucineren.

• Verkeersinspectie en replay.

Omdat de gateway de verbinding beëindigt, kan hij MCP-verkeer bufferen en traceren. Dit maakt inspectie van tool-interacties in PCAP-stijl mogelijk. Wanneer een agent vastloopt in een lus of een slechte beslissing neemt, kun je de exacte tool-aanroepsequentie opnieuw afspelen zonder de dure inferentiestappen die ertoe leidden opnieuw uit te voeren. Foutopsporing verschuift van gokwerk naar inspectie.

‍

Alles bij elkaar genomen is dit het verschil tussen hopen dat een agent zich gedraagt en afdwingen dat hij zich niet kan misdragen. Toegangsbeheer verhuist uit prompts naar de infrastructuur, waar het thuishoort.

Defense in Depth: Guardrails op de protocollaag

Virtual Servers bepalen welke tools een agent kan zien. Guardrails bepalen hoe die tools worden gebruikt. Zelfs als een agent sql_query mag aanroepen, betekent dat niet dat hij SELECT * FROM users zou mogen uitvoeren en de gehele klantendatabase in zijn context window zou mogen dumpen.

Dit is waar Guardrails om de hoek komen kijken. In de TrueFoundry-architectuur werken guardrails als middleware die de JSON-RPC-payload onderschept op de protocollaag, waarbij het verkeer wordt geïnspecteerd voordat het wordt uitgevoerd.

Input Guardrails (De "WAF" voor Agents) We kunnen Python-middleware of eenvoudige regex-regels schrijven die tool-argumenten valideren voordat het verzoek de backend-container bereikt.

• Het Scenario: Een agent probeert een query uit te voeren zonder LIMIT-clausule, wat de database mogelijk laat crashen或者是 een vermogen kost aan tokengebruik.
• De Oplossing: Een input guardrail onderschept de sql_query-tool. Het controleert de argumenten-payload. Als LIMIT ontbreekt, wijst het het verzoek af of injecteert het automatisch een standaard LIMIT 100.
• Security Use Case: Regex-filters kunnen patronen zoals API-sleutels of privesleutels in de invoerargumenten detecteren, wat voorkomt dat de agent per ongeluk geheimen lekt naar een loggingtool van derden.

Output Guardrails (Data Loss Prevention) Agents zijn geneigd tot "sprakeloos lekken", waarbij ze meer gegevens ophalen dan ze nodig hebben en deze samenvatten.

• Het Mechanisme: Output guardrails schonen de JSON-respons van de tool op voordat deze wordt teruggegeven aan de LLM.
• De Implementatie: Als een database-tool een kolom met de naam ssn of credit_card teruggeeft, kan de guardrail deze gegevens hashen of maskeren (bijv. ****-1234) in de JSON-RPC-respons. De LLM krijgt de context die hij nodig heeft ("Creditcard bestaat") zonder ooit de gevoelige gegevens in zijn context window te hebben.

Observability: Het "denkproces" traceren

In traditionele software controleer je de logs als een API-aanroep mislukt. Je ziet een 500 Internal Server Error en een stack trace.

In agentic systemen is een "fout" vaak stil. De agent roept een tool aan, krijgt een resultaat, maar interpreteert het verkeerd. Of hij roept de tool aan met net verkeerde argumenten die technisch wel werken, maar waardeloze gegevens opleveren. Standaard applicatielogs tonen "200 OK", maar de uitkomst is fout.

Om dit te debuggen, heb je Distributed Tracing voor MCP nodig.

TrueFoundry biedt een watervalvisualisatie van de uitvoeringsketen van de agent. Je ziet niet alleen "Verzoek mislukt." Je ziet de latentie en payload bij elke stap:

• Span A (Reasoning): De LLM besteedt 200ms aan het genereren van de gedachte.
• Span B (Gateway): De Gateway heeft 10ms nodig om de JWT te valideren en het verzoek te routen.
• Span C (Tool Execution): De Postgres-container heeft 1.5s nodig om de query uit te voeren.

Waarom dit van belang is: Je kunt inzoomen op Span C en de exacte SQL-query zien die de agent heeft gegenereerd. Je realiseert je misschien dat de agent een tabelnaam hallucineert die niet bestaat, of een verouderde API-parameter gebruikt. Zonder deze zichtbaarheid op protocolniveau ben je een black box aan het debuggen door te raden.

Conclusie: Beveiliging als enabler

De overgang van "Chatbot" naar "Agent" is in feite de overgang van "Tekstgeneratie" naar "Remote Code Execution." Die realiteit is precies wat de meeste enterprise-pilots in de PoC-fase houdt.

TrueFoundry overbrugt die kloof. Wanneer je het Virtual MCP Server-patroon implementeert via de AI Gateway, stop je met het vragen aan je securityteam om een probabilistisch model te vertrouwen en begin je hen een deterministische architectuur te tonen. Je implementeert niet zomaar een tool; je implementeert een afgebakende, identiteitsbewuste interface die de mogelijke schade inherent beperkt.

Voor enterprises levert TrueFoundry niet alleen de "leidingen" voor MCP; het levert de kleppen, meters en sloten. Het verandert een roekeloze "Root Access"-agent in een vertrouwde digitale medewerker. Je zou een Kubernetes-productiecluster niet draaien zonder RBAC; je zou een enterprise-agent-stack niet moeten draaien zonder TrueFoundry.