Este es el cuarto blog de una serie de siete partes sobre la seguridad de la identidad como seguridad de la IA.
En resumen: las cadenas de delegación se están convirtiendo en objetivos de alto impacto en los sistemas autónomos. Cada traspaso entre agentes multiplica el acceso y, dado que casi todas las identidades no humanas (el 97 %) ya cuentan con privilegios excesivos, el riesgo se amplifica en cada salto. En una vulnerabilidad conocida como contrabando de sesiones de agente (noviembre de 2025), un subagente inserta de forma silenciosa una operación bursátil en una respuesta rutinaria. El agente principal la ejecuta sin ninguna solicitud explícita y sin visibilidad para el usuario. En otra vulnerabilidad conocida como escalada de privilegios entre agentes (septiembre de 2025), un agente reescribe la configuración de otro durante la ejecución de una tarea, lo que puede activar un bucle de control que se refuerza a sí mismo. La delegación no es inherentemente riesgosa, pero sin licencias limitadas ni linaje criptográfico, puede convertirse en un canal directo para el movimiento lateral.
Contrabando de sesiones de agentes: cuando la delegación se convierte en explotación
La delegación entre agentes permite escalar por diseño: los agentes principales delegan tareas complejas en subagentes especializados para una ejecución puntual.
En teoría, cada paso reduce los permisos y mantiene la alineación con la intención original. Pero en la práctica, suele ocurrir exactamente lo contrario.
En una prueba de concepto (PoC) utilizada como parte del escenario de contrabando de sesiones, un agente asistente financiero solicitó análisis de mercado a un agente de investigación. El subagente devolvió un resumen limpio, además de una orden de compraventa de acciones oculta. No se activó ninguna alerta y la operación se ejecutó sin que nadie lo advirtiera.
Cada capa confió en la siguiente y ninguna verificó la alineación. El equipo Unit 42 describió cómo podía desarrollarse todo el recorrido del ataque:
- El asistente financiero delega en el asistente de investigación la obtención de noticias de mercado
- El asistente de investigación es malicioso e inyecta instrucciones ocultas en su respuesta
- El asistente financiero ejecuta una operación no autorizada de 10 acciones
- El usuario solo ve el resumen de noticias; la llamada buy_stock resulta invisible
Tal como señaló Unit 42:
“Un agente comprometido representa un adversario con mayores capacidades. Impulsado por modelos de IA, un agente comprometido puede generar estrategias adaptativas de forma autónoma, explotar el estado de la sesión y ampliar su influencia en todos los agentes cliente conectados“.
En un ejemplo que ilustra cómo podría desarrollarse un escenario de escalada de privilegios, un agente comprometido podría modificar el entorno de ejecución de un agente hermano. Ese agente, ahora mal configurado, delega tareas de formas que pueden ampliar el alcance del atacante. Si la cadena no se interrumpe, puede cerrarse sobre sí misma y profundizar una intrusión.
Cuanto más profundamente se integran los agentes en finanzas, operaciones e infraestructura, más peligrosa se vuelve la delegación sin control. Cada traspaso de tareas sin verificación se convierte en una filtración en acción.
Tres sistemas y el mismo patrón de fallo
ServiceNow Now Assist (octubre de 2025)
AppOmni reveló que agentes con pocos privilegios en Now Assist de ServiceNow podían utilizarse para explotar la detección de agentes, reclutar pares con mayores privilegios y extraer datos.
Escalada de privilegios entre agentes (septiembre de 2025)
Johann Rehberger identificó la vulnerabilidad de escalada de privilegios entre agentes y explicó cómo un agente comprometido podía reconfigurar a otros reescribiendo su configuración. En entornos donde varios agentes (por ejemplo, Copilot, Claude y Gemini) comparten una base de código, un Copilot con inyección de prompts puede modificar el archivo .mcp.json de Claude.
En el siguiente uso, Claude ejecutaría código arbitrario y luego podría reconfigurar Copilot. Como señaló Rehberger:
“Lo que comienza como una única inyección de prompts indirecta puede escalar rápidamente hasta convertirse en un compromiso de múltiples agentes“.
EchoLeak en Microsoft 365 Copilot (junio de 2025)
Aim Security reveló “EchoLeak“ (CVE-2025-32711, CVSS 9.3), una vulnerabilidad sin interacción del usuario en el que instrucciones ocultas en correos electrónicos activaron la extracción silenciosa de datos desde SharePoint, Teams y OneDrive.
El mismo patrón de vulnerabilidad aparece en los marcos de orquestación de LLM, donde las cadenas de modelos y herramientas suelen carecer de una aplicación automática del alcance, lo que obliga a los desarrolladores a gestionar manualmente la atenuación.
Delegación recursiva: el problema de la muñeca rusa
Los sistemas multiagente están diseñados para descomponer tareas. Un agente principal divide las solicitudes complejas en subtareas y las delega en agentes especializados. Esos subagentes, a su vez, pueden delegar. Cada salto cruza un límite de confianza y hereda la autoridad original.
La guía de OpenID Foundation sobre IA de agentes señala esto como la principal ventaja y el principal riesgo de los ecosistemas de agentes: “El verdadero poder de un ecosistema de agentes surge de la delegación recursiva: la capacidad de un agente para descomponer una tarea compleja y delegar subtareas en otros agentes más especializados“.
Pero ese poder viene acompañado de una advertencia: “Los desafíos se multiplican de forma exponencial con la delegación recursiva, la atenuación del alcance a lo largo de las cadenas de delegación, los flujos reales en nombre del usuario que mantienen la rendición de cuentas y la pesadilla de interoperabilidad entre distintos sistemas de identidad de agentes que intentan comunicarse“.
En otras palabras, lo que hace potente a la IA de agentes también la vuelve frágil, a menos que la arquitectura imponga controles en cada traspaso.
Alcance, procedencia y contexto: tres brechas estructurales que generan riesgo
1. Falta de atenuación del alcance en los saltos de delegación. Cada agente de una cadena de delegación debería tener permisos más limitados que el anterior, pero este principio de privilegio mínimo suele fallar en la práctica. En el escenario de contrabando de sesiones de agente, un agente de investigación heredó acceso a la herramienta de compra de acciones buy_stock de un asistente financiero y ejecutó una operación oculta insertada en un resumen de noticias. Los tokens OAuth tradicionales no pueden restringirse después de emitidos sin volver a contactar al servidor de autenticación, lo que no funciona en sistemas descentralizados. La delegación segura requiere formatos de token que admitan atenuación fuera de línea, de modo que los agentes puedan limitar el acceso de forma independiente.
2. Falta de prueba criptográfica del linaje de delegación. Los tokens OAuth validan la estructura y el estado, pero carecen de trazabilidad histórica. A partir del tercer salto de delegación, ya no existe un vínculo criptográfico con el agente o el usuario que inició la acción. Aembit señala: “Sin pruebas criptográficas, los agentes maliciosos pueden falsificar reclamaciones de delegación y acceder a recursos a los que no deberían llegar“.
3. Falta de anclaje de contexto entre sesiones. Las interacciones de los agentes en múltiples turnos requieren una alineación persistente con la tarea original. Sin ese anclaje, los agentes se desvían y amplían gradualmente su comportamiento más allá de la intención inicial. Unit 42 recomienda el “anclaje de contexto“: crear un punto de referencia de la tarea al inicio de la sesión y validar de forma continua la alineación semántica.
Atenuación del alcance: los permisos deben reducirse, no ampliarse
Los formatos de tokens emergentes, como Macaroons, Biscuits y Wafers, reflejan la arquitectura que requieren las cadenas de delegación para ser seguras. Cada token incluye atributos básicos: identidad, vencimiento y una raíz criptográfica. Quienes los utilizan pueden añadir capas que únicamente reduzcan los permisos. Los tokens siguen siendo verificables fuera de línea, lo que preserva la integridad y evita la escalada de privilegios.
Aunque la sintaxis varía según el formato, el patrón central es el mismo y los tokens pueden atenuarse de forma local, pero nunca ampliarse:
Cada subagente agrega una condición firmada y de solo adición que reduce el alcance del token y forma una cadena verificable. Cuando se utiliza el token, el emisor puede rastrear todo el recorrido de la delegación. Si un agente de investigación intenta ejecutar buy_stock, la solicitud falla de forma trazable, con pruebas de quién restringió qué y dónde.
Aunque ningún proveedor de identidad importante admite actualmente Macaroons o Biscuits de forma nativa, sus principios fundamentales (atenuación fuera de línea, delegación criptográfica y restricciones de solo adición) pueden aplicarse hoy utilizando la infraestructura OAuth existente.
Cómo defenderse de los ataques de delegación recursiva
Estas vulnerabilidades asociadas a la delegación de agentes de IA plantean cuatro requisitos defensivos:
1. Confirmación fuera de banda: las acciones sensibles requieren aprobación humana a través de canales a los que los agentes no pueden acceder, como notificaciones push o una interfaz de usuario separada, no el chat.
2. Anclaje de contexto: vincular las sesiones a la tarea original y detectar desvíos semánticos antes de la ejecución.
3. Identidad y capacidades verificadas: los agentes deben presentar credenciales firmadas (por ejemplo, tarjetas de agente criptográficas).
4. Visibilidad para el usuario: las instrucciones encubiertas funcionan cuando pasan inadvertidas. Es necesario exponer las llamadas a herramientas y los registros.
Cómo Okta y Auth0 abordan la delegación recursiva
La implementación de estos controles de forma independiente puede crear puntos ciegos. Okta y Auth0 ayudan a abordar la delegación recursiva mediante una capa de identidad unificada:
Acceso entre aplicaciones (XAA). XAA, disponible tanto en Okta como en Auth0, traslada el consentimiento al proveedor de identidades, que desde noviembre de 2025 forma parte de MCP bajo el modelo de “autorización administrada por la empresa“. Basado en ID-JAG, permite dar seguimiento al linaje de delegación y revocarlo, de modo que las acciones de los agentes quedan registradas y pueden revocarse.
Token Vault. Auth0 Token Vault resuelve el problema del “delegado confundido“ en el acceso de los agentes a credenciales. Las API ingenuas permiten a los desarrolladores pasar parámetros como userId, lo que expone a los sistemas a errores o inyecciones de prompts que podrían obtener las credenciales de otro usuario. Token Vault elimina este riesgo al exigir pruebas criptográficas de la sesión de usuario actual, nunca un identificador plano. Los agentes utilizan OAuth 2.0 Token Exchange (RFC 8693) para convertir tokens de sesión en credenciales de corta duración y con alcance limitado, logrando una atenuación precisa del alcance mediante protocolos estándar.
Autorización asincrónica. Auth0 Async Auth habilita la aprobación fuera de banda mediante notificaciones push o correo electrónico, y aborda directamente la vulnerabilidad de contrabando de sesiones del agente al exigir confirmación humana a través de canales que los LLM no pueden manipular.
Autorización detallada. Auth0 FGA, basado en el modelo Zanzibar de Google, aplica controles de acceso basados en relaciones en cada solicitud. Los agentes validan y actualizan el estado de la delegación en cada salto, lo que reduce progresivamente los permisos. Este contexto con estado reside en FGA, no en el token, lo que permite una atenuación al estilo de capacidades sin necesidad de nuevos formatos de token.
Identity Governance. Okta Identity Governance extiende la gestión del ciclo de vida a los agentes y ayuda a garantizar que los permisos delegados se revisen y se revoquen a medida que cambian los roles, los proyectos o los contextos de seguridad. Lo que era adecuado en el momento de la implementación puede volverse excesivo muy rápidamente. La gobernanza permite ajustar de forma continua el nivel de autoridad de los agentes.
El camino a seguir: una delegación que demuestra su valía
Los sistemas multiagente ofrecen capacidades que van más allá de lo que puede lograr un solo agente, pero también exponen vacíos que los modelos tradicionales de IAM no cubren. Todas las vulnerabilidades analizadas aquí comparten el mismo patrón: agentes que adquieren más autoridad de la prevista, operan sin visibilidad para el usuario y no dejan registro de auditoría.
Proteger la delegación requiere cuatro pilares: atenuación del alcance en cada salto, verificación del linaje a nivel de token, alineación persistente del contexto y aprobación humana fuera de banda para las acciones sensibles.
Estos controles ya no son opcionales. Según la Ley de IA de la UE, la trazabilidad y la supervisión son obligaciones legales para los sistemas de alto riesgo. El artículo 14 exige que las personas humanas comprendan y supervisen plenamente cómo opera la IA.
Sin cadenas de delegación verificables, ese nivel de supervisión se derrumba. Su infraestructura o bien habilita un control auditable o se convierte en un riesgo de cumplimiento normativo.
A continuación, en el Blog 5: qué ocurre cuando los agentes de IA pasan de los flujos de trabajo digitales a sistemas físicos, donde un solo error puede causar daños en el mundo real y la identidad se convierte en la última línea de defensa.
