MCP Authentication, Explained: Inbound Identity, Outbound Credentials, and Delegation

Het token dat een caller identificeert bij een gateway en het credential dat wordt gebruikt om een downstream service te bereiken, lossen verschillende problemen op. Veilige MCP-systemen behouden dat onderscheid.

Authenticatie is niet één hop

Een MCP-verzoek kan verschillende trust boundaries doorkruisen voordat een bedrijfssysteem het ziet. Een persoon of service authenticeert bij een applicatie. Een agent kan handelen als een afzonderlijke software principal. De client authenticeert bij MCP Gateway. De gateway beslist of die caller een server of tool mag gebruiken. Vervolgens authenticeert de gateway bij de downstream MCP server, die een andere geautoriseerde service kan aanroepen.

Het gebruik van het woord “token” voor elk credential laat deze grenzen verdwijnen. Het inbound credential beantwoordt wie de gateway aanroept. Access policy beantwoordt welke gateway-resources die identiteit mag gebruiken. Outbound authenticatie bepaalt wiens credentials en permissies de downstream server ontvangt. Die antwoorden kunnen bewust van elkaar verschillen.

De documentatie van TrueFoundry splitst de architectuur op in inbound authenticatie, access control en outbound authenticatie. Die scheiding is het juiste vertrekpunt voor het redeneren over delegatie, attributie en confused-deputy-risico's.

De gateway is bewust opgesplitst in drie controles. Succesvolle inbound authenticatie identificeert een caller, maar het access policy selecteert nog steeds toegestane tools en outbound authenticatie bepaalt nog steeds de principal die door de MCP server wordt gezien.

Inbound authenticatie achterhaalt de gateway caller

TrueFoundry documenteert verschillende inbound methoden: een personal access token voor gebruikers met TrueFoundry-accounts, een virtual-account token voor service-to-service callers, een identity-provider token voor klanten of services die de JWT-issuer van een organisatie gebruiken, en TrueFoundry OAuth voor compatibele IDE-clients.

Na het valideren van het credential achterhaalt de gateway een TrueFoundry-identiteit en past het access control toe op MCP servers en individuele tools. De relevante identiteit kan een gebruiker, team of virtual account zijn. Agent Identity, gedocumenteerd als beta, voegt een afzonderlijke geregistreerde agent actor toe voor verzoeken die vanuit een agent zijn geïnitieerd. Dat is anders dan een virtual account, dat een service of applicatie vertegenwoordigt zonder een mens erachter.

Identiteitsresolutie moet de issuer, audience, handtekening, tijdsgrenzen en de claim mapping valideren die wordt gebruikt om het subject te selecteren. Een geldig ondertekend token voor de verkeerde audience is geen autoriteit voor de gateway. Mappings moeten specifiek genoeg zijn zodat twee services niet per ongeluk naar dezelfde agent identity leiden.

Outbound authenticatie selecteert de downstream principal

De gateway kan bij een MCP server authenticeren met behulp van per-user OAuth authorization code, OAuth client credentials op applicatieniveau, de gedocumenteerde Okta token-exchange/OBO-configuratie, gedeelde of individuele API keys, geen authenticatie voor openbare services, token passthrough, token forwarding of AWS SigV4 voor ondersteunde AWS-eindpunten.

Deze modi verankeren verschillende autoriteiten. Met per-user OAuth kan elke persoon zijn eigen account van derden autoriseren. Client credentials vertegenwoordigen de applicatie en stellen meestal gedeelde servicepermissies beschikbaar. Token-exchange of OBO vraagt een identiteitssysteem om een downstream token aan te maken dat is afgeleid van de identiteit van de caller en gericht is op een andere audience. Een gedeelde API key voegt alle callers samen tot één upstream principal, zelfs als de gateway interne attributie behoudt.

Het kiezen van de eenvoudigste integratie kan het autorisatiemodel stilzwijgend veranderen. Als een Gmail MCP server één gedeelde service-credential gebruikt, ziet de upstream de autoriteit van de persoonlijke mailbox van elke werknemer niet. Als een interne MCP server het IdP-token van de organisatie rechtstreeks valideert, kan passthrough het subject behouden — maar alleen als issuer, audience en scopes bewust worden geaccepteerd.

Het diagram groepeert modi op basis van autoriteitssemantiek in plaats van protocollabels. Per-user en OBO-stromen kunnen subject-context behouden, terwijl client credentials en gedeelde sleutels applicatie-autoriteit vertegenwoordigen, tenzij de downstream service aanvullende subject-bewuste controles toepast.

Passthrough en forwarding zijn geen synoniemen

In de gedocumenteerde terminologie van TrueFoundry stuurt token passthrough hetzelfde token dat voor inbound authenticatie is gebruikt door naar de MCP server. De server moet dat TrueFoundry- of identity-provider-token kunnen valideren. Token forwarding draagt afzonderlijke serverspecifieke credentials over die door de client in specifieke headers worden aangeleverd. Het outbound credential is niet de inbound bearer.

