MCP Gateway Registry: het enterprise-besturingsvlak voor AI-agents

U bent voorbij chatbots gegroeid. Nu bouwen uw teams autonome AI-agents die toegang hebben tot uw interne databases, Jira raadplegen, GitHub bijwerken, Slack-berichten sturen en uw aangepaste API's aanroepen, allemaal zonder menselijke hulp. Deze ongelooflijke agent-workflows leveren echte productiviteitswinst op, maar ze brengen ook een governance-complexiteit met zich mee die de meeste teams onderschatten.

Aanvankelijk werkt deze opzet. Wat begint als een interessant experiment, waarbij een ontwikkelaar één agent verbindt met één tool, verloopt soepel. Al snel worden er meer agents en MCP-tools toegevoegd, afkomstig uit VS Code-extensies, community-servers of interne builds. Binnen de kortste keren verliest IT het overzicht over hoeveel verbindingen er bestaan, waar inloggegevens zijn opgeslagen of welke agent waartoe toegang heeft.

Dit is niet zomaar een technische hoofdpijn. Het is ook een beveiligings- en compliance-risico dat op de loer ligt.

Anthropic lanceerde het Model Context Protocol (MCP) in november 2024 om te standaardiseren hoe AI-agents verbinding maken met externe tools. MCP lost het probleem met de integratietaal op, maar regelt de governance niet. Het helpt u niet bij het beheren van honderden toolverbindingen over vele agents heen op enterprise-schaal.

Dat is waar een MCP gateway registry uitkomst biedt. Laten we kijken wat deze registry is, wat hij moet doen om in productie te werken, waar concurrenten de plank misslaan en waarom TrueFoundry een betere, voordeligere keuze is.

De chaos voor de registry: punt-tot-punt toolintegraties

Wanneer bedrijven AI-agents beginnen te bouwen zonder een centrale registry, volgen ze bijna altijd hetzelfde pad. De eerste paar integraties zijn eenvoudig. Daarna beginnen de dingen op voorspelbare wijze vast te lopen.

• Hardcoded afhankelijkheden: Ontwikkelaars verbinden hun agents rechtstreeks met specifieke MCP-servers. Elke agent weet waar de tool zich bevindt, hoe deze moet worden aangeroepen en welke inloggegevens moeten worden gebruikt. Deze opzet werkt voor een enkele bron. Maar als de API van de backend-tool verandert, breekt elke agent die ervan afhankelijk is tegelijkertijd. Er is geen buffer om de verandering op te vangen, dus platformteams moeten meerdere codebases bijwerken om hetzelfde probleem op te lossen.
• Wildgroei van inloggegevens: Elke agent beheert zijn eigen authenticatie. API-sleutels worden hardcoded in omgevingsbestanden geplaatst. OAuth-flows worden opgeslagen op individuele servers en in notebooks van ontwikkelaars. Inloggegevens van serviceaccounts worden dubbel opgeslagen over teams heen. Wanneer een sleutel moet worden geroteerd, moet deze worden opgespoord en bijgewerkt op elke plek waar hij staat. Als er één instantie wordt overgeslagen, is dat uw kwetsbare plek. Op schaal is het garanderen van veilige rotatie van inloggegevens vrijwel onmogelijk.
• Nul centraal overzicht: IT- en beveiligingsteams hebben geen centraal toegangspunt om te controleren. Ze kunnen vragen zoals welke MCP-tools en databronnen agents kunnen gebruiken, welke agents welke tools gebruiken, hoe vaak een database wordt geraadpleegd, of dat een agent toegang heeft tot gegevens waar hij geen toegang toe zou moeten hebben, niet eenvoudig beantwoorden. Compliance-audits betekenen het verzamelen van logs uit vele systemen, en het opsporen van anomalieën is vrijwel onmogelijk.

