Proteja sus flujos de trabajo de varios agentes con conexiones de agente a agente

El punto ciego de la identidad en los flujos de trabajo con múltiples agentes

En este momento, dentro de su empresa, un agente de IA podría estar invocando a otro agente de forma autónoma. Un agente de ventas obtiene el historial de pagos de un cliente de un agente financiero. Un agente de monitoreo activa un agente de diagnóstico para investigar un servicio fallido. El trabajo que antes requería decenas de traspasos entre personas ahora se completa en segundos.

Aquí está el problema: cada uno de esos traspasos es un evento de acceso que necesita gobernar. Y la mayoría de los equipos de seguridad no tienen visibilidad sobre ellos. Mientras tanto, los equipos de IA que crean estos flujos de trabajo con múltiples agentes están codificando de forma personalizada la autorización entre cada par de agentes, ensamblando soluciones puntuales sin un lugar central desde el que ver o controlar lo que está sucediendo.

Las arquitecturas de múltiples agentes, ya sean iniciadas por humanos, por máquinas o, cada vez más, por los propios agentes, ya están en producción. Pero falta la capa de identidad subyacente. Sin una capa de identidad diseñada específicamente para interacciones entre agentes, estas conexiones se convierten en puntos ciegos: sin gobernanza, sin atribución e imposibles de auditar.

Novedades: conexiones seguras entre agentes

Para asegurar y gobernar flujos de trabajo de múltiples agentes, Okta for AI Agents aprovecha el plan estratégico para la empresa agencial segura de Okta, un marco estratégico para descubrir, autorizar y gobernar agentes de IA autónomos. El segundo pilar de este plan plantea: “¿A qué pueden conectarse?”, enfocándose en asegurar las conexiones de agente a recurso y otorgando a los agentes acceso limitado y auditado a los datos y sistemas empresariales que necesitan.

Ahora estamos ampliando ese mismo modelo de conectividad segura para abarcar flujos de trabajo de múltiples agentes. Las mismas primitivas que protegen a las personas y las aplicaciones hoy en día, como las identidades de agentes, las credenciales con alcance y la atribución de auditoría, ahora se extienden a las conexiones entre agentes.

En el centro de todo esto se encuentran las Agent-to-Agent Connections, una nueva capacidad de Okta for AI Agents que le permite definir: 

• Políticas de conexión por agente 
• ¿Qué servicios y agentes aguas arriba pueden invocar a un agente? 
• Alcance del agente (a lo que puede acceder)
• Duración de la sesión (cuánto dura ese acceso)

La identidad se conserva en cada transferencia, de modo que cada conexión permanece verificable a lo largo de todo el flujo de trabajo.

Para los equipos de seguridad, eso significa que cada llamada de agente a agente está regulada, delimitada y completamente auditable. Para los desarrolladores, significa crear flujos de trabajo multiagente sin tener que codificar la autorización de cada agente. Todo lo que tienes que hacer es definir las políticas de autorización y acceso una sola vez en Okta, y cada agente en la cadena de delegación trabajará automáticamente con esas políticas.

¿Cómo funcionan las Agent-to-Agent Connections?

Cada vez que un agente llama a otro, Okta verifica que la conexión esté autorizada, limita los datos a los estrictamente necesarios para la tarea y registra quién actuó en nombre de quién, de modo que el flujo de trabajo multiagente quede gobernado de extremo a extremo.

Flujo de múltiples agentes paso a paso

Para ver cómo funciona esto, sigamos una sola solicitud a través del flujo de trabajo multiagente. Imagine una tarea rutinaria de generación de informes a cargo de dos agentes:

• Agente asistente del usuario: Actúa en nombre del empleado
• Agente analista de datos: Extrae datos de bases de datos sensibles

Aquí está el flujo:

