Cross App Access en el TrueFoundry MCP Gateway: acceso de agentes gobernado por la identidad y basado en tu IdP

Los agentes de IA se están convirtiendo rápidamente en el mando a distancia universal para el trabajo empresarial. Leen de Jira, escriben en Slack, consultan el almacén de datos, abren pull requests y encadenan una docena de herramientas para completar una sola tarea. El Model Context Protocol (MCP) es lo que lo hace posible: proporciona a los agentes una forma estándar de descubrir y llamar a esas herramientas.

Pero MCP responde a cómo un agente habla con una herramienta. No responde a la pregunta que todos los equipos de seguridad se hacen ahora: ¿qué agentes tienen permiso para acceder a qué sistemas, en nombre de quién, con qué alcance y quién puede ver y revocar eso?

Ese vacío es exactamente lo que cierra Cross App Access (XAA). Y encaja casi perfectamente con lo que un MCP gateway está diseñado para hacer. Esta publicación explica qué es XAA, por qué es importante y cómo lo implementa el TrueFoundry MCP Gateway, convirtiendo a tu proveedor de identidad en el plano de control para cada conexión de agente a herramienta en tu organización.

El problema: las conexiones de los agentes ocurren fuera del perímetro de identidad

Hoy en día, cuando un usuario conecta un cliente MCP (una aplicación de IA como Claude, Cursor o VS Code) a un servidor MCP (Slack, Atlassian, un servicio interno), el intercambio de autorización suele ocurrir directamente entre esas dos aplicaciones. El patrón se parece a una de estas dos cosas, y ambas son problemáticas a escala empresarial:

• Credenciales estáticas y API keys. De larga duración, con frecuencia con permisos excesivos y dispersas entre portátiles y archivos de configuración. Rara vez se rotan y casi nunca se revocan de forma limpia. Cada clave representa un privilegio permanente y un radio de impacto potencial.
• Consentimiento OAuth por usuario. Es mejor que las claves sin procesar, pero muestra una pantalla de consentimiento al usuario para cada herramienta, cada cliente y cada vez. El IdP corporativo autenticó al usuario en la aplicación, pero nunca autorizó la relación entre el cliente de IA y la herramienta. Desde el punto de vista del IdP, esa concesión es invisible.

El resultado es la IA en la sombra (shadow AI): una red dispersa y no gestionada de conexiones de agente a aplicación que los equipos de TI y seguridad no pueden inventariar ni controlar. Los administradores no pueden responder a "¿qué clientes de IA pueden actuar en Atlassian como este usuario y con qué alcances?", y no pueden desactivarlo en un solo lugar cuando se desvincula a un empleado o a un agente.

TrueFoundry ya resuelve gran parte de esto centralizando el acceso a MCP a través de un gateway único y gobernado: un único punto de entrada, RBAC hasta el nivel de herramienta, una bóveda de credenciales segura y una traza de auditoría completa. XAA cierra la última brecha: vuelve a situar al propio proveedor de identidad en la decisión de autorización, de modo que las mismas políticas que gobiernan el resto de tu stack gobiernen ahora a tus agentes.

Qué es realmente Cross App Access

Cross App Access (XAA) es una extensión de OAuth 2.0 que permite a un proveedor de identidad empresarial mediar y aprobar la conexión entre dos aplicaciones, en lugar de que esas dos aplicaciones establezcan confianza directamente. Fue introducido por Okta en junio de 2025, adoptado por el IETF OAuth Working Group en septiembre de 2025 e incorporado a MCP en noviembre de 2025 como la extensión de autorización conocida como Enterprise-Managed Authorization (EMA). Esa extensión alcanzó el estado estable en junio de 2026.

Una breve nota sobre la terminología, porque verá ambos nombres en la práctica:

• ID-JAG — la Identity Assertion JWT Authorization Grant — es la extensión de OAuth neutral con respecto al proveedor que se está estandarizando en el IETF. Es el diseño técnico: cómo un IdP emite una aserción de identidad firmada, qué claims lleva y cómo la canjea una aplicación.
• XAA es el nombre de producto de Okta para su implementación de ID-JAG, y el término con el que la mayoría de la gente se encuentra primero. En MCP, este mismo mecanismo se presenta como la extensión Enterprise-Managed Authorization.

Utilizaremos "XAA" en todo momento, pero el punto importante es que se trata de un estándar abierto. Cualquier IdP puede implementar ID-JAG, y cualquier servidor, cliente o gateway de MCP puede ser compatible con él.

Los tres roles

XAA define una clara separación de responsabilidades:

El flujo

La magia de XAA radica en que reemplaza el paso manual de consentimiento por aplicación por un intercambio de tokens regido por políticas que gestiona el IdP:

Dado que la resource app ya confía en las claves de firma del IdP del SSO, no se necesita ninguna nueva infraestructura de confianza. El IdP aplica la política una vez, emite tokens con ámbito de corta duración y registra cada concesión, y el usuario nunca ve una solicitud de consentimiento. Las decisiones de autorización pasan de la capa de aplicación a la capa de identidad, donde son auditables y revocables.

Cómo implementa TrueFoundry XAA

Un gateway de MCP es el lugar ideal para implementar XAA, porque el gateway ya se encuentra exactamente en el punto donde la requesting app se encuentra con la resource app. La arquitectura de autenticación de TrueFoundry se diseñó en torno a una separación deliberada entre la autenticación entrante (cómo los clientes demuestran quiénes son ante el Gateway) y la autenticación saliente (cómo el Gateway llega a los servidores de MCP descendentes). Esa separación tiene precisamente la forma que requiere XAA.

TrueFoundry admite XAA asumiendo el Gateway el rol de requesting app. Aquí está el flujo principal.

El agente envía su token de Okta; el Gateway realiza el intercambio

La aplicación del agente autentica al usuario una sola vez con Okta y recibe un token de Okta. A partir de ese momento, simplemente pasa ese token al Gateway en cada solicitud: no necesita implementar XAA por sí misma ni obtener sus propias aserciones delimitadas. El Gateway se encarga del resto:

1. Valida el token de Okta y lo resuelve a una identidad de TrueFoundry (usuario, equipo o cuenta virtual) utilizando la configuración existente del Identity Provider y la asignación de grupo de Okta → equipo, para luego aplicar el RBAC/ABAC a nivel de herramienta.
2. Realiza el intercambio de tokens con Okta, solicitando una aserción ID-JAG con alcance específico para el servidor MCP al que el agente intenta acceder. Okta evalúa la política XAA y devuelve la aserción delimitada — sin ninguna solicitud adicional de consentimiento o autorización al usuario.
3. Canjea la aserción por un token de acceso de corta duración y restringido a la audiencia para ese servidor MCP.
4. Llama al servidor MCP con el token delimitado y transmite el resultado de vuelta al agente.

El usuario inicia sesión una sola vez en la aplicación del agente. Nunca ve una pantalla de consentimiento de OAuth por servidor y el agente nunca conserva credenciales permanentes para ninguna herramienta descendente (downstream).

Esto se basa directamente en el modelo de autenticación de entrada existente de TrueFoundry (tokens del Identity Provider y Token Passthrough), donde el Gateway actúa como la aplicación solicitante de XAA, realizando el intercambio de tokens y delimitando el alcance de cada aserción al servidor específico en uso.

Conectar servidores MCP que no admiten XAA (el factor diferencial)

La mayoría de los servidores MCP existentes (servicios internos, herramientas adaptadas con OpenAPI, servidores de terceros) no implementan XAA de forma nativa, y muchos nunca lo harán. Aquí es donde un gateway demuestra su valor.

