«Contrabando de sesiones»: Palo Alto Networks explica cómo un agente de IA malicioso puede engañar a tu asistente de IA

Los especialistas de Unit 42 de Palo Alto Networks describieron un nuevo vector de ataque para sistemas multiagente — agent session smuggling — en el que un agente remoto malicioso inyecta instrucciones ocultas durante una sesión prolongada y obliga al agente cliente a ejecutar acciones no deseadas sin notificar al usuario. La vulnerabilidad no reside en una falla formal del protocolo A2A, sino en la forma en que el estado de la sesión y la confianza incorporada entre agentes permiten camuflar comandos maliciosos entre el intercambio legítimo.

La mecánica es simple: el cliente inicia una petición habitual a un agente remoto; durante la sesión activa, ese agente envía mensajes adicionales y ocultos que modifican el contexto interno del cliente; luego el agente remoto devuelve la respuesta externa esperada, y las operaciones intermedias permanecen invisibles para el usuario. Como resultado, pueden producirse suplantaciones de contexto, filtración de la configuración interna y llamadas no autorizadas a funciones — todo dentro del diálogo.

El estudio compara A2A con Model Context Protocol (MCP) y muestra por qué el riesgo es mayor en A2A: MCP suele operar sin mantener sesiones y realiza llamadas aisladas a herramientas, mientras que A2A conserva el historial de interacciones y permite a los agentes adaptarse durante el diálogo. Esta combinación de memoria y autonomía hace posibles ataques progresivos y difíciles de rastrear.

Para demostrarlo, los investigadores implementaron dos escenarios de prueba de concepto (PoC) basados en Google Agent Development Kit y el protocolo A2A. El cliente era un asistente financiero basado en Gemini 2.5 Pro, y el participante remoto era un asistente de investigación basado en Gemini 2.5 Flash. En el primer escenario, el agente remoto, al recibir una solicitud delegada para un resumen de noticias, mediante una serie de intercambios aclaratorios consiguió que el agente financiero revelara su historial de chat, las instrucciones del sistema, la lista de herramientas disponibles y las formas de invocarlas. En el entorno de pruebas del panel de desarrollo esos mensajes intermedios eran visibles, pero en la interfaz de usuario habitual esos detalles están ocultos, por lo que el usuario solo recibió la respuesta final.

En el segundo PoC, el atacante utilizó la misma técnica para provocar la ejecución de la herramienta buy_stock en el cliente: tras delegar la tarea de recopilar noticias, el agente remoto insertó requisitos adicionales de procesamiento, y el asistente financiero compró automáticamente 10 acciones sin solicitar una confirmación separada al titular de la cuenta. Los registros de actividad del cliente reflejaron function_call y function_response adicionales entre la solicitud original y la respuesta final; esos pasos ocultos fueron los que llevaron a la transacción no autorizada.

Las propiedades clave del ataque — el estado de la sesión, la naturaleza multironda, la adaptabilidad y el sigilo — lo hacen difícil de detectar y peligroso en contextos de integración interorganizacional, donde agentes de distintos dominios se comunican entre sí. La probabilidad de explotación exitosa es baja en entornos estrictamente confiables; el riesgo aumenta cuando se conectan agentes externos de terceros.

Para protegerse, los autores proponen un enfoque multinivel. Es necesario aplicar verificación externa para operaciones críticas — participación humana — en la que la ejecución se pausa y la confirmación se realiza por un canal separado no generativo. Se debe implantar verificación criptográfica de los participantes mediante AgentCard firmadas, para confirmar el origen y las capacidades declaradas del interlocutor. El anclaje del contexto implica crear un ancla de la tarea al inicio de la sesión y verificar semánticamente de forma continua las instrucciones entrantes, finalizando automáticamente el diálogo si se desvía de la intención original. Conviene enriquecer las interfaces con indicadores visibles de actividad — registros de llamadas, visualización de instrucciones remotas y etiquetas de comandos externos — lo que aumenta la probabilidad de detección de abusos por parte del usuario u operador.

Recomendaciones prácticas para las organizaciones: no considerar la comunicación interagente automáticamente segura y diseñar orquestadores con controles que minimicen la confianza y exijan autorización externa para operaciones de alto riesgo. Unit 42 recomienda realizar auditorías proactivas y contactar al servicio de respuesta ante incidentes ante actividad sospechosa.

Los autores subrayan que, en el momento del estudio, no se habían registrado casos masivos en sistemas reales, pero la técnica sigue siendo factible: basta convencer al agente cliente de establecer una sesión con un socio malicioso. A medida que crecen los ecosistemas multiagente y se intensifica la integración entre proveedores, este vector debe considerarse desde el inicio del diseño de las arquitecturas y políticas de seguridad de los sistemas de IA.