Dit zijn geen uitzonderingsgevallen, en ze zijn een belangrijke oorzaak van schaduw-AI-risico's. Ze duiken op in elk bedrijf dat agent-infrastructuur probeert te schalen zonder besturingsvlak. Het punt-tot-puntmodel werkt voor pioniers die experimenteren met individuele agents. Het werkt niet voor productie.

Wat is een MCP Gateway Registry?

Een MCP gateway registry is een centrale catalogus binnen uw MCP gateway. Dit fungeert als de centrale bron van waarheid voor elke goedgekeurde tool in uw organisatie. Het is de enige plek waar elke goedgekeurde MCP-server en externe tool wordt geregistreerd, beschreven, van een versie wordt voorzien en vindbaar wordt gemaakt voor AI-agents binnen uw hele organisatie.

Zie het als de gids voor uw AI-toolinfrastructuur. Net zoals microservicecatalogi individuele service-eindpunten abstraheren, abstraheert een registry de complexiteit van de ruwe protocolondersteuning voor agent-ontwikkelaars. Zoals een servicecatalogus aan ontwikkelingsteams laat zien welke API's er bestaan in een microservices-opzet, vertelt een MCP gateway registry aan AI-agents welke MCP-tools ze kunnen gebruiken, hoe ze deze kunnen aanroepen en welke machtigingen ze hebben.

• Gecentraliseerd publiceren: Een platformengineer registreert een tool één keer in de officiële MCP registry. Daarna kan elke geautoriseerde agent in de organisatie deze vinden en gebruiken, inclusief algemene hulpprogramma's zoals zoeken, documenten ophalen en interne API-toegang, zonder dat de engineer verbindingsdetails naar elk team hoeft te sturen. De registry is nu het implementatiedoel voor tools, in plaats van individuele tools die door elke agent worden beheerd.
• Dynamische discovery: Agents gebruiken geen hardcoded toolinstellingen. In plaats daarvan raadplegen ze de registry tijdens de uitvoering om de nieuwste schema's, beschrijvingen en instructies te krijgen voor de tools die ze mogen gebruiken. Deze dynamische tool-discovery betekent dat wanneer een backend-API verandert, de registry wordt bijgewerkt en agents de verandering automatisch overnemen. U hoeft niet langer prompts bij te werken telkens wanneer een tool veranderd.
• Centrale bron van waarheid: Uw beveiligingsteams krijgen een geüniformeerde inventaris. Elke voor AI toegankelijke tool in de organisatie is op één plek geregistreerd, gekoppeld aan eigenaarschap, toegangsbeheerbeleid en gebruiksgeschiedenis. Alles is zichtbaar. Niets opereert buiten het zicht. Dit wordt het daadwerkelijke systeem van verslaglegging voor alle voor agents toegankelijke tooling.

Kernfunctionaliteiten van een Enterprise Registry

Niet elke tool registry is gebouwd voor enterprise-gebruik. Een eenvoudige catalogus die tools en eindpunten vermeldt, is een beginpunt, geen oplossing. In productie zijn er vier functionaliteiten die de beste MCP gateway registry onderscheiden van een goed georganiseerd configuratiebestand.

Gedetailleerde Role-Based Access Control (RBAC)

In elke echte organisatie dienen verschillende AI-agents verschillende functies en moeten ze werken met verschillende niveaus van toegangsbeheer. Een klantenservice-agent moet bestelgegevens kunnen opzoeken en tickets kunnen escaleren. Deze mag geen zicht hebben op opdrachten voor databasebeheer. Een financiële agent heeft toegang nodig tot betalingssystemen. Deze mag geen deployment-pipelines kunnen activeren.

Een enterprise registry dwingt dit af op het niveau van zichtbaarheid, niet alleen op het niveau van uitvoering. AI-agents zien geen MCP-tools waarvoor ze niet geautoriseerd zijn. Het toegangsbeheerbeleid en de controlelogica worden voorafgaand aan discovery toegepast, niet pas nadat een aanroeppoging mislukt. Dit betekent dat beleidshandhaving geen vangrail is die achteraf is toegevoegd. Het zit ingebouwd in de architectuur van hoe tools beschikbaar worden gemaakt.

