Cross App Access op de TrueFoundry MCP Gateway: Identiteitsgestuurde Agent-toegang, Aangedreven door Uw IdP

AI-agents worden snel de universele afstandsbediening voor zakelijk werk. Ze lezen uit Jira, schrijven naar Slack, bevragen het datawarehouse, openen pull requests en koppelen een dozijn tools aan elkaar om een enkele taak te voltooien. Het Model Context Protocol (MCP) maakt dit mogelijk — het geeft agents een standaardmanier om die tools te ontdekken en aan te roepen.

Maar MCP beantwoordt hoe een agent met een tool praat. Het beantwoordt niet de vraag die elk securityteam stelt: welke agents mogen welke systemen bereiken, namens wie, met welk bereik — en wie kan dat inzien en intrekken?

Dat gat is precies wat Cross App Access (XAA) dicht. En het sluit vrijwel naadloos aan op waar een MCP gateway voor is gebouwd. Dit artikel legt uit wat XAA is, waarom het belangrijk is en hoe de TrueFoundry MCP Gateway het implementeert — waardoor uw identity provider het controle-element wordt voor elke agent-naar-tool-verbinding binnen uw organisatie.

Het probleem: agent-verbindingen vinden plaats buiten de identiteitsperimeter

Wanneer een gebruiker vandaag de dag een MCP-client (een AI-app zoals Claude, Cursor of VS Code) verbindt met een MCP-server (Slack, Atlassian, een interne service), vindt de autorisatie-handshake meestal rechtstreeks tussen die twee apps plaats. Het patroon ziet eruit als een van de volgende twee dingen, en beide zijn problematisch op ondernemingsschaal:

• Statische inloggegevens en API-sleutels. Langdurig geldig, vaak met te brede rechten, verspreid over laptops en configuratiebestanden. Ze worden zelden geroteerd en bijna nooit netjes ingetrokken. Elke sleutel vormt een permanent privilege en een risicobron.
• OAuth-toestemming per gebruiker. Beter dan ruwe sleutels, maar het toont de gebruiker een toestemmingsscherm voor elke tool, elke client, elke keer weer. De corporate IdP heeft de gebruiker geauthenticeerd in de app — maar heeft nooit de relatie tussen de AI-client en de tool geautoriseerd. Vanuit het perspectief van de IdP is die machtiging onzichtbaar.

Het resultaat is shadow AI: een wildgroei van onbeheerde agent-naar-app-verbindingen die IT- en securityteams noch kunnen inventariseren, noch kunnen beheren. Admins kunnen de vraag "welke AI-clients kunnen in Atlassian handelen als deze gebruiker, en met welke rechten?" niet beantwoorden — en ze kunnen het niet op één centrale plek uitschakelen wanneer een medewerker of agent wordt uitgestroomd.

TrueFoundry lost een groot deel hiervan al op door MCP-toegang te centraliseren via een enkele beheerde gateway — één toegangspunt, RBAC tot op toolniveau, een beveiligde kluis voor inloggegevens en een volledige audit trail. XAA dicht het laatste gat: het plaatst de identity provider zelf terug in de autorisatiebeslissing, zodat dezelfde policy's die de rest van uw stack beheren, nu ook uw agents beheren.

Wat Cross App Access daadwerkelijk is

Cross App Access (XAA) is een uitbreiding van OAuth 2.0 waarmee een enterprise identity provider de verbinding tussen twee applicaties kan bemiddelen en goedkeuren — in plaats van dat die twee apps rechtstreeks een vertrouwensrelatie opbouwen. Het werd in juni 2025 geïntroduceerd door Okta, in september 2025 overgenomen door de IETF OAuth Working Group en in november 2025 opgenomen in MCP als de autorisatie-uitbreiding genaamd Enterprise-Managed Authorization (EMA). Die uitbreiding bereikte in juni 2026 de stabiele status.

Een korte noot over de terminologie, aangezien u beide namen in de praktijk zult tegenkomen:

• ID-JAG — de Identity Assertion JWT Authorization Grant — is de leveranciersneutrale OAuth-uitbreiding die wordt gestandaardiseerd bij de IETF. Het is de technische blauwdruk: hoe een IdP een ondertekende identiteitsbewering (identity assertion) uitgeeft, welke claims deze bevat en hoe een app deze inwisselt.
• XAA is de productnaam van Okta voor de implementatie van ID-JAG, en de term die de meeste mensen als eerste tegenkomen. In MCP wordt hetzelfde mechanisme aangeboden als de Enterprise-Managed Authorization-uitbreiding.

