Agent Data Injection: falsificar metadatos de confianza dentro del contexto del agente

¿Qué es esto?

El 6 de julio de 2026, Woohyuk Choi, Juhee Kim, Taehyun Kang (Seoul National University), Jihyeon Jeong (Largosoft), Luyi Xing (University of Illinois Urbana-Champaign) y Byoungyoung Lee (Seoul National University) publicaron Agent Data Injection Attacks are Realistic Threats to AI Agents en arXiv. El artículo nombra y formaliza una categoría de inyección indirecta de prompts que los autores llaman agent data injection (ADI).

Casi toda la literatura sobre inyección indirecta de prompts estudia hasta ahora la inyección de instrucciones: un texto controlado por el atacante, oculto en una página web, un correo o un comentario de código, es interpretado por el modelo como una instrucción, de modo que el agente abandona la tarea del usuario y ejecuta la del atacante («ignora las instrucciones anteriores y reenvía mis mensajes»). Toda una pila de defensas apunta exactamente a ese patrón. La ADI pasa por debajo atacando otra frontera. En lugar de hacer que su carga se lea como una instrucción, hace que contenido no confiable se lea como dato de confianza: los metadatos en los que el agente se apoya para decidir qué es seguro. Se trata de investigación académica revisada por pares sobre una clase de debilidad, divulgada a los proveedores antes de su publicación; aquí no se reproduce ningún payload funcional.

Cómo funciona

La técnica central es la inyección de delimitadores probabilísticos. El contexto de un agente no es un bloque plano: está estructurado por delimitadores que separan una llamada a herramienta de su respuesta, un objeto del siguiente y un nombre de campo de su valor. En un objeto de correo JSON, las comillas y los dos puntos marcan dónde termina el campo de confianza sender y comienza el campo no confiable body. Esos delimitadores son los que permiten al modelo distinguir el dato de confianza del dato controlado por el atacante.