RBAC in een goede registry is gekoppeld aan identiteit. Het integreert met uw bestaande enterprise identity providers, of dat nu Okta, Azure AD of een aangepaste SSO-opzet is, zodat de machtigingen die AI-agents erven, worden beheerd door hetzelfde beleid dat menselijke toegang in uw organisatie regelt.

Naadloze toolversiebeheer

Backend-API's veranderen. Dat is geen risico dat vermeden moet worden; het is een werkelijkheid die beheerd moet worden. Een enterprise registry pakt dit aan door platformteams in staat te stellen meerdere versies van een tool gelijktijdig te publiceren.

Versie één blijft in de registry en blijft agents bedienen die er van afhankelijk zijn. Versie twee wordt er daarnaast geregistreerd. Ontwikkelingsteams kunnen specifieke agents naar versie twee verwijzen om te testen. Zodra het team er zeker van is dat de update stabiel is, migreren productie-agents op hun eigen schema. Er is geen gedwongen overstap, geen downtime en er zijn geen kapotte agents omdat een tool zonder waarschuwing onder hun voeten is veranderd.

Dit model van parallelle versies is de manier waarop volwassen infrastructuurteams elke gedeelde afhankelijkheid beheren. Het favoriete onderdeel voor platformengineers is dat ze niet langer gedwongen upgradewindows hoeven te coördineren. De registry brengt diezelfde discipline naar AI-agents en hun MCP-tools.

Gecentraliseerde kluis voor inloggegevens

In een direct-connect-model is elke agent verantwoordelijk voor zijn eigen opslag van inloggegevens. Dat betekent API-sleutels, OAuth-tokens en databaseverbindingsreeksen die verspreid liggen over agent-codebases, naast andere software-artefacten in omgevingsvariabelen en configuratiebestanden binnen uw infrastructuur. Het roteren van een enkele sleutel vereist het opsporen van elke plek waar deze staat. Er één vergeten creëert een kwetsbaarheid.

Een registry met gecentraliseerde kluisopslag voor inloggegevens neemt dit probleem weg. Backend-inloggegevens worden op één plek opgeslagen en beheerd door de gateway. Wanneer een agent een tool aanroept, voegt de gateway tijdens de uitvoering de juiste inloggegevens in. De agent ziet de ruwe sleutel nooit. Ontwikkelaars hoeven downstream-authenticatie voor de tools die ze aanroepen nooit te beheren. Het vernieuwen van tokens gebeurt automatisch. Rotatie vindt één keer plaats, in de kluis, en elke agent profiteert er direct van.

Individuele gebruikers authenticeren zich één keer bij de MCP gateway, met behulp van een enkel token. De gateway handelt alle downstream MCP-authenticatie namens hen af, inclusief het invoegen van aangepaste headers die vereist zijn door specifieke backend-tools.

Volledig audit-traject en observability

In traditionele infrastructuur kunt u logs van een server ophalen om te begrijpen wat er tijdens een incident is gebeurd. Bij gedistribueerde agent-tool-interacties wordt dat veel moeilijker wanneer er geen centraal verzamelpunt is.

Een enterprise registry geeft u dat verzamelpunt. Uitgebreide audit-logging legt elke tool-aanroep vast met de identiteit van de agent, de gebruiker of service die het verzoek doet, de meegegeven argumenten, de geretourneerde respons en de latentie van de interactie. Wanneer er iets misgaat, kunt u precies traceren wat de agent deed, in welke volgorde en wat elke tool retourneerde. Compliance-teams krijgen een auditeerbaar dossier zonder aangepaste instrumentatie te hoeven bouwen voor elke tool afzonderlijk

De verborgen gebreken in registry's van concurrenten

