Cross App Access sur la TrueFoundry MCP Gateway : accès agent gouverné par l'identité, propulsé par votre IdP

Les agents IA deviennent rapidement la télécommande universelle du travail en entreprise. Ils lisent depuis Jira, écrivent sur Slack, interrogent l'entrepôt de données, ouvrent des pull requests et enchaînent une douzaine d'outils pour accomplir une seule tâche. Le Model Context Protocol (MCP) est ce qui rend cela possible — il offre aux agents un moyen standard de découvrir et d'appeler ces outils.

Mais le MCP répond à la question de savoir comment un agent parle à un outil. Il ne répond pas à la question que toutes les équipes de sécurité posent désormais : quels agents sont autorisés à accéder à quels systèmes, pour le compte de qui, avec quel périmètre — et qui peut visualiser et révoquer cela ?

C'est exactement cette lacune que le Cross App Access (XAA) vient combler. Et cela correspond presque parfaitement au rôle pour lequel une passerelle MCP est conçue. Cet article explique ce qu'est le XAA, pourquoi il est important et comment la TrueFoundry MCP Gateway l'implémente — transformant votre fournisseur d'identité en plan de contrôle pour chaque connexion agent-outil dans votre organisation.

Le problème : les connexions des agents s'effectuent en dehors du périmètre d'identité

Aujourd'hui, lorsqu'un utilisateur connecte un client MCP (une application IA comme Claude, Cursor ou VS Code) à un serveur MCP (Slack, Atlassian, un service interne), le processus d'autorisation se déroule généralement directement entre ces deux applications. Ce modèle prend souvent l'une des deux formes suivantes, toutes deux problématiques à l'échelle de l'entreprise :

• Identifiants statiques et clés API. À longue durée de vie, souvent surdimensionnés en termes de permissions, dispersés sur des ordinateurs portables et dans des fichiers de configuration. Ils sont rarement renouvelés et presque jamais révoqués proprement. Chaque clé constitue un privilège permanent et une surface d'attaque potentielle.
• Consentement OAuth par utilisateur. Préférable aux clés brutes, mais cette méthode impose un écran de consentement à l'utilisateur pour chaque outil, chaque client et chaque tentative. L'IdP d'entreprise a authentifié l'utilisateur dans l'application — mais il n'a jamais autorisé la relation entre le client IA et l'outil. Du point de vue de l'IdP, cet accès est invisible.

Le résultat est une IA fantôme (shadow AI) : un réseau tentaculaire et non géré de connexions agent-application que les équipes IT et sécurité ne peuvent ni inventorier ni contrôler. Les administrateurs ne peuvent pas répondre à la question "quels clients IA peuvent agir dans Atlassian en tant que cet utilisateur, et avec quels périmètres ?" — et ils ne peuvent pas tout désactiver en un seul endroit lorsqu'un employé ou un agent est désactivé.

TrueFoundry résout déjà une grande partie de ce problème en centralisant l'accès MCP via une passerelle gouvernée unique — un point d'entrée unique, du RBAC jusqu'au niveau de l'outil, un coffre-fort d'identifiants sécurisé et un journal d'audit complet. Le XAA vient combler le dernier écart : il réintègre le fournisseur d'identité lui-même au cœur de la décision d'autorisation, de sorte que les mêmes politiques qui régissent le reste de votre infrastructure régissent désormais vos agents.

Ce qu'est réellement le Cross App Access

Le Cross App Access (XAA) est une extension d'OAuth 2.0 qui permet à un fournisseur d'identité d'entreprise de médiatiser et d'approuver la connexion entre deux applications — au lieu que ces deux applications établissent une confiance directe. Il a été introduit par Okta en juin 2025, adopté par le groupe de travail IETF OAuth en septembre 2025 et incorporé dans le MCP en novembre 2025 sous forme d'extension d'autorisation connue sous le nom d'Enterprise-Managed Authorization (EMA). Cette extension a atteint le statut stable en juin 2026.

Une brève remarque terminologique, car vous verrez ces deux noms sur le terrain :

• ID-JAG — l' Identity Assertion JWT Authorization Grant — est l'extension OAuth neutre vis-à-vis des fournisseurs, en cours de standardisation à l'IETF. C'est le modèle technique : comment un IdP émet une assertion d'identité signée, quelles revendications elle contient et comment une application la consomme.
• XAA est le nom commercial donné par Okta à son implémentation de l'ID-JAG, et le terme que la plupart des gens rencontrent en premier. Dans le MCP, le même mécanisme est présenté sous le nom d'extension Enterprise-Managed Authorization.

