Identidad de agente de confianza para Agentic Enterprise

A medida que las empresas adoptan el paradigma de los agentes, surge un nuevo desafío de seguridad: ¿Cómo fluye la identidad del usuario final a través de una red de agentes de IA autónomos? En arquitecturas de API tradicionales, un usuario se autentica una vez y la aplicación llama a servicios backend en nombre del usuario. La cadena de identidad es corta, bien comprendida y normalmente gestionada en un único dominio Trust. Sin embargo, las arquitecturas de agentes presentan cadenas mucho más largas donde una sola solicitud se despliega entre varios agentes, servicios y servidores de Protocolo de contexto de modelo (MCP), cada uno cruzando potencialmente límites de servicio, Trust Domains e incluso fronteras organizativas. Sin una estrategia deliberada para la propagación de la identidad, las empresas se enfrentan a una opción entre seguridad y funcionalidad, un dilema que ningún arquitecto debería enfrentar.

MuleSoft soluciona las complejidades de la propagación de identidad con su función Trusted Agent Identity. Esta solución utiliza una estrategia gestionada por pasarela basada en políticas para garantizar que la identidad del usuario final se mantiene entre varios tipos de interacciones, incluyendo protocolos de agente a agente (A2A), llamadas de herramientas MCP y solicitudes de API de REST.Al centralizar la gestión de identidad en la capa Pasarela Flex a través de políticas de autenticación salientes, las compañías pueden proteger toda su red de agentes sin modificar agentes o servicios backend.

Este documento pasa por el reto de propagación de identidad utilizando una serie progresiva de escenarios, cada uno introduciendo complejidad adicional. Juntos, estos escenarios ilustran por qué Trusted Agent Identity es un requisito fundamental para cualquier implementación de agentes a escala de compañía.

En una aplicación convencional, el flujo de identidad (flujo JWT de OAuth) es sencillo: El usuario inicia sesión, recibe un token y la aplicación utiliza el token para acceder a recursos de backend. El token está integrado con la identidad del usuario, incluyendo quién es y para qué está autorizado, y se desplaza con cada solicitud. La cadena de llamadas es corta, normalmente de uno o dos saltos, y se resuelve la propagación de identidad.

Sin embargo, las arquitecturas de agentes presentan cadenas de llamadas mucho más largas donde una sola solicitud de usuario podría desplegarse entre varios agentes, servicios backend y servidores de Protocolo de contexto de modelo (MCP).Cada destino de solicitud constituye un salto separado. Aunque estos desafíos, como la propagación de identidad de múltiples saltos, los modelos de autorización mixtos y los límites Trust de dominio cruzado, son comunes en cualquier configuración de API distribuida, lo que se distingue es cómo responde el ecosistema actual de forma predeterminada. Hoy en día, el patrón dominante para la comunicación de agente a agente y de agente a API se basa en credenciales de cliente, claves de API o secretos compartidos. Esto significa:

La identidad del usuario se pierde de forma predeterminada. Cuando un agente llama a un servidor MCP o API descendente utilizando credenciales de cliente, la solicitud lleva la identidad de servicio del agente y no la del usuario final. El servicio descendente no tiene forma de saber qué usuario inició la acción, haciendo imposible la autorización por usuario y los seguimientos de auditoría.
Se ignoran las necesidades de autorización mixta. No todos los servicios descendentes requieren contexto de usuario.Mientras que algunos gestionan información específica del usuario como transacciones o carteras, otros proporcionan datos de cara al público o a nivel del sistema como material de referencia o tendencias de mercado.Debido a que el estándar actual se basa exclusivamente en credenciales de cliente, no hay forma de diferenciar entre estas necesidades o propagar selectivamente la identidad del usuario solo cuando sea necesario.
Los límites de Cross-Domain Trust no se tratan. Es posible que los agentes en escenarios B2B y regulados necesiten interactuar con sistemas gobernados por proveedores de identidad (IdP) completamente separados. Por ejemplo, un sistema de banca externa no puede interpretar un token de inicio de sesión único (SSO) corporativo, pero aún debe recibir el consentimiento y la intención del usuario. El flujo de credenciales de cliente no tiene ningún mecanismo para esto.

