Identidad de agente de confianza para la empresa agente

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 se gestiona en un único dominio Trust. Sin embargo, las arquitecturas de agentes presentan cadenas mucho más largas donde una única 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 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 Identidad de agente de confianza. Esta solución utiliza una estrategia basada en políticas y gestionada por pasarela para garantizar que la identidad del usuario final se mantiene entre varios tipos de interacción, 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 flexible a través de políticas de autenticación salientes, las empresas pueden proteger toda su red de agentes sin modificar servicios o agentes 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 empresarial.

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 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 solicitud de un único 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 identidades de múltiples saltos, modelos de autorización mixtos, límites Trust de dominios cruzados, 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, lo que hace imposible la autorización por usuario y los seguimientos de auditoría.
Las necesidades de autorización mixtas se ignoran. 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 del 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 abordan. Los agentes en escenarios B2B y regulados podrían necesitar 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 empresa de 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 por capas para la propagación de la 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 de cartera descendente y el Servidor MCP de cartera deben saber qué datos de usuario devolver y deben verificar que el usuario está autorizado para acceder a ellos. La identidad del 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 conversación) 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 abordan 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 ahora debe 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 puertos 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 total pérdida de identidad. El Agente de servicio de cartera y el Servidor MCP de cartera no tendrían forma de 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 En nombre de Microsoft Entra ID.

Beneficio arquitectónico clave: Todo este proceso es gestionado por la política saliente Flex Gateway. El corredor y los agentes contienen lógica de autenticación cero. En su lugar, se centran exclusivamente en la lógica comercial 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 para un token con ámbito al Agente de servicio de cartera.
El Agente de servicio de cartera recibe un token con el á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é importa: Sin el intercambio de tokens de OBO, las empresas deben elegir entre reenviar el token original, que infringe los privilegios mínimos, o utilizar cuentas de servicio, que corren 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 al tanto 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 el 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 agentes de Finport propagara el token del usuario al agente de datos de mercado utilizando el patrón OBO desde el 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 proviene 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 a 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 integral, 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 corredor de agentes de fin de semana puede participar en flujos de OBO (en el escenario 1) y flujos de S2S sin ningún cambio de código. La configuración de políticas 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 a nivel de servicio utilizando las propias credenciales 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 del 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é 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 gastos generales) 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 “Transferir 5.000 $ a mi cuenta de ahorros externa”. Esta solicitud incluye dos rutas descendentes diferentes:

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 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 identidad de usuario en absoluto. 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 Pasarela flexible utiliza un mecanismo de desafío-respuesta en la conversación del agente. Si falta un token secundario al ponerse en 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 de 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 pasarela orquesta todo el proceso de autenticación entre dominios, garantizando que ni el corredor ni los agentes interactúen nunca con credenciales sin procesar o requieran 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 corredor.
El corredor 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 Pasarela flexible.
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 empresas 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 sostiene: La propagación de identidad se aplica en la capa de pasarela, no dentro de 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 tiene en cuenta el protocolo. Como las políticas funcionan 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 documenta 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 que se pueden componer 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	Ninguno	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)	Operaciones de alto riesgo, de múltiples proveedores de identidad y de dominios cruzados

Estos patrones no se excluyen mutuamente. Como muestran 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 políticas 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 pasarela descritos anteriormente protegen interacciones individuales, pero la propagación de identidad no es una preocupación aislada. Es una capa fundamental del modelo de regulación más amplio de MuleSoft Agent Fabric. Como se describe en Agent Fabric Deep Dive, Agent Fabric se basa en 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 enumera 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.
Orquesta: 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 se aplican políticas 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 y 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 toda 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 sigan 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 soluciona la necesidad de propagación de identidad más común: conservación del contexto de usuario en saltos de agentes.
Agregar en tarea para escenarios entre dominios: 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 un 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 escalable, las experiencias de desarrollador intuitivas y la creación de equipos de alto rendimiento. 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 comercial 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 empresariales escalables, seguros y de alto rendimiento. Trabaja en la intersección de IA, arquitectura empresarial e inteligencia de procesos, con un enfoque en plataformas nativas de la nube y soluciones fiables que operan a escala. Antes de Salesforce, desempeñó funciones de ingeniería en Microsoft, donde contribuyó a productos incluyendo Copilot, Dataverse y Power Platform.