Nous utiliserons "XAA" tout au long de cet article, mais l'élément essentiel à retenir est qu'il s'agit d'un standard ouvert. N'importe quel IdP peut implémenter ID-JAG, et n'importe quel serveur, client ou passerelle MCP peut le prendre en charge.

Les trois rôles

Le XAA définit une séparation claire des responsabilités :

Le flux

La magie du XAA réside dans le fait qu'il remplace l'étape manuelle de consentement par application par un échange de jetons régi par des politiques et géré par l'IdP :

Puisque l'application ressource fait déjà confiance aux clés de signature de l'IdP via le SSO, aucune nouvelle infrastructure de confiance n'est nécessaire. L'IdP applique la politique une seule fois, émet des jetons à portée restreinte et à courte durée de vie, et enregistre chaque octroi d'accès — sans que l'utilisateur ne voie jamais d'invite de consentement. Les décisions d'autorisation passent de la couche application à la couche identité, où elles deviennent auditables et révocables.

Comment TrueFoundry implémente le XAA

Une passerelle MCP est l'endroit idéal pour intégrer le XAA, car la passerelle se trouve exactement à l'intersection entre l'application demandeuse et l'application ressource. L'architecture d'authentification de TrueFoundry a été conçue autour d'une séparation délibérée entre l'authentification entrante (comment les clients prouvent leur identité à la Gateway) et l'authentification sortante (comment la Gateway accède aux serveurs MCP en aval). Cette séparation correspond précisément à la structure requise par le XAA.

TrueFoundry prend en charge le XAA en confiant à la Gateway le rôle de Requesting App. Voici le flux principal.

L'agent envoie son jeton Okta ; la Gateway effectue l'échange

L'application agent authentifie l'utilisateur une seule fois auprès d'Okta et reçoit un jeton Okta. À partir de ce moment, elle transmet simplement ce jeton à la Gateway lors de chaque requête — elle n'a pas besoin d'implémenter le XAA elle-même ni d'obtenir ses propres assertions restreintes. La Gateway s'occupe du reste :

1. Valide le jeton Okta et le résout en une identité TrueFoundry (utilisateur, équipe ou compte virtuel) à l'aide de la configuration existante du fournisseur d'identité et du mappage groupes Okta → équipes, puis applique le RBAC/ABAC au niveau des outils.
2. Effectue l'échange de jetons avec Okta, en demandant une assertion ID-JAG spécifiquement dédiée au serveur MCP que l'agent tente d'atteindre. Okta évalue la politique XAA et retourne l'assertion ciblé — sans aucune invite de consentement ou d'autorisation supplémentaire pour l'utilisateur.
3. Échange l'assertion contre un jeton d'accès à courte durée de vie et restreint à ce serveur MCP spécifique.
4. Appelle le serveur MCP avec le jeton ciblé et transmet le résultat en continu (stream) à l'agent.

L'utilisateur se connecte une seule fois au niveau de l'application agent. Il ne voit jamais d'écran de consentement OAuth par serveur, et l'agent ne détient jamais d'identifiants permanents pour les outils en aval.

Ceci s'appuie directement sur le modèle d'authentification entrante existant de TrueFoundry (jetons Identity Provider et Token Passthrough), la Gateway agissant comme Requesting App XAA — en exécutant l'échange de jetons et en restreignant chaque assertion au serveur concerné.

Accéder aux serveurs MCP qui ne prennent pas en charge le XAA (le facteur différenciateur)

La plupart des serveurs MCP existants — services internes, outils enveloppés dans des API OpenAPI, serveurs tiers — n'implémentent pas le XAA de manière native, et beaucoup ne le feront jamais. C'est ici qu'une passerelle apporte toute sa valeur.