El resultado es una brecha entre el requisito de la compañía para el acceso de menor privilegio atribuible al usuario y la dependencia del ecosistema actual de la autenticación a nivel de servicio que carece de contexto de usuario. Cerrar esta brecha requiere un enfoque deliberado y en capas para la propagación de identidad. Para ilustrar estos conceptos, los siguientes escenarios utilizan Finport, una aplicación fintech ficticia, para proporcionar ejemplos prácticos de estos patrones arquitectónicos.

Finport es una aplicación web ficticia de gestión de carteras de Fintech de cara al consumidor respaldada por una arquitectura agente. Un corredor de agentes (creado utilizando MuleSoft Agent Broker) coordina múltiples agentes descendentes y servidores MCP para satisfacer solicitudes de usuarios.

Finport expone tres funciones principales, cada una con un requisito de identidad distinto:

“Mostrar mi cartera.”: El usuario solicita sus participaciones personales e historial de transacciones. Como estos datos son específicos del usuario, el Agente de servicio descendente de cartera y el Servidor MCP de cartera deben saber qué datos devuelven los usuarios y deben verificar que el usuario está autorizado para acceder a ellos. La identidad de usuario debe propagarse por cada salto.
“¿Cuáles son las tendencias actuales del mercado?”: El usuario solicita datos de mercado públicos y precios de activos. Como los datos son públicos y no varían por usuario, el Agente de datos de mercado descendente y el Servidor MCP de mercado de activos no necesitan o esperan un token con ámbito de usuario. Las credenciales de servicio propias del corredor son suficientes.
“Transferir 5.000 $ a mi cuenta de ahorros externa.”: El usuario inicia una transferencia de fondos a un banco que utiliza un IdP diferente (por ejemplo, Auth0 en vez de Okta). El token Finport del usuario no tiene sentido para el sistema del banco. El usuario debe autenticarse directamente con el banco (en línea dentro de la plática) antes de que pueda continuar la transferencia.

Cada una de estas funciones se asigna a un patrón de propagación de identidad diferente. Los siguientes escenarios se crean progresivamente desde una línea base estándar (sin agentes) a través de cada patrón distinto, ilustrando cómo las políticas salientes en Flex Gateway solucionan cada requisito sin modificar los agentes o servicios backend.

Antes de presentar agentes, es esencial establecer la línea base: un usuario autenticándose con una aplicación cliente y accediendo a un servicio backend.

El flujo:

El usuario abre Finport y se le redirige a la página de inicio de sesión del IdP (por ejemplo, Okta) .
El usuario se autentica (nombre de usuario, contraseña, SSO, autenticación de múltiples factores (MFA) y cualquier otro requisito).
El IdP emite un token de acceso JWT firmado a la aplicación Finport.
Finport ahora tiene un token de usuario que representa la identidad del usuario: quiénes son, qué ámbitos se les han otorgado y cuándo caduca el token. Puede presentarlo a cualquier servicio descendente en nombre de este usuario.

Lo que esto establece: Este proceso sigue el patrón de arquitectura estándar de OAuth 2.0. El token de usuario inicial, validado por un IdP de confianza, sirve como la base esencial para todas las operaciones posteriores. Cada escenario posterior se basa en este token.

La pregunta: Una vez autenticado, el usuario inicia acciones como transferencias de fondos, análisis de mercado o revisiones de cartera. Estas solicitudes se procesan a través de un corredor de agentes y pueden implicar múltiples agentes descendentes o servidores MCP. Esto plantea cuestiones críticas: ¿Cómo se mantiene la identidad del usuario entre estas solicitudes distribuidas? ¿Qué sucede cuando un servicio descendente utiliza un IdP completamente diferente?