Er bestaan verschillende opties voor het op schaal beheren van MCP-servers. De meeste lossen een deel van het probleem op. Begrijpen waar ze tekortschieten, helpt te verduidelijken wat u daadwerkelijk nodig hebt bij het evalueren van de juiste registry voor uw organisatie.

• Nachtmerries met configuratiebestanden: Community-registry's zoals de JFrog MCP registry en andere open-source MCP-proxytools beheren toolregistratie via statische YAML- of JSON-configuratiebestanden, inclusief benaderingen die zijn gebouwd rond Docker Compose- en Nginx reverse proxy-opstellingen. Elke nieuwe MCP-server vereist een handmatige bestandsbewerking, een commit en een hernieuwde deployment. Op kleine schaal is dit werkbaar. Naarmate het aantal MCP-tools groeit en teams zich vermenigvuldigen, wordt het een knelpunt. Er is geen gebruikersinterface voor niet-engineers om tools te registreren, geen goedkeuringsworkflow en geen manier om in één oogopslag te zien wat de werkelijke huidige staat van de registry is. Het configuratiebestand wordt de enige bron, en het loopt altijd één gemiste update achter op de realiteit.

• De enterprise-betaalmuur: Verschillende SaaS-platformen voor AI-infrastructuur bieden basale MCP gateway-routing gratis aan, om vervolgens de functies die er echt toe doen af te schermen achter enterprise-contracten. RBAC, SSO-integratie, toolversiebeheer en uitgebreide audit-logging zijn geen geavanceerde functies. Het zijn de basiseisen voor elke productie-implementatie. Wanneer die mogelijkheden achter een onvoorspelbare prijscategorie zijn vergrendeld, hangt uw governance-status af van een budgetgesprek, niet van een technische beslissing.

• Risico's voor gegevensexfiltratie en -soevereiniteit: In de cloud gehoste SaaS-registry's verwerken de dynamische tool-discovery-verzoeken van uw agents via infrastructuur die u niet beheert. In gereguleerde sectoren levert dit directe beveiligingsrisico's op. Elk discovery-verzoek kan metadata bevatten over uw interne systemen, de tools die uw AI-agents gebruiken en de gevoelige gegevens waartoe ze toegang hebben. Dit is zowel een zorg voor de toeleveringsketen als een datarisico. Het routeren daarvan via een cloud van derden, zelfs een die u vertrouwt, kan u aan de verkeerde kant van uw eigen vereisten voor datalocatie brengen nog voordat er een enkele tool is aangeroepen. Het behandelen van MCP-servers als componenten van de software-toeleveringsketen betekent dat u dezelfde controle moet toepassen als op elke code-afhankelijkheid van derden. Dit is een belangrijk operationeel risico dat beveiligingsteams consequent signaleren.

Hoe TrueFoundry toolbeheer vereenvoudigt

TrueFoundry heeft zijn registry ontworpen om de echte uitdagingen op te lossen waarmee bedrijven worden geconfronteerd wanneer ze AI-agents verplaatsen van experimenten naar productie. De belangrijkste doorbraak is dat governance geen afzonderlijke tooling-laag vereist; het draait binnen uw eigen infrastructuur. De architectuur richt zich op drie prioriteiten: datasoevereiniteit, operationele eenvoud en governance die ontwikkelaars niet vertraagt.

Absolute datasoevereiniteit (In-VPC Deployment)

TrueFoundry draait de gehele registry en MCP gateway binnen uw eigen cloudaccount, of dat nu AWS, GCP of Azure is. Toolverkeer, agent-telemetrie, inloggegevens en dynamische tool-discovery-verzoeken blijven binnen uw netwerk. Ze gaan nooit door de infrastructuur van TrueFoundry en raken nooit het openbare internet.

Voor organisaties met behoeften op het gebied van SOC 2, HIPAA of interne datalocatie is dit niet zomaar een vinkje. Het is het verschil tussen een platform dat past bij uw MCP-beveiligingsmodel en een platform dat voor gebruik een langdurig uitzonderingsproces vereist. Wanneer alles in uw VPC draait, hoeven uw beveiligingsteams alleen uw eigen infrastructuur te beoordelen. Het centrale besturingsvlak blijft volledig binnen uw beveiligingsperimeter.