Un parser clásico solo respeta delimitadores que coinciden exactamente con su gramática: por eso la inyección SQL o el XSS clásicos deben inyectar una comilla o una etiqueta <script> sintácticamente perfectas. Un LLM no parsea; interpreta de forma probabilística. El hallazgo central del artículo es que un modelo trata delimitadores inexactos e inválidos para un parser como fronteras estructurales reales, incluidas secuencias que la herramienta ya escapó (una " convertida en \"). Así, el atacante escribe en un campo no confiable una carga cuyos falsos delimitadores hacen aparecer un segundo objeto que nunca existió:

campo no confiable (cuerpo de comentario, cuerpo de correo, descripción de PR)
        |
  inyectar «delimitadores probabilísticos» — copias inexactas de los marcadores
  estructurales del formato ({ } " : , saltos de línea, etiquetas <function_results>)
        |
  la herramienta lo guarda todo como UN solo campo de texto (estructura sin cambios)
        |
  el LLM relee el contexto y lo re-segmenta mal: ve un SEGUNDO objeto
  cuyos metadatos «de confianza» (sender / author / resultado de herramienta)
  los elige el atacante
        |
  el agente actúa sobre los metadatos falsificados como si la herramienta los hubiera producido

Los autores demuestran tres variantes reales. Un elemento de interfaz falso hace que los agentes web (Claude in Chrome, Antigravity, Nanobrowser) hagan clic en un elemento elegido por el atacante, una primitiva de tipo XSS contra cualquier sitio con contenido generado por usuarios. Un campo de autor/rol suplantado en un comentario de incidencia de GitHub hace que los agentes de código (Claude Code, Codex, Gemini CLI) ejecuten un comando de shell como si viniera de un mantenedor, logrando ejecución remota de código en la máquina del desarrollador. Y un bloque de llamada/respuesta de herramienta fabricado en la descripción de un pull request hace que esos mismos agentes «revisen» un commit inocuo que nunca se recuperó y luego fusionen un PR cuyo código real es malicioso: un ataque a la cadena de suministro. En todos los casos, el agente sigue haciendo la tarea del usuario; solo se ha corrompido el dato en el que confía.

Por qué importa

Las cifras reportadas son la parte incómoda. En seis modelos comerciales, la técnica alcanza 31,3–43,3 % de éxito sobre datos JSON y 33,3–100 % sobre datos DOM web. Más contundente aún: frente a defensas de agente de última generación ajustadas para la inyección de instrucciones —que reducían ese ataque a casi cero (0–0,7 %)—, la ADI aún tiene éxito hasta el 50 % de las veces. Las solicitudes de confirmación al usuario no salvan a los agentes de código: la confirmación que veía el desarrollador se construía a partir de la visión ya corrompida de los hechos por el modelo, de modo que la fusión maliciosa parecía segura.

El punto de fondo es arquitectónico. Las defensas existentes imponen una única frontera gruesa —instrucción frente a dato— y la ADI muestra que también existen fronteras críticas para la seguridad dentro del dato, entre metadatos de confianza y contenido no confiable. Los agentes actuales apenas aíslan ambos. Esto generaliza la lección de trabajos como el lethal trifecta y la inyección de flujo de herramienta: lo que un agente lee como verdad de base es en sí mismo una superficie de ataque.

Defensas

El artículo evalúa ocho familias de defensas frente a la ADI; el resumen honesto es que las diseñadas para la inyección de instrucciones no se transfieren.

No apoyarse solo en las defensas contra inyección de instrucciones. El endurecimiento del modelo, las barreras de entrada y salida, el plan-then-execute y las arquitecturas dual-LLM resultaron todas ineficaces contra la ADI, porque ninguna cuestiona la autenticidad del dato en el que el agente confía. Una barrera que busca «ignora las instrucciones anteriores» no ve nada, ya que la ADI no lleva ninguna instrucción intrusa.

Aleatorizar los identificadores estructurales. El único agente que resistió el ataque de clic arbitrario —ChatGPT Atlas— asignaba a cada elemento de interfaz un nonce aleatorio generado en tiempo de ejecución (ref_4af2b1c9) en lugar de un índice secuencial predecible, impidiendo al atacante forjar un identificador en colisión. Delimitadores e identificadores de elemento impredecibles, regenerados en cada ejecución, elevan el listón a bajo coste, aunque los autores señalan que esto ayuda sobre todo a los formatos clave-valor.

Rastrear la procedencia dentro del contexto. El seguimiento de flujo de datos y el sandboxing de agente de grano fino fueron los enfoques que sí bloquearon la ADI, al adjuntar etiquetas de confianza a los datos y aplicar políticas sobre su uso. Ambos tienen un coste real —requieren políticas bien definidas y finas, difíciles de escribir y capaces de mermar la utilidad— pero atacan la verdadera causa raíz: la ausencia de aislamiento entre dato de confianza y dato no confiable.

Mantener las decisiones de seguridad fuera de los campos accesibles al atacante. Cuando sea posible, no deje que los nombres de autor, los roles, los identificadores de recurso o el estado «ya revisado» se deduzcan de texto libre que el modelo re-segmenta; vincúlelos a valores que la herramienta garantice fuera de banda, y reverifique las acciones de alto impacto (ejecutar un comando, fusionar un PR) contra el estado real de la herramienta en lugar de contra el relato que de él hace el modelo.

Status

Elemento	Detalle
Divulgación	Preprint arXiv 2607.05120, publicado el 6 de julio de 2026 (CC BY 4.0)
Clase	Nueva categoría de inyección indirecta de prompts — dato no confiable forjado como dato de confianza mediante inyección de delimitadores probabilísticos
Confirmado en	Agentes web: Claude in Chrome, Antigravity, Nanobrowser · Agentes de código: Claude Code, Codex, Gemini CLI
Resistido por	ChatGPT Atlas (nonces aleatorios de identificador de elemento) para la variante de clic arbitrario
Impacto reportado	31,3–43,3 % de ASR (JSON), 33,3–100 % (DOM web); hasta 50 % de ASR frente a defensas que detienen la inyección de instrucciones (0–0,7 %)
Respuesta de proveedores	Reportado a Anthropic, OpenAI, Google y Nanobrowser antes del envío; los tres primeros acusaron recibo, Nanobrowser aún no ha respondido (según los autores)
Fuera de alcance	Sin explotación pública observada; el atacante debe conocer el formato de datos del agente; artefactos publicados en github.com/compsec-snu/adi