El usuario solicita al agente de Finport “Mostrarme mi cartera”. Esta interacción desencadena una cadena backend que comienza con el Finport Agent Broker, creado utilizando MuleSoft Agent Broker. El corredor transfiere la tarea a un Agente de servicio, que a su vez consulta un servidor MCP de cartera. El token de autenticación inicial del usuario debe ahora desplazarse por múltiples saltos para acceder a los registros de cartera solicitados.

Pasar el token original infringe el principio de menor privilegio, mientras que el uso de una cuenta de servicio pierde la identidad del usuario.

El Agente de finanzas recibe el token del usuario, pero no puede simplemente reenviar ese mismo token al Agente de servicio de cartera, ya que violaría el principio de menor privilegio y no abarcaría correctamente la solicitud para el servicio descendente. Por el contrario, el uso de una cuenta de servicio da como resultado una pérdida de identidad total. El Agente de servicio de cartera y el Servidor MCP de cartera no podrían saber qué cartera de usuarios devolver, y el seguimiento de auditoría atribuiría cada acción a la identidad del servicio del corredor en vez del usuario final.

Flex Gateway resuelve estas complejidades de propagación de identidad de forma transparente a través de su política de intercambio de tokens de OAuth 2.0 saliente. Esta solución intercepta solicitudes salientes en cada salto de la cadena de llamadas, intercambiando el token de usuario entrante con el IdP por una nueva credencial con ámbito específico para el servicio descendente. La política En nombre de (OBO) admite los protocolos Intercambio de tokens de OAuth 2.0 (RFC 8693) y Id. de entrada de Microsoft en nombre de.

Beneficio arquitectónico clave: Todo este proceso está gestionado por la política saliente Flex Gateway. El broker y los agentes contienen lógica de autenticación cero. En su lugar, se centran exclusivamente en la lógica de negocio mientras que la capa de pasarela aplica la propagación de identidad.

El flujo:

El usuario se autentica con Okta y la aplicación Finport envía una solicitud a través de Flex Gateway.
El corredor recibe el token de usuario validado y determina que se necesita el Agente de servicio de cartera.
La política de OBO saliente de Flex Gateway intercambia el token de usuario con el IdP por un token con ámbito al Agente de servicio de cartera.
El Agente de servicio de cartera recibe un token con ámbito adecuado y llama al servidor MCP de cartera.
Flex Gateway vuelve a intercambiar el token, esta vez con ámbito para el servidor MCP.
El servidor MCP de cartera devuelve los datos de cartera específicos del usuario.
Existe un seguimiento de auditoría completo. Cada salto es atribuible al usuario final original.

Por qué esto importa: Sin el intercambio de tokens de OBO, las compañías deben elegir entre el reenvío del token original, que infringe el menor privilegio, o el uso de cuentas de servicio, que corre el riesgo de perder la identidad del usuario. El patrón OBO elimina esta compensación ya que la identidad del usuario se mantiene en cada salto, cada token tiene ámbito a su destino y los propios agentes permanecen completamente inconscientes de la mecánica de identidad.

No todos los servicios descendentes requieren contexto de usuario. El usuario pregunta al agente de Finport “¿Cuáles son las tendencias actuales del mercado?” A diferencia de la solicitud de cartera en Escenario 1, los datos de tendencia de mercado son públicos cuando no varían por usuario. El Agente de datos de mercado descendente y el Servidor MCP de mercado de activos no necesitan, o esperan, un token con ámbito de usuario.

La propagación de tokens de usuario donde no son necesarios amplía la superficie de ataque.

Si el corredor de agente de Finport propagara el token del usuario al agente de datos de mercado utilizando el patrón OBO desde Escenario 1, funcionaría pero no sería necesario. La propagación de tokens de usuario donde no son necesarios amplía la superficie de ataque, crea dependencias innecesarias en el IdP para intercambios de tokens e infringe el principio de menor privilegio. El Agente de datos de mercado simplemente necesita saber que la solicitud procede de un servicio autorizado, no qué usuario está preguntando.