1. El usuario le pide al agente asistente que le prepare un informe del cuarto trimestre.
2. El agente asistente del usuario necesita datos, así que llama al agente analista de datos «en nombre de [user]».
3. Okta verifica la política: ¿Se le permite al agente asistente de usuario llamar al agente analista de datos? ¿Puede el agente analista de datos compartir estos datos con el usuario?
4. Si es así, Okta emite un token temporal que dice: "Agente de análisis de datos, esta solicitud proviene de [user] a través de [user assistant agent]." Puedes compartir X, Y y Z.
5. El agente analista de datos valida el token, comparte solo lo permitido y registra la solicitud.
6. El agente asistente del usuario utiliza los datos para elaborar el informe y se lo devuelve al usuario.
7. Todo es auditable. El registro muestra: usuario → agente asistente de usuario → agente analista de datos.

Tres principios lo hacen posible:

•  Listas blancas explícitas: Defina qué agentes pueden llamar a qué otros agentes.
•  Permisos con alcance: otorgue a cada agente aguas abajo solo lo que necesita para su tarea.
•  Cadenas de delegación verificables: Viaja con cada token, de modo que el registro de auditoría captura quién autorizó qué.

El resultado: Los equipos de seguridad obtienen visibilidad completa de cada acción de los agentes. Desarrolladores, dejen de escribir código de autorización entre agentes y empiecen a desplegar flujos de trabajo multiagente más rápido.

Por qué la cadena de delegación de múltiples agentes sigue siendo confiable

Dos cosas mantienen la cadena de delegación confiable: 

1. Cada agente puede actuar tanto como cliente como recurso. 
2. Cada token contiene un registro completo y verificable de quién autorizó qué. La autorización ocurre en tiempo de ejecución y la acción se almacena en el registro de auditoría.

Agentes que actúan tanto como clientes como recursos.

Cada agente en Okta es tanto un cliente como un recurso. Esto es importante porque en un flujo de trabajo real de múltiples agentes, los agentes no se limitan a estar en un extremo de la llamada; están en medio. Cada agente puede iniciar solicitudes a otros agentes o servicios, y puede recibir solicitudes de ellos. Ese doble rol es lo que hace posible la orquestación.

• Como cliente: El agente puede llamar a otros agentes o servicios
• Como recurso: Otros agentes pueden llamar a este agente (si la política lo permite)

Un único agente puede ser tanto especializado como orquestador, sin romper la cadena de confianza.

Preservando el contexto mediante registros de delegación basados en tokens.

Cuando Okta emite un token para una llamada de agente a agente, incluye un registro de la ruta completa:

• Esto es para el usuario A.
• El usuario A delegó en el agente asistente.
• El agente asistente delegado al agente analista de datos
• Se le permite al agente analista de datos realizar X, Y y Z.

Okta incluye la cadena de delegación completa en el token para que el agente receptor pueda verificar la autorización antes de actuar. El registro de auditoría de Okta captura la cadena de delegación de cada llamada, conservándola mucho después de que caduque el propio token. 

Si algo sale mal, como un incidente de seguridad, una consulta de auditoría o una revisión de cumplimiento, puedes extraer el registro de auditoría y ver exactamente qué sucedió, quién lo autorizó y si cumplió con la política. No se requiere búsqueda manual en los registros. No hay trabajo de correlación.

Analizando patrones de flujo liderados por humanos versus liderados por máquinas

Ya sea que un flujo de trabajo comience con un humano o con una máquina, una identidad ancla toda la cadena. Cada agente aguas abajo actúa bajo dicha autoridad, y cada paso es atribuible a la misma. Hoy, Agent-to-Agent Connections manejan ambos patrones.

Patrón 1: un humano inicia la cadena

Un usuario inicia sesión y le solicita a un agente que realice una acción. Ese agente podría llamar a otros agentes para completar el trabajo, pero la identidad del humano es el ancla.

Ejemplo: El empleado pregunta: "Dame un resumen de las métricas del cuarto trimestre."

1. El agente de resumen llama al agente del panel de control (en nombre del empleado)
2. El agente del panel de control llama al agente de base de datos (en nombre del empleado)