Dit onderscheid is van belang voor logging, redactie, intrekking en threat modeling. Passthrough behoudt één credential over de gateway-grens heen en vereist daarom het juiste downstream audience-vertrouwen. Forwarding introduceert een ander geheim dat de client moet verkrijgen en beschermen. Geen van beide bewijst automatisch dat een uiteindelijke zakelijke API de beoogde relatie tussen mens en agent heeft gezien.

OAuth token exchange en OBO bieden een ander patroon: de gateway of identiteitslaag verkrijgt een nieuw audience-specifiek token dat gedelegeerde autoriteit vertegenwoordigt. Dat kan het hergebruik van bearer-tokens verminderen en downstream systemen in staat stellen scopes af te dwingen die zijn ontworpen voor hun resource. De exacte garanties hangen af van de identity provider, claims, validatie en de downstream applicatie.

Modelleer de principals, niet alleen de headers

Voorkom de confused deputy

Een gateway wordt een confused deputy wanneer deze een brede downstream autoriteit heeft en deze gebruikt voor een caller die de overeenkomstige permissie mist. Inbound authenticatie kan volkomen geldig zijn, terwijl de samengestelde actie toch over-geautoriseerd is. De gateway moet de identiteit van de caller, de agent identity, de gevraagde server en tool, de outbound credential mode en de downstream scope samenvoegen.

Voor gedeelde credentials moet de MCP server of achterliggende applicatie voldoende vertrouwde context ontvangen om subject-bewuste autorisatie opnieuw toe te passen, of de tool mag alleen resources beschikbaar stellen die veilig zijn voor elke toegestane caller. Vertrouw er niet op dat het model resultaten filtert na een brede query. Controleer bij per-user credentials of de autorisatie gekoppeld is aan het beoogde subject en niet door een andere gebruiker kan worden vervangen via overrides.

Elke hop moet ook een audit-correlatie-ID behouden zonder bearer-tokens naar logs te kopiëren. Leg de credential mode, achterhaalde identiteit, issuer, audience, scope class, policy-versie en metadata van het downstream antwoord vast. Geheime waarden horen thuis in beschermde opslagruimten, niet in transcripties of traces.

De keten draagt zowel een menselijk subject als een software-actor door de gateway-beslissing. De outbound modus kan die identiteitscontext behouden, uitwisselen of samenvouwen; het downstream systeem voert nog steeds de uiteindelijke autorisatie voor resources en acties uit.

Een uitgewerkt voorbeeld: CRM-toegang voor klantenservice

Een supportmedewerker ontvangt een verzoek van een geauthenticeerde werknemer. De applicatie stuurt het identity-provider-token van de werknemer naar MCP Gateway en presenteert afzonderlijk de geregistreerde agent identity. Het gateway-beleid staat dat gebruiker-agent-paar toe om de CRM-zoektool aan te roepen.

Stel dat de uitrol gebruikmaakt van de gedocumenteerde Okta OBO-configuratie van TrueFoundry. De gateway wisselt het inbound gebruikerstoken in voor een CRM-audience-token met een read-only case scope. Het CRM valideert het nieuwe token en past zijn eigen autorisatie op rijniveau toe. De agent kan de toegestane cases van de werknemer ophalen, maar kan ze niet wijzigen. Een afzonderlijke update-tool vereist een bekendere downstream scope en goedkeuring.

Als de uitrol in plaats daarvan een gedeelde API key gebruikt, moet de architectuur dit compenseren. De service die gericht is op het CRM ontvangt een vertrouwd, achterhaald subject-attribuut van de gateway, valideert dit en filtert records aan de serverzijde. Als de service de subject-context niet kan afdwingen, is de gedeelde sleutel ongeschikt voor gegevens met gebruikersspecifieke autorisatie.

Kies outbound auth op basis van autoriteitssemantiek

• Gebruik per-user autorisatie wanneer de upstream resource het eigendom is van of geautoriseerd is door elke persoon afzonderlijk.
• Gebruik client credentials voor resources die echt eigendom zijn van de applicatie, niet als een snelkoppeling om gebruikersautorisatie te omzeilen.
• Gebruik token exchange of OBO wanneer de downstream een gedelegeerd, audience-specifiek gebruikerstoken nodig heeft.
• Gebruik passthrough alleen wanneer de downstream het inbound token bewust vertrouwt en valideert.
• Gebruik forwarding wanneer de MCP server een afzonderlijk credential-schema heeft en accepteer de bijbehorende last voor het afhandelen van clientgeheimen.
• Behandel no-auth servers als openbare functionaliteiten; plaats geen gevoelige gegevens of mutaties erachter.

