Entrar, evadir, escapar: anatomía de los ataques de secuestro de agentes de IA
El 7 de agosto de 2026, Varonis Threat Labs divulgó RovoBlast, una vulnerabilidad en el asistente de IA Rovo de Atlassian que permite a un atacante exfiltrar datos de Jira, Confluence, Slack y otras cincuenta plataformas conectadas con un solo enlace manipulado. Es el último caso de un patrón que ha pasado de pruebas de concepto aisladas a amenaza empresarial sistémica en menos de dieciocho meses. El patrón ya tiene nombre: Enter, Evade, Escape (entrar, evadir, escapar).
Todos los grandes asistentes de IA empresariales (Microsoft Copilot, Google Gemini, Salesforce Agentforce, Atlassian Rovo, Amazon Q, GitLab Duo, ChatGPT, Perplexity) han sido atacados. Los ataques comparten una anatomía común. Entender esa anatomía es el primer paso para defenderse de lo que se está convirtiendo rápidamente en la superficie de ataque que define 2026.
Cómo funciona RovoBlast
El ataque es desarmantemente sencillo. Rovo Chat de Atlassian acepta un parámetro de URL llamado rovoChatPrompt que rellena automáticamente la entrada del chat. El atacante construye un enlace como:
https://home.atlassian.com/chat?rovoChatPathway=chat&rovoChatPrompt=[attacker instructions]Cuando la víctima hace clic en el enlace (compartido en un correo, un mensaje directo de Slack o un comentario de Jira), el prompt inyectado se ejecuta en su sesión autenticada de Rovo. Sin aviso ni diálogo de confirmación. El ResearchAgent de Rovo busca entonces de forma autónoma en todas las plataformas conectadas (Jira, Confluence, Bitbucket, Slack, Microsoft 365, Google Workspace), recopila los resultados y puede enviarlos a una URL externa como parte de su capacidad integrada de «investigación».
El campo del ID de organización puede dejarse vacío: Rovo redirige automáticamente a la organización por defecto del usuario, así que el atacante ni siquiera necesita saber a qué instancia de Atlassian apuntar.
El patrón está en todas partes
RovoBlast no es una excepción. Es el undécimo gran ataque de secuestro de agentes de IA divulgado en dieciocho meses, y el patrón se acelera. Todas las grandes plataformas de IA empresariales han sido atacadas, la mayoría más de una vez.
Lo que hace estos ataques especialmente peligrosos:
- Un solo clic o ninguno. La mayoría requieren un clic en un enlace de apariencia legítima. Varios (EchoLeak, ShadowLeak, AgentFlayer) no requieren ninguna interacción: basta con que llegue un correo manipulado a la bandeja de entrada.
- Sin malware. No se instala nada. La carga del ataque es texto plano (un prompt) inyectado en un contexto en el que confía el agente de IA.
- Radio de impacto federado. Los agentes de IA empresariales están conectados al correo, los archivos, los repositorios de código, el CRM, los sistemas de RR. HH. y más. Una sola sesión comprometida de un agente puede llegar a todos ellos.
- Invisibles para el usuario. La exfiltración se produce a través del uso normal de herramientas de la IA: obtener URL, renderizar imágenes, navegar por la web. No hay ninguna señal visible de que los datos han salido del edificio.
- Sin un registro de auditoría significativo. Las acciones del agente son idénticas al uso legítimo. Distinguir en los logs una búsqueda dirigida por un atacante de una dirigida por el usuario a menudo es imposible.
Por qué todos los fabricantes siguen siendo atacados
La razón por la que este patrón se repite en todos los fabricantes es estructural, no accidental. Los agentes de IA empresariales se basan en una tensión arquitectónica fundamental: deben tratar las instrucciones del usuario como fiables, pero no pueden distinguir de forma fiable las instrucciones del usuario de las del atacante inyectadas en el mismo contexto.
Un correo, un ticket de Jira, un mensaje de Slack, un comentario en el código, una invitación de calendario: todo son datos que ingiere el agente de IA. Pero también son canales en los que pueden escribir actores externos. Cuando el agente procesa un correo envenenado junto a otros legítimos, no tiene ningún mecanismo fiable para separar «esto es lo que pidió el usuario» de «esto es lo que plantó el atacante».
Este es el problema de la inyección indirecta de prompts, y está sin resolver en la capa del modelo. Todas las barreras que han desplegado los fabricantes (filtros de contenido, clasificadores de seguridad, listas de dominios permitidos, diálogos de confirmación) se han eludido a los pocos meses de desplegarse. Los ataques no explotan fallos en el sentido tradicional. Explotan el hueco entre cómo procesan el lenguaje los agentes de IA y cómo funcionan las fronteras de seguridad.
El dominio de 5 $ que rompió Salesforce
ForcedLeak, el ataque a Salesforce Agentforce, ilustra lo finas que son las defensas. Noma Security descubrió que la Content Security Policy (CSP) de Salesforce (la lista de dominios a los que el agente puede enviar datos) incluía un dominio caducado. Lo compraron por 5 $. Después enviaron un formulario Web-to-Lead malicioso (algo que cualquier visitante anónimo puede hacer) con instrucciones ocultas. Agentforce procesó el formulario, siguió las instrucciones inyectadas y exfiltró datos del CRM al dominio recién comprado por el atacante. CVSS 9.4.
Sin autenticación. Sin malware. Sin exploit en el sentido tradicional. La compra de un dominio de 5 $, el envío de un formulario web y un prompt: ese fue todo el ataque.
Sin clic es la nueva normalidad
La tendencia más alarmante es el paso a los ataques sin clic. De los catorce ataques divulgados, nueve no requieren ninguna interacción de la víctima. El atacante envía un correo, hace un commit, envía un formulario o publica un mensaje, y el agente de IA lo procesa automáticamente.
EchoLeak (CVSS 9.3; desglosa el vector) es el ejemplo canónico. Aim Security descubrió que bastaba con enviar un solo correo manipulado a un usuario de Microsoft 365. Cuando Copilot procesaba el correo como parte de su contexto, las instrucciones ocultas hacían que accediera a archivos internos y exfiltrara su contenido a un servidor controlado por el atacante. La víctima nunca hizo clic en nada. Ni siquiera llegó a leer el correo.
ShadowLeak fue más allá: texto oculto blanco sobre blanco en un correo, invisible para el lector humano, hizo que el agente Deep Research de ChatGPT exfiltrara datos de Gmail íntegramente desde el servidor. El usuario no vio nada raro porque el ataque ocurrió en la capa de procesamiento de la IA, no en la interfaz.
Qué deberían hacer ahora los líderes de seguridad
La verdad incómoda: hoy no hay una solución completa para la inyección indirecta de prompts en la capa del modelo. Pero hay pasos concretos que reducen de forma material la superficie de ataque.
El panorama general
La adopción de la IA en las empresas no se está frenando. Gartner estima que para finales de 2026 más del 60 % de las grandes empresas habrá desplegado al menos un agente de IA con acceso a datos internos. Cada uno de esos despliegues arrastra la misma tensión arquitectónica que produjo estos catorce ataques.
Los fabricantes no están ignorando el problema: Microsoft, Atlassian, Salesforce, Google y OpenAI han corregido las vulnerabilidades concretas tras su divulgación. Pero parchear ataques individuales no corrige el patrón de fondo. Cada parche aborda un vector de entrada, una técnica de evasión, un canal de escape, mientras la superficie de ataque crece con cada nueva integración y cada nueva capacidad de los agentes.
Para los líderes de seguridad, la conclusión no es evitar los agentes de IA. Es desplegarlos con el mismo rigor que aplicarías a cualquier otro sistema con acceso privilegiado a tus datos: mínimo privilegio, monitoreo, pruebas y la suposición de que el perímetro alrededor del contexto del agente será vulnerado.
Los ataques van a seguir llegando. La pregunta es si el radio de impacto de tu agente de IA es del tamaño de una sola bandeja de entrada o del tamaño de toda tu organización.