OAuth op MCP-niveau: hoe we enterprise-tokenbeheer voor AI-agents hebben opgelost

Een walkthrough van de auth-architectuur in de TrueFoundry MCP Gateway — drie lagen, twee OAuth-flows, één credential vault — verteld vanuit het perspectief van een klant die dit in productie uitrolt.

Een maandagochtend bij Northwind. Om 8:47 uur op een maandagochtend krijgt de dienstdoende engineer bij Northwind Logistics — een fictief maar herkenbaar supply chain-platform met 50 engineers — een Slack-bericht. Hun interne AI-assistent, Cargo Copilot, geeft 401-fouten bij elke tool call naar Jira en GitHub. De oorzaak is de laptop van een ontwikkelaar, die in het weekend op het vliegveld is kwijtgeraakt. IT heeft de SSO-sessie van de laptop ingetrokken. Maar de laptop bevatte ook OAuth-tokens voor GitHub, Slack, Jira en een interne analytics-service, die allemaal naar de editor-instellingen en dotfiles van de ontwikkelaar waren gekopieerd. Security kan niet met zekerheid zeggen welke scopes zijn gelekt, op welke andere apparaten die tokens zijn gespiegeld (omdat ontwikkelaars elkaar helpen), of hoe ze allemaal ingetrokken kunnen worden zonder ieders werkdag te verstoren.

Het incident bij Northwind is niet zeldzaam. Dit is hoe beheer van inloggegevens er bij de meeste bedrijven uitziet na zes maanden enthousiast MCP-gebruik. De rest van dit artikel beschrijft de architectuur waarmee Northwind — en andere TrueFoundry-klanten — dit soort incidenten voorkomen.

1. De wildgroei aan inloggegevens: Hoe 50 ontwikkelaars × 8 MCP-servers er in de praktijk uitzien

Northwind heeft ongeveer vijftig engineers die actief MCP-geschikte IDE's gebruiken in combinatie met acht servers — GitHub, Slack, Google Workspace, Jira, een interne analytics-service, een interne Logistics API, Zendesk en een eigen routeplanningsservice. Dat zijn vierhonderd actieve verbindingen op basis van de eenvoudige rekensom, en in de praktijk aanzienlijk meer plekken waar inloggegevens staan opgeslagen als je sleutelhangers, editor-instellingen, shell-omgevingsbestanden, CI-variabelen en de kopieën die worden gemaakt bij het inwerken van collega's meerekent.

De schade van een gelekte werkplek beperkt zich niet tot één token. Het is één token vermenigvuldigd met de scopes die aan die provider zijn gekoppeld, de levensduur van het token (vaak 90 dagen of langer voor personal access tokens), het aantal apparaten waarop het is gespiegeld en het ontbreken van centrale intrekking. Als een Slack OAuth -token het lezen van de kanaalgeschiedenis toestaat en een lokaal GitHub-token het lezen van repositories mogelijk maakt, verandert een enkel datalek in een incident dat meerdere systemen raakt voordat het securityteam kan reageren. Lokale MCP-inloggegevens zijn operationeel ook onzichtbaar: er is geen centraal audit-log, geen afgedwongen rotatie, geen beleidscontrole voordat een tool wordt uitgevoerd en geen snelle manier om te bepalen wie wat mag aanroepen.

Het gateway-patroon lost dit probleem op. Ontwikkelaars authenticeren zich één keer bij de gateway, en de gateway handelt de uitgaande authenticatie af volgens het geconfigureerde model van elke server — precies het ontwerp zoals beschreven in het TrueFoundry MCP Gateway overview en de Authentication and Security docs. Het voordeel is niet alleen centralisatie. Het zorgt ervoor dat authenticatie een onderdeel van de infrastructuur wordt in plaats van een instelling op elke laptop binnen het bedrijf.

2. De auth-architectuur in drie lagen: Inkomend, toegangsbepaling en uitgaand

De eerste ontwerpkeuze is het scheiden van drie lagen die bij lokale ontwikkelaarsopstellingen vaak door elkaar lopen. De TrueFoundry Authentication and Security docs beschrijven dit als een systeem met drie onderdelen: inkomende authenticatie, toegangsbepaling (access control) en uitgaande authenticatie. De documentatie geeft expliciet aan dat de inkomende en uitgaande lagen onafhankelijk van elkaar werken, wat de belangrijkste architectonische winst is.