Transparante, op compute gebaseerde kosten

TrueFoundry gebruikt geen afscherming van functies om bedrijven meer te laten betalen. Gedetailleerde RBAC, opslag van inloggegevens, volledige dynamische tool-discovery en uitgebreide audit-logging zijn standaardfuncties, geen add-ons voor hogere prijscategorieën.

Kosten zijn gebaseerd op uw werkelijke compute-gebruik. Naarmate u uw agent-infrastructuur schaalt, betaalt u voor de compute die u gebruikt, niet voor toegang tot governance-functies die standaard zouden moeten zijn. Dit betekent dat de functies die u nodig hebt om veilig in productie te draaien vanaf dag één beschikbaar zijn voor MCP-servergovernance, ongeacht uw contractniveau.

Gebouwd voor ontwikkelsnelheid

Het publiceren, testen en beheren van versies van tools vereist geen bewerking van YAML-bestanden of het indienen van configuratiewijzigingen via een deployment-pipeline. Ontwikkelaars werken met de officiële MCP registry via een intuïtieve UI of CLI. Platformteams kunnen nieuwe MCP-serververmeldingen registreren, toegangsbeheerbeleid instellen en updates doorvoeren zonder handmatig werk te creëren voor elk consumerend team.

TrueFoundry organiseert MCP-servers in logische groepen met behulp van MCP Server Groups, waardoor teams toolsets kunnen isoleren op basis van omgeving, functie of beveiligingsniveau. Ontwikkelingsteams kunnen experimenteren met tools zonder toegang open te stellen in de productie-registry. Verschillende groepen hebben hun eigen RBAC-beleid en goedkeuringsflows, zodat gevoelige systemen met een hoog risico expliciete goedkeuring vereisen voordat een agent ze mag aanroepen.

Het platform ondersteunt ook On-Behalf-Of (OBO) MCP-authenticatie. In plaats van dat AI-agents werken onder een generiek serviceaccount, kunnen de MCP-client tool-aanroepen de identiteit en machtigingen weerspiegelen van de werkelijke menselijke gebruiker die met de agent communiceert. De MCP-tools respecteren dezelfde toegangsgrenzen die die persoon elders in de enterprise-systemen heeft.

Conclusie: Behandel tools als infrastructuur

Het patroon is consistent bij bedrijven die AI-agents voorbij de proof-of-concept-fase hebben geschaald. Punt-tot-puntverbindingen tussen agents en tools werken totdat ze dat niet meer doen. Het moment dat u meer dan een handvol agents in productie hebt draaien, wordt de afwezigheid van een centrale registry een dagelijks operationeel probleem, geen theoretisch risico.

Breder gebruik van MCP in bedrijven maakt deze infrastructuurlaag steeds essentiëler. Een MCP gateway registry is geen 'nice-to-have'-laag boven op uw agent-architectuur. Naarmate organisaties vorderen op de adoptiecurve van individuele agents naar gecoördineerde multi-agent-systemen, wordt de registry het fundament waarvan al het andere afhangt.

Het is het besturingsvlak dat de agent-infrastructuur regelt. Het is de manier waarop IT-teams overzicht krijgen, hoe beveiligingsteams beleidshandhaving afdwingen en hoe ontwikkelaars tools opleveren zonder handmatig werk te creëren voor elk team dat toegang tot tools wil.

TrueFoundry houdt dat allemaal binnen uw eigen omgeving. Uw bedrijfssystemen blijven beschermd en uw gegevens verlaten uw cloudperimeter nooit. De MCP registry draait in uw VPC. De inloggegevens blijven in uw kluis. Het audit-traject is van u. En de functies die u nodig hebt om veilig in productie te draaien, zijn beschikbaar zonder een prijsdiscussie.