La política Credenciales de cliente de OAuth 2.0 salientes de Flex Gateway gestiona esto de forma transparente. En vez de intercambiar el token del usuario, la política inyecta las credenciales de servicio propias del corredor a través de una concesión de credenciales de cliente en la solicitud saliente. El Agente de datos de mercado descendente recibe un token de nivel de servicio autenticado correctamente donde no se propaga ninguna identidad de usuario porque no se necesita ninguna.

Beneficio arquitectónico clave: La estrategia de propagación de identidad no es de tamaño único, sino que se determina por ruta descendente basándose en la naturaleza de los datos y los requisitos del servicio de destino. Las políticas salientes de Flex Gateway hacen que esto sea configurable por ruta. El mismo agente de finanzas puede participar en flujos de OBO (en Escenario 1) y flujos de S2S sin ningún cambio de código. La configuración de la política en la pasarela de salida determina qué patrón se aplica a qué llamada descendente.

El flujo:

El usuario pregunta al agente de Finport “¿Cuáles son las tendencias actuales del mercado?”
El corredor determina que el Agente de datos de mercado es necesario para realizar la solicitud.
La política Credenciales de cliente salientes de Flex Gateway obtiene un token de nivel de servicio utilizando las credenciales propias del corredor (no se intercambia ni se propaga ningún token de usuario).
El Agente de datos de mercado recibe una solicitud de servicio autenticada correctamente y llama al Servidor MCP de Mercado de activos.
El servidor MCP de mercado de activos devuelve los datos de mercado público.
No hay identidad de usuario presente en la cadena por diseño porque no se necesita ninguna para este tipo de datos.

Por qué esto importa: El marco de trabajo dirigido por políticas de Flex Gateway permite a los arquitectos seleccionar el modelo de identidad óptimo para cada interacción, resolviendo la difícil elección entre la propagación de tokens de usuario universal (que aumenta los riesgos de seguridad y sobrecarga) y el uso de cuentas de servicio globales, que sacrifica el contexto y el cumplimiento de los usuarios.

El escenario de identidad más complejo surge cuando un agente necesita interactuar con un sistema gobernado por un IdP completamente diferente, uno que no reconoce el token de usuario existente.

El escenario: El usuario de Finport solicita al agente de Finport que “transfiera 5.000 $ a mi cuenta de ahorros externa”. Esta solicitud incluye dos rutas descendentes distintas:

La ruta Agente de servicio de cartera (OBO) para verificar las participaciones del usuario
La ruta Agente de transacciones → Servidor MCP de transacciones → Banco del usuario para ejecutar la transferencia real

El Agente de transacciones necesita interactuar con el banco del usuario, que utiliza su propio IdP. El token Okta del usuario de Finport no tiene sentido para el sistema del banco, ya que el banco no tiene ninguna relación Trust con el IdP de Finport. Ni el patrón OBO (desde Escenario 1) ni el patrón S2S (desde Escenario 2) pueden resolver esto. OBO intercambia tokens dentro del mismo IdP, y S2S utiliza credenciales de servicio que no llevan ninguna identidad de usuario. El banco requiere que el usuario se autentique directamente con sus propias credenciales bancarias, incluyendo posiblemente MFA.

La política Código de autorización en tarea A2A saliente en Flex Gateway utiliza un mecanismo de desafío-respuesta en la plática del agente. Si falta un token secundario al hacer contacto con el banco, la política devuelve un reto de autenticación obligatoria. Este reto incluye todos los detalles necesarios (como extremos, ámbitos y parámetros PKCE) para que el cliente inicie un flujo de OAuth 2.0 con el proveedor del banco.

La aplicación Finport muestra a continuación el inicio de sesión del banco en línea para la autenticación de usuario directa. Una vez completado, el cliente devuelve el token en la solicitud A2A. La política extrae este token para el sistema del banco y lo depura del cuerpo del mensaje para garantizar la seguridad.

