Si le pide a un agente de inteligencia artificial que resuma las reseñas en la página de un producto, puede colocar solo una reseña y hacer que haga clic en «Comprar ahora». Cuando le pides a un asistente de codificación que aplique una solución de mantenimiento de un hilo de GitHub, un comentario falso puede ejecutar el comando de un extraño en tu computadora.
Ninguno de los trucos secuestra las tareas del agente. Lo único que hace es socavar los hechos en los que cada uno confía y mantenerlos haciendo el trabajo que les pidió que hicieran.
Este es un nuevo tipo de ataque descrito en un artículo publicado el 6 de julio por investigadores de la Universidad Nacional de Seúl, la Universidad de Illinois en Urbana-Champaign y Largosoft.
A esto lo llaman inyección de datos del agente (ADI). Debido a que la entrada del atacante está disfrazada de datos en los que el agente ya confía, como el nombre del remitente o el ID del botón, elude la mayoría de las defensas creadas para detener la inyección rápida.
La brecha proviene de cómo se lee al agente. Se necesitan dos tipos de cosas. Uno son las instrucciones, es decir, lo que los usuarios y desarrolladores de aplicaciones le dicen a la aplicación que haga, y el otro son los datos, es decir, todo lo que se captura mientras trabaja, como correos electrónicos, páginas web, comentarios y más. La inyección de aviso clásica oculta instrucciones dentro de esos datos, como «Ignorar la tarea y enviar el archivo por correo electrónico».
Los investigadores llaman a esto «inyección de comandos». Los sistemas de defensa modernos han sido entrenados para encontrar y bloquear textos como órdenes de contrabando, y se han vuelto efectivos contra tales movimientos.
ADI funciona en una capa inferior, basándose en pequeños datos en los que los agentes confían secretamente, como el remitente de un correo electrónico, la identificación de un botón en una página o un registro de los pasos que la herramienta ya ha tomado. Incluso si los corrompe, el agente solo realizará tareas basadas en la información colocada por el atacante.
Falsos signos de puntuación que el modelo cree.
El método detrás de esto es lo que los investigadores llaman inyección delimitadora estocástica. El agente utiliza signos de puntuación alrededor de los datos para indicar dónde termina una parte y comienza la siguiente, como comillas, llaves, etiquetas, paréntesis y saltos de línea. Esta puntuación es una forma que tiene el modelo de transmitir campos confiables, como el nombre del remitente, por separado del contenido que no es confiable, como el cuerpo del mensaje.
Un programa típico lee esa puntuación según reglas estrictas. El modelo de lenguaje lo lee por inferencia. Por lo tanto, un atacante puede rociar los campos que controla con caracteres similares a signos de puntuación, y el modelo a menudo los leerá como estructuras reales que no existen y verá el resultado de un correo electrónico adicional, un botón adicional o una herramienta adicional.
Lo que es difícil de detener es que la puntuación falsa ni siquiera tiene que ser precisa. En nuestras pruebas, las comillas escapadas (\»), las comillas curvas e incluso los signos de dólar pasaron como reales, pero aun así engañaron al modelo. Un analizador estricto leería estos caracteres como texto normal, no como una nueva construcción.
Los investigadores construyeron tres ataques prácticos contra herramientas de envío reales.
Los agentes web (Claude de Chrome, Antigravity de Google, Nanobrowser) reutilizan el ID del botón real en las reseñas de productos plantadas. El agente hace clic en «Leer más» y en su lugar hace clic en «Comprar ahora», lo que significa que el usuario realiza un pedido que nunca antes había realizado. Estas herramientas numeran los elementos de la página de forma secuencial, lo que permite a un atacante determinar sus ID de antemano. En los asistentes de codificación (Claude Code, Codex de OpenAI y Gemini CLI de Google), los comentarios de GitHub falsifican líneas de autor para que parezcan escritas por el responsable del proyecto. Un agente al que se le haya ordenado aplicar una solución del mantenedor ejecutará los comandos del atacante en la máquina del desarrollador si el desarrollador aprueba lo que parece ser un procedimiento de rutina. Una solicitud de extracción maliciosa disfraza un registro de comprobaciones que el agente no realizó, de modo que el historial muestra resultados benignos. El agente revisa ese resultado falso, determina que el código es seguro, lo fusiona y, una vez que el desarrollador lo aprueba, incorpora el código malicioso real al proyecto.
La mayoría de estas herramientas ya le hacen preguntas antes de hacer algo peligroso. Claude de Chrome pregunta antes de hacer clic. El Asistente de codificación le preguntará antes de ejecutar el comando. No es muy útil. Las solicitudes de clic solo indican que el agente quiere hacer clic en un elemento, no en qué elemento hacer clic ni por qué.
El asistente de codificación le ofrece una inferencia, pero esa inferencia se basa en hechos falsos, por lo que parece una explicación sensata de un paso normal. Al mirar la pantalla, los usuarios tienen poca forma de distinguir entre aprobaciones reales y fabricadas.
La vulnerabilidad se encontró en todos los modelos probados, incluidos 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, los datos estructurados funcionaron entre el 31% y el 43% del tiempo, y los datos de las páginas web funcionaron desde un tercio de las pruebas hasta todas las pruebas.
Se abrió una brecha para las defensas de agentes dedicados que los investigadores probaron. Si bien los ataques clásicos de contrabando de órdenes fueron bloqueados casi por completo y tuvieron una tasa de éxito cercana a cero, ADI aún tuvo éxito hasta el 50% de las veces. La misma defensa tiene resultados muy diferentes porque fue construida para otros ataques.
¿Qué es lo que realmente lo detiene?
No todo se vino abajo. El navegador Atlas de ChatGPT ignoró los ataques 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 tanto, un atacante no puede forjar una cerilla. Los investigadores descubrieron la misma idea. Agregar una etiqueta aleatoria corta al nombre del campo casi lo redujo a la mitad, de aproximadamente 49% a 29% en nuestras pruebas, manteniendo al mismo tiempo la utilidad del agente.
Defensas aún más fuertes que rastreaban de dónde provenían todos los datos cerraron el ataque por completo, con cero éxitos, pero el agente solo pudo completar aproximadamente un tercio de sus tareas normales. Eliminar la puntuación también reduce los ataques, pero también interrumpe la capacidad del agente para leer elementos habituales, como enlaces y rutas de archivos, junto con la puntuación.
Los investigadores solo describen ataques de prueba de concepto y no hay informes públicos sobre el uso de ADI en la naturaleza. El equipo ha comunicado todo a los proveedores afectados antes de publicarlo. OpenAI, Google y Anthropic han confirmado el informe, pero Nanobrowser no ha respondido al momento de esta edición.
Se deben cumplir varias condiciones para que el ataque funcione. Los agentes necesitan manejar contenido que pueden ser editados por extraños, y los agentes web y los agentes de GitHub hacen esto todo el día. El atacante también necesita conocer el formato en el que el agente comprime los datos.
Los investigadores dicen que si bien un atacante puede recuperar formatos de herramientas de código abierto o ejecutados localmente leyendo o aplicando ingeniería inversa a su código, los servicios en la nube son más difíciles ya que pueden requerir jailbreak, cuyo funcionamiento no está garantizado.
Los investigadores también publicaron puntos de referencia y códigos de ataque para que los proveedores y defensores puedan probarlos, según el documento.
Woohyuk Choi, coautor del artículo con el profesor Byoungyoung Lee, dijo a The Hacker News que OpenAI, Google y Anthropic confirmaron que el ataque fue efectivo y que OpenAI y Google solicitaron copias del artículo. Más allá de eso, dijo que el equipo «no ha sido notificado de ninguna solución, ya sea enviada o planificada».
En cuanto a la parte difícil de restaurar el formato utilizado por el servicio en la nube, Choi dijo que el equipo lo logró de todos modos. Para los formatos del lado del servidor que no son directamente visibles para los atacantes, expusimos el modelo mediante un jailbreak de varios turnos y trabajamos contra GPT, Claude y Gemini con varios esfuerzos.
También hay atajos. Debido a que los modelos grandes y pequeños de una empresa tienden a compartir el mismo formato, un atacante puede plagiarlo del modelo más pequeño, lo que facilita su descifrado. Choi espera que este formato siga siendo recuperable incluso cuando los modelos mejoren, ya que los modelos lingüísticos no pueden contener tales secretos de manera confiable.
Donde esto aplica
Los problemas de confianza subyacentes han surgido antes. En junio de 2025, Aim Security reveló EchoLeak (CVE-2025-32711), una falla en Microsoft 365 Copilot. Esto es algo que le permite redactar un correo electrónico que filtra archivos internos a su asistente sin hacer clic.
Aunque Microsoft parchó esto y no se informaron exploits reales, este fue un ejemplo concreto temprano de la idea de que la inyección rápida se convirtió en una ruta viable de extracción de datos en un producto de envío. EchoLeak fue su primera forma, una historia de comandos ocultos. ADI es la próxima revolución del tornillo.
El ángulo de GitHub tampoco es nuevo. En mayo de 2025, Invariant Labs indicó que un problema de publicación en GitHub podría permitir a los agentes leer y filtrar repositorios privados. Este es un problema de diseño sin un parche limpio.
Más recientemente, las pruebas entre proveedores han provocado que Claude Code, Gemini CLI y Copilot filtren secretos de propiedad a través de textos de problemas y solicitudes de extracción, evitando las barreras de seguridad que GitHub ha agregado para hacer precisamente eso. Estos ataques involucraron instrucciones contrabandeadas. ADI falsifica quién dijo qué y falsifica registros de lo que los agentes ya han hecho.
Los investigadores atribuyeron esto a una lección que el software tradicional aprendió por las malas: separar el código y los datos, y luego separar los datos confiables de los que no lo son.
El agente tomó la primera parte y se saltó la segunda. En la propia memoria del agente, el nombre en el correo electrónico está justo al lado del cuerpo del correo electrónico y no hay nada que el sistema garantice ni indique que un extraño haya ingresado en él. Hasta que un agente trace esa línea, todo lo que un ataque requiere es una mentira convincente sobre quién envió algo.
Source link