Étant donné que la Gateway centralise la gestion du flux d'identité, elle peut placer la gouvernance XAA devant n'importe quel serveur MCP, que ce serveur prenne en charge la norme ou non. Une fois la politique validée et le jeton sécurisé obtenu, la Gateway gère la connexion en aval en utilisant le protocole pris en charge par ce serveur — OAuth 2.0 par utilisateur, client credentials, une clé API partagée issue du coffre-fort sécurisé, le passage de jetons (token passthrough) ou des en-têtes personnalisés. Le serveur MCP bénéficie ainsi d'une autorisation régie par l'entreprise et intégrée à l'IdP sans avoir à écrire une seule ligne de code d'échange de jetons, et vous obtenez un point de contrôle XAA unique et cohérent sur l'ensemble de vos outils plutôt qu'un assemblage disparate de serveurs "compatibles XAA" et "hérités".

Mappage du XAA avec les fonctionnalités déjà intégrées à TrueFoundry

Ce que cela donne en pratique

Prenons l'exemple d'un développeur qui demande à Cursor de gérer un incident : récupérer les tickets Atlassian associés, vérifier le fil Slack correspondant et résumer l'historique de déploiement.

1. Le développeur se connecte une fois à l'application agent via le SSO Okta, et l'agent reçoit un jeton Okta.
2. L'agent envoie ce jeton Okta à la TrueFoundry Gateway lors de chaque requête. Lorsqu'il a besoin d'Atlassian, la Gateway valide le jeton, confirme que l'équipe du développeur a le droit d'accéder au serveur MCP Atlassian et uniquement aux outils de lecture autorisés, puis effectue l'échange de jetons avec Okta — en demandant une assertion dédiée à ce serveur. Okta vérifie la politique — le groupe de ce développeur est-il autorisé à laisser un client IA accéder à Atlassian ? — et retourne l'assertion restreinte. Aucune fenêtre contextuelle de consentement n'apparaît.
3. La Gateway échange l'assertion contre un jeton d'accès ciblé et à courte durée de vie, puis traite l'appel vers Atlassian.
4. Chaque action est enregistrée dans le journal d'audit de TrueFoundry, attribuée à l'identité individuelle et à l'agent spécifique.
5. Lorsque ce développeur quitte l'équipe, l'équipe IT le désactive dans Okta. Son accès — ainsi que celui de son agent — à l'ensemble des serveurs MCP placés derrière la Gateway est révoqué via le même flux de désactivation que celui qui régit le reste de ses applications.

Aucune nouvelle clé n'a été créée. Aucun privilège permanent n'a été conservé. L'équipe de sécurité n'a révisé la politique qu'une seule fois, dans Okta.

Pourquoi associer TrueFoundry et Okta

Okta divise l'écosystème XAA en trois couches : les applications demandeuses (les clients et agents), les applications ressources (les outils qui détiennent les données), et la couche d'infrastructure d'identité et de passerelle qui achemine et sécurise le trafic intermédiaire. TrueFoundry s'inscrit pleinement dans cette troisième couche.

Cette association est naturelle et complémentaire :

• Okta est le plan de contrôle. Il authentifie les utilisateurs, évalue les applications autorisées à se connecter et émet les assertions signées ainsi que les jetons à courte durée de vie qui transmettent les politiques entre les domaines.
• TrueFoundry est le plan d'exécution et de connectivité pour le MCP. C'est là que les assertions sont échangées, que le RBAC au niveau des outils est appliqué, que les serveurs non-XAA sont intégrés au standard, que les garde-fous fonctionnent et que chaque appel est journalisé.

Ensemble, ils permettent à une entreprise de répondre à la question essentielle de toute revue de sécurité liée à l'IA — "pouvons-nous gouverner cela dans notre IdP ?" — par un oui catégorique : votre fournisseur d'identité décide quels clients IA se connectent, à quels serveurs MCP, avec quels périmètres, et vous pouvez tout révoquer de manière centralisée.

Prise en main

Si vous utilisez déjà la MCP Gateway de TrueFoundry, la prise en charge du XAA étend le modèle d'authentification que vous utilisez aujourd'hui — enregistrez Okta comme fournisseur d'identité, mappez les groupes Okta sur les équipes TrueFoundry et rassemblez vos serveurs MCP (compatibles XAA ou non) sous un point d'accès unique régi par l'identité.

Si vous évaluez comment déployer des agents IA à grande échelle sans subir la dispersion des identifiants et les risques liés au shadow-AI, voici la base idéale : appuyée sur des standards, gérée par l'IdP et bâtie sur les protocoles OAuth et OpenID Connect auxquels vous faites déjà confiance.