Beneficio arquitectónico clave: La capa de política de la pasarela orquesta todo el proceso de autenticación entre dominios, garantizando que ni el corredor ni los agentes interactúan con credenciales sin procesar o requieren Knowledge del IdP del banco. Al utilizar este marco de trabajo de desafío-respuesta, los usuarios mantienen el control completo: proporcionan consentimiento explícito para autenticarse con sistemas externos, mientras que el token resultante se transmite de forma segura a través de la capa de política.

El flujo:

El usuario solicita a Finport iniciar una transferencia. La solicitud fluye a través del broker.
El broker se despliega, utilizando la Cartera (OBO) para verificar participaciones y la Transacción (En tarea) para ejecutar la transferencia.
La ruta Transacción desencadena un reto de autenticación obligatoria desde la política En tarea en Flex Gateway.
El reto se propaga de vuelta a la aplicación Finport, que presenta el flujo de inicio de sesión del banco al usuario en línea.
El usuario se autentica con su banco, incluyendo MFA si es necesario.
El token bancario se incluye en la solicitud A2A posterior. La política la extrae, la establece en el encabezado Autorización y reenvía la solicitud.
El servidor MCP de transacciones recibe la solicitud con el token del banco y ejecuta la transferencia.

Por qué esto importa: La identidad entre dominios es un reto importante en arquitecturas de agentes. Sin autenticación en tarea, las compañías deben establecer previamente relaciones Trust complejas entre cada IdPin de la red o solicitar a los usuarios proporcionar credenciales bancarias a un agente. El patrón En tarea resuelve esto permitiendo la autenticación de usuario directa con proveedores externos; la política gestiona la mecánica de tokens mientras mantiene los agentes desvinculados de dominios de identidad externos.

En los tres escenarios, un único principio arquitectónico mantiene: La propagación de identidad se aplica en la capa de la pasarela, no en agentes o servicios. Los agentes y servidores MCP contienen cero lógica de autenticación. Su función está restringida al procesamiento de solicitudes autenticadas y la devolución de resultados, mientras que la capa de política saliente Pasarela flexible gestiona todas las operaciones relacionadas con la identidad.

Esto funciona porque las políticas de autenticación salientes de Flex Gateway interceptan el tráfico en el punto correcto: después de que el agente tome su decisión de enrutamiento, pero antes de que la solicitud llegue al servicio descendente. La política transforma el token (ya sea un intercambio de OBO, una inyección de credenciales de cliente o una respuesta de reto en tarea) y reenvía una solicitud autenticada correctamente. El servicio descendente nunca conoce la diferencia, por lo que el agente nunca tiene que preocuparse. La lógica de autenticación está centralizada en la pasarela, no dispersa entre servicios. Los servicios backend no requieren cambios de código y la misma configuración de política se puede reutilizar entre múltiples rutas.

Este enfoque también distingue entre protocolos. Como las políticas operan en la capa HTTP, se aplican de forma coherente tanto si el agente se comunica a través de REST, MCP, A2A o webhooks. Como se documentó en Agent Fabric Deep Dive, todo el tráfico A2A y MCP se enruta a través de Flex Gateway para garantizar que las políticas se aplican en cada extremo, lo que significa que la propagación de identidad se aplica de forma uniforme independientemente del protocolo de comunicación.

Tres patrones componibles cubren el espectro completo de requisitos de identidad en una arquitectura agente:

Patrón	Política	Identidad de usuario	Interacción de usuario	Caso de uso
En nombre de (OBO)	Política de inyección de credenciales de OBO de OAuth 2.0	Conservado	Ninguna (transparente)	Datos específicos del usuario en el mismo dominio Trust
Servidor a servidor (S2S)	Credenciales de cliente de OAuth 2.0 salientes	No propagado	Ninguna	Datos públicos, operaciones a nivel del sistema
Código de autorización en tarea	Código de autorización en tarea A2A saliente	Principal + Secundario	Obligatorio (autenticación en línea	Dominios cruzados, proveedores de múltiples identidades, operaciones de alto riesgo

Estos patrones no se excluyen mutuamente. Como se muestra en los escenarios de Finport, un único agente corredor puede utilizar OBO para una llamada descendente, S2S para otra y En tarea para una tercera. La configuración de la política en cada ruta saliente determina qué patrón se aplica. No hay cambios de código de agente ni modificación de servicio, solo política.

Los patrones aplicados por la pasarela descritos anteriormente aseguran interacciones individuales, pero la propagación de identidad no es una preocupación aislada. Es una capa fundamental del modelo de gobernanza más amplio de MuleSoft Agent Fabric. Como se describe en Agent Fabric Deep Dive, Agent Fabric está construido sobre cuatro pilares: Descubra, orqueste, gobierne y observe, y cada uno depende de una cadena de identidad fiable para funcionar de forma efectiva.

Descubrir: El Registro de agentes cataloga agentes y sus funciones. Los metadatos de agentes incluyendo requisitos de autenticación permiten a los corredores comprender qué patrones de identidad espera cada agente.
Orquestar: El corredor de agentes coordina flujos de trabajo de múltiples agentes. Flex Gateway gestiona de forma transparente la transformación de identidad en cada salto, de modo que el corredor puede centrarse en la descomposición y el enrutamiento de tareas.
Gobernar: Todo el tráfico A2A y MCP se enruta a través de Flex Gateway, incluso si el sistema de destino no es seguro, para garantizar que las políticas se aplican en cada extremo. Las políticas de autenticación salientes forman parte de la capa de gobernanza.
Observar: Visualizador de agentes proporciona observabilidad en tiempo real a través de un mapa interactivo dinámico de interacciones de agentes. Con la identidad de usuario preservada en cada salto, los rastreos y registros proporcionan seguimientos de auditoría atribuibles al usuario en la red de agentes.

Sin propagación de identidad de confianza, la gobernanza es incompleta. Puede catalogar y orquestar agentes, pero no puede garantizar que actúen dentro de los límites de la autorización del usuario. Trusted Agent Identity cierra esta brecha, garantizando que la seguridad y el contexto de usuario siguen siendo fundamentales para los flujos de trabajo de agentes.

Para implementar estos patrones:

Comprenda el Directorio de políticas saliente. Revise el conjunto completo de políticas de autenticación disponibles para Flex Gateway.
Comience con OBO. La política de intercambio de tokens de OAuth 2.0 aborda las necesidades de propagación de identidad más comunes: preservación del contexto de usuario entre saltos de agentes.
Agregar en tarea para escenarios de dominio cruzado: Cuando su red de agentes cruza los límites Trust, la política Código de autorización en tarea A2A proporciona el mecanismo de desafío-respuesta para obtener credenciales secundarias del usuario.
Tela de agente de apalancamiento. Defina su red de agentes en el YAML agente-red con configuraciones de políticas que especifican el modelo de identidad por ruta. La plataforma gestiona el resto.

Para obtener directrices de implementación detalladas, consulte la guía de implementación.

Nikhil Aggarwal es ingeniero distinguido en Salesforce, donde lidera la arquitectura para MuleSoft y Salesforce Automation Cloud. Nikhil aporta más de 18 años de experiencia entregando productos a gran escala y es un apasionado de la arquitectura ampliable, las experiencias de desarrollador intuitivas y la creación de equipos de alto desempeño. Antes de Salesforce, dirigió múltiples iniciativas en Microsoft Power Platform, Dataverse y Office 365 desde el concepto hasta el lanzamiento. Su trabajo continúa dando forma a cómo las empresas modernas conectan sistemas, automatizan flujos de trabajo y desbloquean valor de negocio en la primera era de la IA.

Akash Trivedi es Director de Ingeniería de Salesforce con más de 18 años de experiencia en la creación de sistemas de negocio escalables, seguros y de alto desempeño. Trabaja en la intersección de IA, arquitectura de negocio e inteligencia de procesos, con un enfoque en plataformas nativas de la nube y soluciones fiables que operan a escala. Antes de Salesforce, tenía funciones de ingeniería en Microsoft, donde contribuyó en productos incluyendo Copilot, Dataverse y Power Platform.