Dado que el Gateway finaliza el flujo de identidad de forma centralizada, puede aplicar el gobierno de XAA a cualquier servidor MCP, independientemente de si el servidor admite el estándar o no. Una vez que se cumple la política y se dispone de un token delimitado, el Gateway gestiona la conexión descendente utilizando el método que ese servidor realmente entienda: OAuth 2.0 por usuario, client credentials, una API key compartida del vault seguro, token passthrough o encabezados personalizados. El servidor MCP obtiene una autorización gobernada a nivel empresarial y con el IdP integrado sin escribir una sola línea de código de intercambio de tokens, y usted obtiene un punto de control XAA coherente en todo su ecosistema de herramientas en lugar de un parche de servidores "preparados para XAA" y "heredados".

Asignación de XAA a las capacidades que TrueFoundry ya ofrece

Cómo se ve en la práctica

Considere a un desarrollador que le pide a Cursor clasificar un incidente: obtener los tickets de Atlassian relacionados, consultar el hilo relevante de Slack y resumir el historial de despliegues.

1. El desarrollador inicia sesión en la aplicación del agente una vez a través de SSO de Okta, y el agente recibe un token de Okta.
2. El agente envía ese token de Okta al Gateway de TrueFoundry con cada solicitud. Cuando necesita Atlassian, el Gateway valida el token, confirma que el equipo del desarrollador puede acceder al servidor MCP de Atlassian y solo a las herramientas de lectura a las que tiene derecho, y realiza el intercambio de tokens con Okta, solicitando una aserción delimitada a ese servidor. Okta comprueba la política: ¿tiene permiso el grupo de este desarrollador para permitir que un cliente de AI acceda a Atlassian? — y devuelve la aserción delimitada. Sin ventanas emergentes de consentimiento.
3. El Gateway canjea la aserción por un token de acceso delimitado y de corta duración, y gestiona la llamada a Atlassian.
4. Cada acción queda registrada en la auditoría de TrueFoundry, atribuida a la identidad individual y al agente específico.
5. Cuando ese desarrollador deja el equipo, TI lo desactiva en Okta. Su acceso — y el de su agente — a cada servidor MCP detrás del Gateway se revoca a través del mismo flujo de baja que gobierna el resto de sus aplicaciones.

No se crearon claves nuevas. No se dejaron privilegios permanentes. Seguridad revisó la política una sola vez, en Okta.

Por qué TrueFoundry + Okta

Okta agrupa el ecosistema XAA en tres capas: aplicaciones solicitantes (los clientes y agentes), aplicaciones de recursos (las herramientas que contienen datos) y la infraestructura de identidad y capa de gateway que enruta y asegura el tráfico intermedio. TrueFoundry se sitúa directamente en esa tercera capa.

La combinación es natural y complementaria:

• Okta es el plano de control. Autentica a los usuarios, evalúa qué aplicaciones pueden conectarse y emite las aserciones firmadas y tokens de corta duración que transfieren la política entre dominios.
• TrueFoundry es el plano de ejecución y conectividad para MCP. Es donde se canjean las aserciones, donde se aplica el RBAC a nivel de herramienta, donde los servidores sin XAA se integran en el estándar, donde se ejecutan los guardrails y donde se registra cada llamada.

Juntos permiten a una empresa responder a la pregunta clave en cualquier revisión moderna de seguridad de AI — "¿podemos gobernar esto en nuestro IdP?" — con un sí contundente: su proveedor de identidad decide qué clientes de AI se conectan, a qué servidores MCP, con qué alcances, y puede revocarlo todo de forma centralizada.

Primeros pasos

Si ya está ejecutando el MCP Gateway de TrueFoundry, la compatibilidad con XAA amplía el modelo de autenticación que utiliza hoy: registre Okta como Identity Provider, asigne los grupos de Okta a los equipos de TrueFoundry e integre sus servidores MCP (nativos de XAA o no) bajo una única puerta de acceso gobernada por la identidad.

Si estás evaluando cómo desplegar agentes de AI a escala sin heredar la dispersión de credenciales ni el riesgo de shadow-AI, esta es la base: basada en estándares, mediada por IdP y construida sobre OAuth y OpenID Connect en los que ya confías.