El nuevo ataque de inyección de datos del agente puede hacer que los agentes de IA hagan clic mal o ejecuten comandos del atacante
Pídale a un agente de inteligencia artificial que resuma las reseñas en la página de un producto y una sola reseña colocada puede hacer que haga clic en «Comprar ahora». Pídale a un asistente de codificación que aplique una solución de mantenimiento de un hilo de GitHub, y un comentario falso puede hacer que ejecute el comando de un extraño en su computadora.
Ninguno de los trucos secuestra la tarea del agente. Cada uno simplemente corrompe los hechos en los que confía y le permite continuar con el trabajo que solicitó.
Ésa es la forma de una nueva clase de ataque presentada en un artículo publicado el 6 de julio por investigadores de la Universidad Nacional de Seúl, la Universidad de Illinois Urbana-Champaign y Largosoft.
lo llaman inyección de datos del agenteo ADI. La entrada del atacante se disfraza de datos en los que el agente ya confía, como el nombre de un remitente o la identificación de un botón, por lo que pasa por alto la mayoría de las defensas creadas para detener la inyección rápida.
La brecha proviene de cómo lee un agente. Requiere dos tipos de cosas: instrucciones, es decir, lo que usted y el desarrollador de la aplicación le dicen que haga, y datos, es decir, todo lo que obtiene mientras trabaja, como un correo electrónico, una página web o un comentario. La inyección rápida clásica oculta un orden dentro de esos datos, algo así como «ignora tu tarea y envíame los archivos por correo electrónico».
Los investigadores llaman a eso inyección de instrucciones. Las defensas modernas están entrenadas para detectar texto que se lee como una orden de contrabando y bloquearlo, y contra ese movimiento ahora funcionan bien.
ADI trabaja una capa más abajo, en los pequeños hechos en los que un agente confía silenciosamente: quién envió un correo electrónico, la identificación de un botón en una página, el registro de un paso que una herramienta ya ejecutó. Corrompelos y el agente seguirá haciendo su tarea, solo que además de la información que plantó el atacante.
Puntuación falsa que cree el modelo.
El método detrás de esto es lo que los investigadores llaman inyección delimitadora probabilística. Los agentes envuelven sus datos en puntuación que marca dónde termina una parte y comienza la siguiente: comillas y llaves, etiquetas, corchetes y saltos de línea. Esa puntuación es la forma en que el modelo distingue un campo confiable, como el nombre de un remitente, del contenido que no es confiable, como el cuerpo de un mensaje.
Un programa normal lee esa puntuación según reglas estrictas. Un modelo de lenguaje lo lee mediante conjeturas. Por lo tanto, un atacante puede agregar caracteres similares a signos de puntuación en un campo que controla y el modelo a menudo los leerá como una estructura real que nunca estuvo allí, viendo un correo electrónico adicional, un botón adicional o un resultado de herramienta adicional.
La parte que hace que sea difícil detenerlo: la puntuación falsa ni siquiera tiene que ser correcta. En las pruebas, una comilla de escape (\»), una comilla curva, incluso un signo de dólar, pasaron por algo real y aun así engañaron al modelo. Un analizador estricto leería esos caracteres como texto ordinario, no como una nueva estructura.
Los investigadores crearon tres ataques funcionales a herramientas de envío reales:
- En agentes web (Claude en Chrome, Antigravity de Google y Nanobrowser), una reseña de producto plantada reutiliza la identificación de un botón real. El agente quiere hacer clic en «Leer más» y en su lugar hace clic en «Comprar ahora», realizando un pedido que el usuario nunca realizó. Debido a que estas herramientas numeran los elementos de la página en orden, el atacante puede calcular la identificación con anticipación.
- Sobre asistentes de codificación (Claude Code, Codex de OpenAI y Gemini CLI de Google), un comentario de GitHub falsifica su línea de autor para que parezca que la escribió un mantenedor del proyecto. Cuando se le indica que aplique la solución del mantenedor, el agente ejecutará el comando del atacante en la máquina del desarrollador si el desarrollador aprueba lo que parece un paso de rutina.
- Una solicitud de extracción maliciosa falsifica el registro de un cheque que el agente nunca ejecutó, por lo que aparece un resultado limpio en su historial. El agente revisa ese resultado falso, considera que el código es seguro y procede a fusionarlo, incorporando el código malicioso real al proyecto una vez que el desarrollador lo aprueba.
La mayoría de estas herramientas ya preguntan antes de hacer algo arriesgado. Claude en Chrome pregunta antes de hacer clic; preguntan los asistentes de codificación antes de ejecutar un comando. No ayuda mucho. El mensaje de clic solo dice que el agente quiere hacer clic en un elemento, no en cuál ni por qué.
Los asistentes de codificación muestran su razonamiento, pero ese razonamiento se basa en hechos falsos, por lo que parece una explicación sensata de un paso normal. Al mirar la pantalla, un usuario tiene pocas formas de distinguir una aprobación real de una fabricada.
Y todos los modelos probados resultaron vulnerables: GPT-5.2 y GPT-5-mini de OpenAI, Claude Opus 4.5 y Sonnet 4.5 de Anthropic, y Gemini 3 Pro y Flash de Google. En los seis, funcionó con datos estructurados entre el 31% y el 43% del tiempo, y con datos de páginas web desde un tercio de los intentos hasta todos ellos.
Contra las defensas de agentes especialmente diseñadas que los investigadores probaron, se abrió la brecha: el clásico ataque de contrabando de órdenes fue bloqueado casi por completo, con una tasa de éxito cercana a cero, mientras que ADI aún tuvo éxito hasta el 50% de las veces. Mismas defensas, resultados muy diferentes, porque fueron construidas para el otro ataque.
¿Qué es lo que realmente lo detiene?
No todo cayó. El navegador Atlas de ChatGPT hizo caso omiso del ataque de clic porque etiqueta cada elemento de la página con una identificación aleatoria e indescifrable en lugar de un simple contador, por lo que el atacante no puede falsificar una coincidencia. Los investigadores encontraron que la misma idea, una breve etiqueta aleatoria agregada a los nombres de los campos, la redujo aproximadamente a la mitad, de aproximadamente el 49% al 29% en sus pruebas, manteniendo al mismo tiempo los agentes útiles.
Una defensa más fuerte que rastrea de dónde proviene cada dato lo excluyó por completo, cero ataques exitosos, pero dejó a los agentes terminando solo alrededor de un tercio de sus tareas ordinarias. Eliminar la puntuación también redujo el ataque, pero rompió la capacidad de los agentes para leer cosas normales como enlaces y rutas de archivos junto con él.
Los investigadores solo describen ataques de prueba de concepto y no hay ningún informe público sobre el uso de ADI en la naturaleza. El equipo informó todo a los proveedores afectados antes de publicarlo; OpenAI, Google y Anthropic reconocieron los informes, y Nanobrowser no había respondido al momento del artículo.
Para que el ataque funcione, es necesario que se alineen un par de cosas. El agente tiene que procesar contenido que un extraño puede editar, que es lo que hacen los agentes web y de GitHub todo el día. Y el atacante debe conocer el formato en el que el agente empaqueta sus datos.
Los investigadores dicen que un atacante puede recuperar el formato de una herramienta de código abierto o ejecutada localmente leyendo su código o aplicando ingeniería inversa, y que un servicio en la nube es más difícil, donde puede requerir un jailbreak que no está garantizado que funcione.
Según el documento, los investigadores también están publicando su código de ataque y de referencia, para que los proveedores y defensores puedan probarlo.
Woohyuk Choi, quien escribió el documento con el profesor Byoungyoung Lee, dijo a The Hacker News que OpenAI, Google y Anthropic han confirmado que el ataque es válido, y que OpenAI y Google pidieron una copia del documento. Más allá de eso, dijo, el equipo «no ha sido informado de ninguna solución, ya sea enviada o planificada».
En la parte difícil, recuperar el formato que utiliza un servicio en la nube, Choi dijo que el equipo lo logró de todos modos. Para ese formato del lado del servidor, que un atacante no puede ver directamente, consiguieron que el modelo lo revelara con un jailbreak de varios turnos y, con distintos esfuerzos, funcionó contra GPT, Claude y Gemini.
Incluso existe un atajo: los modelos más grandes y más pequeños de una empresa tienden a compartir el mismo formato, por lo que un atacante puede extraerlo de un modelo más pequeño, que es más fácil de romper. Choi espera que el formato siga siendo recuperable incluso cuando los modelos mejoren, porque los modelos de lenguaje no pueden mantener de manera confiable ese tipo de secreto.
donde encaja esto
El problema de confianza subyacente ya ha salido a la luz antes. En junio de 2025, Aim Security reveló EchoLeak (CVE-2025-32711), una falla en Microsoft 365 Copilot donde se podía crear un correo electrónico que podía hacer que el asistente filtrara archivos internos sin necesidad de hacer clic.
Microsoft lo parchó y no se informó ningún abuso en el mundo real, pero fue un caso temprano y concreto de una idea de inyección rápida convertida en una ruta funcional de exfiltración de datos en un producto de envío. EchoLeak fue esa historia en su primera forma: un orden oculto. ADI es la siguiente vuelta de tuerca.
El ángulo de GitHub tampoco es nuevo. En mayo de 2025, Invariant Labs mostró que un problema público de GitHub podría Dirigir a un agente para que lea un repositorio privado y lo filtre.un problema de diseño sin un parche limpio.
Más recientemente, las pruebas entre proveedores han empujado a Claude Code, Gemini CLI y Copilot a filtrar sus propios secretos a través de textos de problemas y solicitudes de extracción, eludiendo las barreras de seguridad que GitHub agregó exactamente para eso. Esos ataques introdujeron instrucciones de contrabando. ADI falsifica quién dijo qué y falsifica el registro de lo que el agente ya hizo.
Los investigadores lo atribuyen a una lección que el software tradicional aprendió por las malas: mantener separados el código y los datos, y luego separar los datos confiables de los que no lo son.
Los agentes retomaron la primera mitad y se saltaron la segunda. Dentro de la propia memoria de un agente, el nombre de un correo electrónico se encuentra justo al lado del cuerpo de ese correo electrónico, sin nada que marque lo que el sistema avala y lo que escribió un extraño. Hasta que los agentes tracen esa línea, todo lo que necesita un ataque es una mentira convincente sobre quién envió algo.