La identidad del empleado fluye a través de toda la cadena, y cada paso queda registrado a su nombre.

Qué registra Okta en el registro de auditoría: “el empleado autorizó al agente de resumen a llamar al agente del panel de control.” El agente del panel recuperó métricas del agente de la base de datos dentro del alcance de acceso del empleado.

Patrón 2: un servicio inicia la cadena 

Las empresas cuentan con décadas de aplicaciones de servicio, pipelines ETL, tareas programadas y microservicios que ejecutan cargas de trabajo deterministas. Estos sistemas ahora incorporan inteligencia artificial.

Ejemplo: Un servicio de monitoreo detecta un pico de CPU.

1. El servicio de monitoreo llama al agente de diagnóstico.
2. El agente de diagnóstico llama al agente de análisis de registros.

Ningún usuario inició la solicitud. El servicio de monitoreo es el cliente y el agente de diagnóstico es su recurso, y la autoridad del servicio fluye a lo largo de toda la cadena.

Qué registra Okta en el registro de auditoría: "El servicio de supervisión autorizó al agente de diagnóstico a invocar al agente de análisis de registros." El agente de análisis de registros puede analizar los registros de producción del servicio de monitoreo.

Diferencias clave entre los dos patrones

El resultado: Un modelo de gobernanza, independientemente de dónde empiece la cadena de delegación. Los equipos de seguridad obtienen trazabilidad completa en los flujos de trabajo iniciados tanto por humanos como por máquinas, con cada traspaso registrado. Los equipos de IA reciben autorización que funciona de la misma manera, ya sea que el elemento raíz sea un usuario o un servicio, por lo que no es necesario construir ni mantener lógica separada para cada patrón.

Patrón 3: un agente autónomo inicia la cadena (próximamente)

Próximamente llegará un tercer patrón: On-behalf-of-self, donde un agente autónomo puede actuar completamente con su propia autoridad, sin ninguna delegación, bajo una política preaprobada por un administrador. Usando este patrón, podrás ejecutar agentes autónomos dentro de una política predefinida, totalmente auditados y gobernados. 

Llevar los flujos de trabajo multiagente bajo una gobernanza centralizada

Los agentes ya están llamando a otros agentes en su entorno, pero nada regula esas llamadas. La pregunta nunca fue si los agentes llamarían a otros agentes; la cuestión es si usted puede responder por lo que sucede cuando lo hacen.

Eso es lo que Okta for AI Agents hace posible. Al extender las mismas primitivas de identidad que aseguran a tu personal, tus aplicaciones y tus agentes a las conexiones entre agentes, sacas el flujo de trabajo multiagente del punto ciego y lo pones bajo gobernanza. Agent-to-Agent Connections le proporciona las listas blancas, los permisos con alcance limitado y una cadena verificable que hacen que escalar los flujos de trabajo autónomos sea seguro.

A medida que las arquitecturas multiagente se vuelvan más complejas, las empresas que triunfen no solo se moverán rápidamente; también podrán demostrar, en cualquier momento, quién hizo qué, en nombre de quién y de acuerdo con qué política.

¿Listo para gobernar tus flujos de trabajo con múltiples agentes?

El acceso anticipado a Agent-to-Agent Connections ya está disponible para los clientes de Okta. Póngase en contacto con el equipo de su cuenta de Okta para inscribirse.

Mira cómo funcionan en la práctica estos controles de agentes de IA. Únete a nuestro streamcast de Okta para saber más sobre cómo se ve la gobernanza de agentes cuando la identidad es el punto de control. 

Estos materiales se ofrecen únicamente con fines informativos generales y no constituyen asesoramiento legal, de privacidad, de seguridad, de cumplimiento ni empresarial. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales. Cualquier mención de productos, funciones, funcionalidades o certificaciones futuras en este blog es únicamente con fines informativos. Estos elementos no son compromisos de entrega y no deben considerarse como base para tomar decisiones de compra. © Okta, Inc. y sus filiales, 2026.