Fouttests voor de auth-keten

• Speel een geldig token opnieuw af met de verkeerde audience, issuer, tenant of gemapte subject.
• Houd de gebruiker constant en verander de agent identity; controleer of het effectieve bereik van de tool verandert zoals ontworpen.
• Houd de agent constant en verander de gebruiker; controleer of de downstream gegevens het menselijke subject volgen waar vereist.
• Vervang een individueel credential via de auth override van een andere gebruiker.
• Trek een gateway-toekenning en een upstream OAuth-toekenning onafhankelijk van elkaar in; controleer hun verschillende effecten.
• Roep de MCP server aan buiten de gateway om; controleer of het netwerk- en serverbeleid een bypass voorkomen wanneer dat vereist is.
• Inspecteer logs, traces, fouten en modelcontext op gelekte bearer-tokens of doorgestuurde geheimen.

De levenscyclus van credentials maakt deel uit van het datapad

Het ontwerp van de authenticatie gaat door nadat een token is geaccepteerd. Credentials verlopen, verversen, roteren en worden ingetrokken bij verschillende systemen. De documentatie van TrueFoundry merkt bijvoorbeeld op dat de actie "Revoke all tokens" opgeslagen credentials verwijdert uit AI Gateway, maar toekenningen bij de upstream OAuth-provider niet intrekt. Beheerders hebben afzonderlijke procedures nodig voor de gateway-credential, de identity-provider-sessie, de upstream autorisatie en elk gecached downstream token.

Definieer welk onderdeel elk credential ververst, welk subject het ververse token vertegenwoordigt en wat er gebeurt als het verversen halverwege een agent-taak mislukt. Een gepauzeerde autorisatiestroom mag niet stilzwijgend terugvallen op een applicatie-credential met bredere toegang. Wanneer de gebruiker opnieuw verbinding maakt met een account, moet de nieuwe toekenning worden gecorreleerd met het beoogde subject en de beoogde server voordat de agent doorgaat.

Rotatie creëert een nieuwe testgrens. Gedeelde API keys hebben mogelijk een periode met twee sleutels nodig; per-user OAuth-tokens kunnen onafhankelijk ongeldig worden gemaakt; OBO-tokens kunnen worden gecached tot ze verlopen, terwijl het inbound token actueel moet blijven voor het opnieuw uitwisselen. Sla identifiers voor credential modes en token-families op in beschermde operationele metadata, zodat responders betrokken verzoeken kunnen vinden zonder geheimen bloot te stellen.

Het intrekken moet van buiten naar binnen worden gecontroleerd. Verwijder de gateway-collaborator, trek de upstream toekenning in, schakel het downstream account uit en test elk effect afzonderlijk. Een volledige incidentprocedure weet welke actie nieuwe gateway-verzoeken stopt, welke directe toegang ongeldig maakt en welke alleen een lokale kopie verwijdert.

Het afhandelen van tokens moet ook afwezig zijn in de context die zichtbaar is voor het model. Agents kunnen redeneren over stabiele identiteitslabels, autorisatieresultaten en instructies voor het opnieuw verbinden zonder bearer-materiaal te ontvangen. Fouten die door providers worden geretourneerd, moeten worden genormaliseerd, zodat debug-output geen headers, refresh tokens, client secrets of ondertekende verzoekonderdelen naar de transcriptie lekt.

De operationele regel

Veilige MCP-authenticatie begint met het benoemen van elke principal en hop. Inbound identity, gateway access, outbound credential en zakelijke autorisatie zijn gerelateerde maar niet-inwisselbare controles. Het veiligste ontwerp maakt elke verandering van principal of audience expliciet.

TrueFoundry MCP Gateway biedt gedocumenteerde mechanismen voor elke op de gateway gerichte laag, en Agent Identity — gedocumenteerd als beta op de governance availability map — kan de software-actor onderscheiden van het menselijke subject. De downstream applicatie blijft eigenaar van haar domeinautorisatie en de organisatie blijft eigenaar van credential-minimalisatie. Die grens is geen beperking in de uitleg; het is wat het beveiligingsmodel testbaar maakt.

Referenties

1. TrueFoundry — MCP Gateway Authentication and Security.
2. TrueFoundry — Agent Identity.
3. TrueFoundry — MCP Gateway Overview.
4. IETF RFC 8693 — OAuth 2.0 Token Exchange.

Redactionele vermelding. Dit artikel weerspiegelt de engineering-interpretatie van TrueFoundry van de geciteerde openbare materialen per 17 september 2026. Productfunctionaliteiten zijn beperkt tot de gekoppelde documentatie. Voorbeelden en operationele standaarden zijn illustratief; ze zijn geen juridisch advies, een audit-oordeel, een onafhankelijke benchmark of een garantie voor beveiliging, veiligheid of compliance.

‍