We gebruiken overal "XAA", maar het belangrijke punt is dat dit een open standaard is. Elke IdP kan ID-JAG implementeren, en elke MCP-server, -client of -gateway kan het ondersteunen.

De drie rollen

XAA definieert een duidelijke scheiding van verantwoordelijkheden:

De stroom (flow)

De magie van XAA is dat het de handmatige toestemmingsstap per app vervangt door een door policy's beheerde token exchange die door de IdP wordt bemiddeld:

Omdat de resource-app de ondertekeningssleutels van de IdP al vertrouwt vanuit SSO, is er geen nieuwe vertrouwensinfrastructuur nodig. De IdP dwingt de policy één keer af, geeft kortstondige tokens met een beperkt bereik uit en registreert elke toewijzing — en de gebruiker ziet nooit een toestemmingsscherm. Autorisatiebeslissingen verschuiven van de applicatielaag naar de identiteitslaag, waar ze auditeerbaar en intrekbaar zijn.

Hoe TrueFoundry XAA implementeert

Een MCP gateway is de ideale plek om XAA te implementeren, omdat de gateway zich al bevindt op het exacte punt waar de requesting app de resource app ontmoet. De authenticatie-architectuur van TrueFoundry is gebouwd op een bewuste scheiding van inkomende authenticatie (hoe clients hun identiteit bewijzen aan de Gateway) en uitgaande authenticatie (hoe de Gateway stroomafwaartse MCP-servers bereikt). Die scheiding is precies de vorm die XAA nodig heeft.

TrueFoundry ondersteunt XAA waarbij de Gateway de rol van requesting app op zich neemt. Dit is de kernstroom:

De agent stuurt zijn Okta-token; de Gateway voert de exchange uit

De agent-applicatie authenticeert de gebruiker één keer met Okta en ontvangt een Okta-token. Vanaf dat moment geeft het bij elk verzoek simpelweg dat token door aan de Gateway — het hoeft XAA niet zelf te implementeren of eigen beweringsbewijzen te verkrijgen. De Gateway regelt de rest:

1. Valideert het Okta-token en herleidt dit naar een TrueFoundry-identiteit (gebruiker, team of virtueel account) met behulp van de bestaande Identity Provider-configuratie en Okta-groep → team-mapping, en dwingt vervolgens RBAC/ABAC op toolniveau af.
2. Voert de token exchange uit met Okta en vraagt om een ID-JAG-bewering die specifiek is afgestemd op de MCP-server die de agent probeert te bereiken. Okta evalueert het XAA-beleid en retourneert de afgestemde bewering — zonder aanvullende toestemming of autorisatieprompt voor de gebruiker.
3. Wisselt de bewering in voor een kortstondig accesstoken met beperkte doelgroep voor die MCP-server.
4. Roept de MCP-server aan met het afgestemde token en streamt het resultaat terug naar de agent.

De gebruiker meldt zich één keer aan bij de agent-applicatie. Ze zien nooit een OAuth-toestemmingsscherm per server, en de agent heeft nooit permanente inloggegevens voor stroomafwaartse tools.

Dit bouwt rechtstreeks voort op het bestaande inkomende authenticatiemodel van TrueFoundry (Identity Provider tokens en Token Passthrough), waarbij de Gateway optreedt als de XAA requesting app — de token exchange uitvoert en elke bewering afstemt op de specifieke server in kwestie.

Overbrugging van MCP-servers die geen XAA spreken (de onderscheidende factor)

De meeste MCP-servers in de praktijk — interne services, tools met een OpenAPI-wrapper, servers van derden — implementeren XAA niet van nature, en vele zullen dat ook nooit doen. Dit is waar een gateway zijn waarde bewijst.