• Inkomende authenticatie. Wie roept de gateway aan? TrueFoundry ondersteunt vier methoden: TrueFoundry API Key (PAT), Virtual Account Token, Identity Provider Token (een Okta/Auth0/Azure AD JWT die wordt gevalideerd via een geconfigureerde Identity Provider) en TrueFoundry OAuth (gebruikt door IDE's zoals Cursor en VS Code).
• Toegangsbepaling. Wat mag de geauthenticeerde identiteit doen? Elke MCP-server heeft Collaborators — gebruikers, teams of virtuele accounts — met op rollen gebaseerde rechten (RBAC). Het beperken van de reikwijdte op tool-niveau wordt bereikt door tools van meerdere MCP-servers te combineren in een Virtual MCP Server, die alleen een geselecteerde subset beschikbaar stelt.
• Uitgaande authenticatie. Hoe bereikt de gateway elke achterliggende server? Er worden zeven methoden ondersteund: OAuth2 (Authorization Code), OAuth2 (Client Credentials), API Key (Gedeeld), API Key (Individueel), No Auth, Token Passthrough en Token Forwarding via x-tfy-mcp-headers.

‍

Het ontwerpprincipe is eenvoudig: het gegeven dat wordt gebruikt om de gateway te bereiken, is nooit het gegeven dat de achterliggende tool bereikt. Inkomende rotatie heeft geen invloed op de OAuth-status van de provider. Een GitHub MCP-server kan OAuth per gebruiker gebruiken terwijl de interne analytics-service gebruikmaakt van Client Credentials — binnen dezelfde agent en in dezelfde verzoekstroom. De gateway fungeert zowel als controlepunt voor het beleid als tussenpersoon voor de inloggegevens.

3. 2LO vs 3LO: Het juiste OAuth Grant Type kiezen voor elke MCP-server

In enterprise-termen verwijzen 2LO en 3LO naar twee grant types uit RFC 6749 (OAuth 2.0), ingedeeld naar de manier waarop eindgebruikers hierin meegaan.

Two-legged OAuth (2LO) maakt gebruik van de Client Credentials-grant. De gateway beheert een client_id en client_secret, stuurt grant_type=client_credentials naar het token-eindpunt van de provider, ontvangt een tijdelijk access_token en gebruikt dat token bij elk verzoek naar de MCP-server. Er is geen browser of toestemming van de gebruiker nodig. Dit is de juiste keuze voor server-to-server-integraties: interne analytics-API's, backend-microservices en interne datadiensten.

Three-legged OAuth (3LO) maakt gebruik van de Authorization Code-grant. Elke eindgebruiker wordt omgeleid naar de provider (GitHub, Slack, Google) om toegang tot hun specifieke bronnen te autoriseren. De gateway slaat een refresh_token per gebruiker op, beheert een versleutelde koppeling van user_id → {access_token, expires_at, refresh_token, scopes, provider_metadata} en roteert het access-token automatisch.

Hoe Northwind heeft gekozen

De acht MCP-servers van Northwind zijn ongeveer gelijk verdeeld. GitHub, Slack, Jira, Google Workspace en Zendesk werken allemaal op basis van specifieke gebruikersgegevens — de waarde van "voer dit uit als Alice" weegt zwaarder dan de beheerlast van een token per gebruiker. Deze maken gebruik van 3LO. De interne analytics-service, de Logistics API en de routeplanningsservice bieden allemaal toegang tot bedrijfsbrede gegevens; hier is OAuth per gebruiker niet van toepassing en is een enkele gedeelde Client Credentials-grant eenvoudiger en beter te controleren. Deze maken gebruik van 2LO.

Hoe het configuratiemodel eruitziet

Opmerking over deze configuratieweergave

TrueFoundry registreert MCP-servers via de gebruikersinterface (Settings → MCP Servers → Add MCP Server) en niet via een door de klant beheerd YAML-bestand, hoewel configuratie ook declaratief kan worden toegepast via tfy apply. De onderstaande YAML toont het configuratiemodel per server — dezelfde velden die u in de UI invult — op basis van het gevalideerde schema van TrueFoundry (provider-account/mcp-server-group met geneste integrations):

Het commando om de bovenstaande YAML toe te passen is:

Drie dingen vallen op. Ten eerste is tfy-secret:// het standaard FQN-referentieschema dat TrueFoundry gebruikt voor geheimen die zijn opgeslagen in een TrueFoundry secret group, met de door dubbele punten gescheiden indeling tfy-secret://<tenant>:<secret-group>:<secret-key> zoals beschreven in de Environment Variables and Secrets guide. De waarde staat in uw secret manager (AWS SSM, GCP Secret Manager, HashiCorp Vault, Azure Key Vault); TrueFoundry verwerkt de FQN tijdens de uitvoering, waardoor het bovenstaande bestand veilig in een Git-repository opgeslagen kan worden. Ten tweede is authorized_subjects de RBAC-lijst per server — een combinatie van teams en virtuele accounts — wat het mogelijk maakt dat dezelfde MCP-server zowel menselijke ontwikkelaars bedient (weduwe PAT's naar een teamlidmaatschap verwijzen) als geplande service-account-taken (waarvan de Virtual Account Tokens verwijzen naar virtualaccount:-onderwerpen) zonder dat de configuratie afwijkt. Ten derde stelt de 3LO-invoer code_challenge_methods_supported: [S256] in — PKCE wordt tegenwoordig aanbevolen voor elke Authorization Code-client en is verplicht in de nieuwere MCP-specificatie van 2025-11-25.

Aan de clientzijde hoeft de agent nooit authenticatiemethoden te controleren. Deze verbindt met één gateway-URL, stuurt één inkomend gegeven mee, en de gateway voegt het juiste uitgaande gegeven toe per server:

4. Beheer van de token-levenscyclus: Proactief verversen en gelijktijdige toegang

Een correcte OAuth-implementatie gaat niet alleen over het ophalen van tokens. Het gaat over het veilig beheren van die tokens bij gelijktijdig gebruik. Het basisontwerp ververst een token pas wanneer de provider een 401-fout retourneert, of wanneer now ≥ expires_at. Dat werkt in demonstraties, maar faalt zodra het in een productieomgeving wordt gebruikt.

Stel het incident bij Northwind voor met dit basisontwerp: om 8:47 uur op maandagochtend starten vijftig engineers hun werkdag. Elke worker constateert onafhankelijk van elkaar dat hetzelfde GitHub-token is verlopen. Vijftig parallelle POST /token-aanroepen raken GitHub vanaf dezelfde gateway, waarna GitHub het verkeer blokkeert (rate-limiting). Cargo Copilot geeft 401-fouten aan iedereen totdat de wachtrij is verwerkt.

Het patroon dat standhoudt in productie heeft twee componenten: proactief verversen op 80% van de TTL, en het verversen per (gebruiker, server) opeenvolgend verwerken met een distributed lock.

Door te verversen op 80% van de TTL blijft er ruimte voor tijdverschillen tussen systemen, herhaalde pogingen, trage token-eindpunten van providers en verzoeken die al onderweg zijn. De vergrendeling per (gebruiker, server) voorkomt dat de provider overbelast raakt door een grote hoeveelheid gelijktijdige verzoeken. De extra controle binnen de vergrendeling is noodzakelijk: het zorgt ervoor dat het eerste verzoek de refresh uitvoert, terwijl de overige verzoeken het zojuist bijgewerkte token hergebruiken.

Twee details zijn van belang bij opschaling. Ten eerste is de cache-sleutel voor Client Credentials-integraties (server_id, provider_account); voor Authorization Code-integraties moet de sleutel ook user_id bevatten. Ten tweede vereisen providers die bij elke refresh een nieuw refresh-token uitgeven — zoals Google en Microsoft, afhankelijk van de configuratie — dat het opslaan atomair gebeurt. Als het nieuwe access_token wordt opgeslagen voordat het nieuwe refresh_token is vastgelegd, kan een storing ervoor zorgen dat de gebruiker achterblijft met een ongeldig oud refresh-token, wat opnieuw authenticeren afdwingt.

5. De dubbele auth-flow: Een compleet werkingsdiagram

Door het scheiden van de lagen en het vastleggen van het refresh-pad, volgt een MCP-verzoek via de gateway een vast proces. Volg een Cargo Copilot-aanroep — "geef een samenvatting van de openstaande kritieke problemen in repo northwind/logistics-core" — van agent naar GitHub en terug:

‍

Drie eigenschappen van dit proces zijn belangrijk. De agent ontvangt het GitHub-access-token nooit; alleen de gateway beheert dit token. De MCP-server ziet het inkomende TrueFoundry-gegeven van Northwind nooit, tenzij Token Passthrough expliciet is geconfigureerd (zie paragraaf 7). En het securityteam van Northwind beschikt over één gecontroleerd verzoekpad waarin identiteit, autorisatie en audit-gegevens op één plek worden vastgelegd — de functionaliteit waarmee de vraag op maandagochtend ("welke scopes stonden er op die laptop?") binnen een minuut beantwoord had kunnen worden.

De MCP authorization specification bevestigt een belangrijk onderdeel van deze opzet: bearer access tokens moeten worden meegestuurd in de Authorization request header en nooit in een URI query string. Die afspraak zorgt ervoor dat tokens niet terechtkomen in access logs, browsergeschiedenis en proxy-traces.

6. Integratie met de Credential Vault: Waarom ruwe geheimen nooit in het applicatiegeheugen komen

Een gateway in een productieomgeving moet OAuth-refresh-tokens niet behandelen als standaard applicatiegegevens. Client secrets en refresh-tokens bieden langdurige toegang tot systemen — het lekken van een Slack refresh-token is in de praktijk vergelijkbaar met het lekken van de gehele Slack-workspace.

De standaardaanpak hiervoor is envelope encryption. De gateway genereert een willekeurige data encryption key (DEK) voor elk token-record, versleutelt het OAuth-geheim met die DEK, versleutelt de DEK met een hoofdsleutel in een KMS of secret manager, en slaat de versleutelde DEK samen met de ciphertext op. Bij het uitlezen vraagt de gateway de vault om alleen de DEK te ontsleutelen, waarna het token wordt ontsleuteld in een afgeschermd onderdeel van de code dat loggen of het tonen van onversleutelde tekst voorkomt.

Bij strenger beveiligde omgevingen kan de tokenuitwisseling zelf worden verplaatst naar een sidecar of een vault transit operation, zodat de applicatiecode nooit rechtstreeks met het client_secret werkt. Zelfs met standaard envelope encryption vermindert de risico-impact aanzienlijk: een kopie van de database alleen is onvoldoende (de DEK's worden niet onversleuteld opgeslagen), en een geheugendump van een server bevat minder snel volledige inloggegevens (alleen de recent opgevraagde sleutels worden ontsleuteld, en uitsluitend voor de duur van het verzoek).

De omgeving van Northwind maakt gebruik van AWS KMS als opslag voor de hoofdsleutel en de TrueFoundry secrets store voor het versleutelde materiaal. De gateway leest een client_secret van een provider nooit rechtstreeks uit; het leest de FQN van een TrueFoundry-geheim, haalt de ciphertext op en verzoekt KMS om deze te ontsleutelen. De aanvullende configuratie — zoals het beleid voor KMS-sleutelrotatie, het bewaren van audit-logs en operationele handleidingen — valt onder het beheer van de organisatie die de gateway gebruikt.

7. Token Passthrough vs. Token Forwarding: Uitzonderingen en wanneer u ze gebruikt

Twee patronen lijken op elkaar, maar hebben verschillende gevolgen voor de beveiliging. Het is belangrijk om deze goed te onderscheiden, omdat verkeerd gebruik het nut van de gateway grotendeels tenietdoet.

Token Passthrough is geschikt voor interne MCP-servers die hetzelfde identity token van de organisatie valideren als het token dat door de gateway bij de inkomende stroom is gecontroleerd. De Logistics API van Northwind is hier een voorbeeld van: de gateway en de API vertrouwen allebei de Okta-omgeving van het bedrijf, waardoor het doorsturen van de Okta JWT de identiteit van de aanroeper door de hele keten behoudt. Het risico hierbij is token audience confusion: een token dat is aangemaakt voor de gateway mag niet automatisch geldig zijn voor elke MCP-server. RFC 8707 (Resource Indicators) is ontwikkeld om tokens te koppelen aan een specifieke bron, en de MCP-autorisatiespecificatie vereist nu dat clients een resource-parameter meesturen en dat servers controleren of de ontvangen tokens voor hen zijn uitgegeven.

Token Forwarding werkt anders. De x-tfy-mcp-headers-header van TrueFoundry bevat een JSON-tekenreeks op basis van het ID van de externe MCP-server in <group>/<server>-indeling. Dit is het exacte formaat uit de Virtual MCP Server docs:

Gebruik Token Forwarding als een noodoplossing en niet als standaardinstelling. De meerwaarde van de gateway ligt juist in het automatische tokenbeheer dat bij deze optie wordt overgeslagen.

8. Latency Benchmarks: De impact van tokenbeheer op elke tool call

Een gateway voert extra stappen uit voor het afhandelen van de uitgaande MCP-aanroep: inkomende auth-validatie, beleidscontrole, tokencontrole en incidenteel het verversen van een token. In een goed ingerichte omgeving is de standaardstroom een cache-hit — de metadata van het token is geldig en de versleutelde tokenreferentie is direct beschikbaar in het geheugen.

Inschatting per scenario

Op basis van de bovenstaande kosten per onderdeel voegt de gateway ongeveer het volgende toe:

Hieruit volgen twee conclusies. Ten eerste is het normale proces een cache-hit. Met enkele milliseconden is de vertraging niet merkbaar in vergelijking met de aanroep naar het LLM (meestal honderden milliseconden tot seconden) en de achterliggende MCP-server (tientallen tot honderden milliseconden). Ten tweede komt het scenario met een cache-miss én refresh zelden voor, maar het heeft voldoende invloed om rekening mee te houden bij hoge belasting. Dit is de reden waarom in paragraaf 4 proactief verversen op 80% van de TTL met een vergrendeling per (gebruiker, server) wordt beschreven. Door proactief te verversen merken gebruikers deze vertraging in de praktijk niet; de gateway heeft van tevoren al een nieuw token opgehaald.

Het blijft verstandig om server-timing headers, de duur van het token-eindpunt, de wachttijd voor vergrendelingen, de ontsleutelingstijd in de vault en de vertraging van de achterliggende MCP-server apart te meten. Het doel is vast te stellen dat tokenbeheer niet de grootste vertraging veroorzaakt in de keten. De bovenstaande schattingen tonen aan dat dit zelden het geval is, maar dit moet per situatie en per provider worden gecontroleerd.

De technische oplossing voor een cache-miss is background refresh. Zodra de gateway ziet dat een token de drempel van 80% bereikt, ververst deze het token eenmalig tijdens het verzoek en plant de daaropvolgende vernieuwingen in voordat gebruikers er hinder van ondervinden. Bij veelgebruikte Client Credentials-integraties verdwijnt de merkbare vertraging door het verversen hiermee vrijwel volledig. Bij Authorization Code-integraties per gebruiker kan het systeem prioriteit geven aan actieve gebruikers en veelgebruikte MCP-servers.

Voor en na: de beveiligingssituatie bij Northwind

9. Veelgestelde vragen (FAQ's)

Is OAuth op de MCP-laag verplicht?

Nee. De MCP authorization specification maakt autorisatie optioneel, maar op HTTP gebaseerde implementaties die het ondersteunen, moeten voldoen aan de specificatie. In de praktijk moeten ondernemingen met een omvangrijk tool-landschap auth centraliseren lang voordat ze het als strikt verplicht beschouwen.

Moet elke MCP server 3LO gebruiken?

Nee. Gebruik Authorization Code (3LO) wanneer de agent handelt namens de resources van een menselijke gebruiker — Slack, GitHub, Gmail, CRM-tools. Gebruik Client Credentials (2LO) wanneer de downstream server de applicatie of gateway als zichzelf authenticeert. Het mengen van beide binnen één Virtual MCP Server is normaal en te verwachten.

Elimineert een gateway permissies aan de providerzijde?

Nee. Het vult ze aan. Slack, GitHub, Google en interne API's handhaven nog steeds hun eigen scopes en resourcepermissies. De gateway voegt daar een grovere, snellere beleidslaag bovenop toe — op serverniveau, toolniveau, teamniveau — en een uniform audit trail over alle systemen heen.

OAuth 2.0 of OAuth 2.1?

De TrueFoundry gateway ondersteunt de OAuth 2.0-grants die real-world providers vandaag ondersteunen: Authorization Code (met PKCE), Client Credentials en refresh tokens. De MCP authorization specification richt zich zelf op OAuth 2.1, wat grotendeels OAuth 2.0 is plus de security best practices die al als verplicht worden beschouwd in moderne implementaties (overal PKCE, geen implicit grant, geen password grant). Voor praktische doeleinden komen de twee overeen; we volgen de OAuth 2.1-richtlijnen waar deze het gedrag aanscherpen.

Hoe zit het met de nieuwere MCP-specificatie van 2025-11-25?

De herziening van november 2025 voegt verplichte PKCE toe voor alle clients, formaliseert Client ID Metadata Documents (CIMD) als de geprefereerde clientregistratiemethode en introduceert step-up authorization voor incrementele scope-toestemming. Deze scherpen de beveiliging aan zonder de architectuur in deze post ongeldig te maken. We volgen deze ontwikkelingen en rollen ondersteuning in zodra deze volwassen wordt in het ecosysteem.

Waar past TrueFoundry in dit plaatje?

De TrueFoundry MCP Gateway is een productie-implementatie van deze architectuur: een gecentraliseerd serverregister, configureerbare inkomende auth, toegangsbeheer, meerdere uitgaande auth-modi en beheer van de token-levenscyclus. Deze post beschrijft het ontwerp; de Authentication and Security docs vormen de operationele referentie. Voor de implementatiepatronen die hier worden behandeld, zie ook de documentatie over Auth Overrides en Virtual MCP Server.

Neem de volgende stap

Als u een platform-, security- of AI infrastructure leader bent die MCP op serieuze schaal draait, is de actie met de hoogste impact het inventariseren van elke actieve MCP server, het koppelen van elk exemplaar aan het juiste inkomende, beleids- en uitgaande auth-model, en het bepalen waar centralisatie echt winst oplevert. De inventarisatie van Northwind kostte twee middagen; de migratie zelf vergde een enkele sprint. We lopen deze oefening graag met uw team door.

Lees de architectuur: TrueFoundry MCP Gateway authentication and security. Of boek een enterprise security architecture review met ons team.

Verder lezen

Alle citaten in deze post zijn inline gelinkt. De onderstaande referenties verzamelen dezelfde URL's voor afdrukbaarheid en als beveiliging tegen link-rot.

• TrueFoundry MCP Gateway overview. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-overview
• TrueFoundry MCP Gateway authentication and security. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-gateway-auth-security
• TrueFoundry Auth Overrides. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-server-auth-overrides
• TrueFoundry Virtual MCP Server. https://www.truefoundry.com/docs/ai-gateway/mcp/virtual-mcp-server
• TrueFoundry using MCP Gateway in your agent. https://www.truefoundry.com/docs/ai-gateway/mcp/use-mcp-gateway-in-agent
• TrueFoundry Identity Providers. https://www.truefoundry.com/docs/platform/identity-providers
• TrueFoundry Secret Manager in AI Gateway. https://www.truefoundry.com/docs/ai-gateway/secret-manager-in-ai-gateway
• TrueFoundry Environment Variables and Secrets (tfy-secret:// FQN format). https://www.truefoundry.com/docs/environment-variables-and-secrets
• TrueFoundry Using tfy apply (provider-account / integrations YAML pattern). https://docs.truefoundry.com/docs/using-tfy-apply
• Okta Concurrency Limits (API response time guidance). https://developer.okta.com/docs/reference/rl2-concurrency/
• WorkOS: RS256 vs HS256 (JWT verification benchmarks). https://workos.com/blog/rs256-vs-hs256-jwt-signing-algorithms
• AWS KMS documentation (decrypt latency guidance). https://aws.amazon.com/kms/faqs/
• Model Context Protocol authorization specification, 2025-06-18. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• RFC 6749: The OAuth 2.0 Authorization Framework. https://datatracker.ietf.org/doc/html/rfc6749
• RFC 8707: Resource Indicators for OAuth 2.0. https://datatracker.ietf.org/doc/rfc8707/
• RFC 9728: OAuth 2.0 Protected Resource Metadata. https://datatracker.ietf.org/doc/html/rfc9728/

Opmerking: Northwind Logistics is een fictief bedrijf dat is gebruikt om het ontwerp in een concrete implementatie te verankeren. Het configuratiemodel in §3 is ter illustratie; productie MCP servers worden geregistreerd via de TrueFoundry UI of toegepast via tfy apply.

‍