Omdat de Gateway de identiteitsstroom centraal afhandelt, kan deze XAA-governance plaatsen voor elke MCP-server, ongeacht of de server de standaard ondersteunt. Zodra aan de policy is voldaan en er een afgestemd token beschikbaar is, bemiddelt de Gateway de stroomafwaartse verbinding met behulp van het protocol dat die server daadwerkelijk begrijpt — OAuth 2.0 per gebruiker, client credentials, een gedeelde API-sleutel uit de beveiligde kluis, token passthrough of aangepaste headers. De MCP-server krijgt enterprise-beheerde autorisatie met de IdP in de keten zonder een enkele regel token-exchange-code te schrijven, en u krijgt één consistent XAA-controlepunt over uw gehele tool-landschap in plaats van een lapjesdeken van "XAA-ready" en "legacy" servers.

XAA koppelen aan functionaliteiten die TrueFoundry al biedt

Hoe het er in de praktijk uitziet

Neem een ontwikkelaar die Cursor vraagt een incident te analyseren: verzamel de gerelateerde Atlassian-tickets, bekijk de relevante Slack-thread en vat de deployment-historie samen.

1. De ontwikkelaar meldt zich één keer aan bij de agent-applicatie via Okta SSO, en de agent ontvangt een Okta-token.
2. De agent stuurt dat Okta-token bij elk verzoek naar de TrueFoundry Gateway. Wanneer Atlassian nodig is, valideert de Gateway het token, bevestigt dat het team van de ontwikkelaar de Atlassian MCP-server mag bereiken (en alleen de lees-tools waar ze recht op hebben), en voert de token exchange uit met Okta — waarbij wordt gevraagd om een bewering die is afgestemd op die server. Okta controleert de policy — mag de groep van deze ontwikkelaar een AI-client toegang geven tot Atlassian? — en retourneert de afgestemde bewering. Geen toestemmings-popup.
3. De Gateway wisselt de bewering in voor een kortstondig accesstoken met beperkt bereik en bemiddelt de aanroep naar Atlassian.
4. Elke actie komt terecht in het auditlogboek van TrueFoundry, toegewezen aan de individuele identiteit en de specifieke agent.
5. Wanneer die ontwikkelaar het team verlaat, deactiveert IT de gebruiker in Okta. Hun toegang — en die van hun agent — tot elke MCP-server achter de Gateway wordt ingetrokken via dezelfde uitstroomprocedure die de rest van hun apps beheert.

Er zijn geen nieuwe sleutels aangemaakt. Er zijn geen permanente privileges achtergebleven. Security heeft de policy één keer beoordeeld, in Okta.

Waarom TrueFoundry + Okta

Okta verdeelt het XAA-ecosysteem in drie lagen: requesting apps (de clients en agents), resource apps (de tools die data bevatten) en de identiteitsinfrastructuur- en gatewaylaag die het verkeer daartussen routeert en beveiligd. TrueFoundry bevindt zich precies in die derde laag.

De combinatie is logisch en complementair:

• Okta is het controle-element (control plane). Het authenticeert gebruikers, evalueert welke apps mogen verbinden en geeft de ondertekende beweringen en kortstondige tokens uit die het beleid over domeinen heen overdragen.
• TrueFoundry is de handhavings- en connectiviteitslaag voor MCP. Het is de plek waar de beweringen worden ingewisseld, waar RBAC op toolniveau wordt toegepast, waar niet-XAA-servers worden geïntegreerd in de standaard, waar guardrails draaien en waar elke aanroep wordt gelogd.

Samen stellen ze een onderneming in staat om de doorslaggevende vraag in elke moderne AI-securitybeoordeling — "kunnen we dit beheren in onze IdP?" — te beantwoorden met een ondubbelzinnig ja: uw identity provider bepaalt welke AI-clients verbinden, met welke MCP-servers, met welke rechten, en u kunt het allemaal centraal intrekken.

Aan de slag

Als u TrueFoundry's MCP Gateway al gebruikt, breidt XAA-ondersteuning het authenticatiemodel dat u nu gebruikt uit — registreer Okta als Identity Provider, koppel Okta-groepen aan TrueFoundry-teams en breng uw MCP-servers (XAA-native of niet) onder bij één door identiteit beheerde toegangspoort.

Als u evalueert hoe u AI-agents op schaal kunt inzetten zonder te maken te krijgen met een wildgroei aan inloggegevens en shadow-AI-risico's, is dit de basis: op standaarden gebaseerd, door de IdP bemiddeld en gebouwd op de OAuth en OpenID Connect die u al vertrouwt.