IterInject: cuando un LLM optimiza sus propias inyecciones de prompt indirectas

¿De qué se trata?

El 23 de mayo de 2026, investigadores de la Shanghai Jiao Tong University y la Universidad de Hong Kong publicaron en arXiv IterInject: Indirect Prompt Injection Against LLM Agents via Feedback-Guided Iterative Optimization. El artículo no reclama un nuevo patrón de payload. Reclama algo más incómodo: que el problema de búsqueda en el corazón de la inyección de prompt indirecta (IPI) puede automatizarse, y que el optimizador resultante empuja las tasas de éxito de ataque muy por encima de lo que payloads estáticos o construidos a mano han conseguido alcanzar en los benchmarks AgentDojo e InjecAgent.

Las cifras destacadas, tomadas de la evaluación del artículo: sobre las 510 instancias de ataque de AgentDojo distribuidas en cuatro conjuntos de tareas, IterInject obtiene el mejor ASR global en cada uno de los cuatro modelos víctima probados, con la mayor brecha sobre DeepSeek (47,8 % frente al 32,9 % de la baseline estática más fuerte). En InjecAgent, el ASR total pasa de casi cero con prompts estáticos a 33–90 % según la víctima. Los autores también ejecutan un experimento de extensión contra Claude Code, un agente de programación de nivel producción con defensas en capas, y reportan 5 de 9 objetivos comprometidos con payloads optimizados.

Cómo funciona

IterInject trata la elaboración de payloads como un bucle cerrado de tres componentes, todos descritos en el artículo a nivel de mecanismo — no a nivel de un exploit listo para copiar.

                +-------------------------+
                |   agente LLM víctima    |
                |   (ejecuta la tarea     |
                |    del benchmark)       |
                +-----------+-------------+
                            |
                            v
                +-------------------------+
                |  diagnosticador por     |
                |  reglas -> etiqueta     |
                |  estructurada +         |
                |  descripción            |
                +-----------+-------------+
                            |
                            v
                +-------------------------+
                |  optimizador LLM        |
                |  condicionado al        |
                |  registro completo      |
                |  -> siguiente payload   |
                +-----------+-------------+
                            |
                            v
                  (bucle, con síntesis
                   de semillas para
                   ampliar el espacio
                   de estrategias)

Tres propiedades importan para los defensores.

Primero, el diagnosticador está estructurado, no es texto libre. Cada intento recibe una etiqueta de resultado conductual (herramienta invocada, parámetro exfiltrado, rechazo, sin efecto, desviación parcial), lo que evita que el optimizador opere sobre una única señal binaria de éxito. Esto es lo que permite al bucle escapar de los óptimos locales en los que los prompts IPI hechos a mano suelen quedarse atascados.

Segundo, el optimizador es a su vez un LLM condicionado al registro de ejecución. No necesita acceso al gradiente del modelo víctima, lo que vuelve operativa la técnica contra agentes de producción cerrados. Es la misma observación que ha guiado el trabajo de jailbreak adaptativo de los últimos dieciocho meses (véase The Attacker Moves Second) — aplicada aquí específicamente a la superficie IPI.

Tercero, los autores añaden, sobre los resultados empíricos, un análisis mecanicista. Reportan un umbral mediado por la atención: los payloads tienen éxito cuando el contenido inyectado capta suficiente atención del modelo para desviarla del prompt de sistema original y cruzar una frontera específica del modelo. Intervenciones causales sobre las cabezas de atención implicadas modifican el resultado. La implicación es que las defensas basadas en la “separación de datos e instrucciones” — paradigma dominante de los guardrails IPI hoy — están peleando en el eje equivocado: sanean el texto sin cambiar la forma en que la atención se asigna una vez ese texto está en la ventana de contexto.

Por qué importa

El encuadre de “nuevo ataque” no es el correcto. La técnica generaliza un procedimiento de búsqueda ya presente en la literatura para jailbreaks (PAIR, TAP, optimización automática de prompts) y lo traslada limpiamente al escenario IPI. Lo nuevo es el piso que la búsqueda en bucle cerrado fija ahora al atacante.

Tres conclusiones para los equipos que despliegan agentes.

La brecha entre benchmarks de investigación y agentes de producción es pequeña. Cinco de nueve objetivos de Claude Code comprometidos bajo un bucle adaptativo es el mismo orden de magnitud que los benchmarks de laboratorio. Si ejecuta un agente de programación contra archivos fuente, pull requests o documentación externa no confiable, el modelo de amenaza ya no es “un humano determinado escribe el prompt perfecto” — es “un LLM escribe unos cientos durante la noche y se queda con los que funcionaron”.

El hallazgo mecanicista socava categorías enteras de defensas. Si el éxito está gobernado por la asignación de atención y no por la distinguibilidad de forma entre datos e instrucciones, entonces el etiquetado de prefijos, el etiquetado de roles y el saneamiento de entradas seguirán produciendo los mismos números decepcionantes en AgentDojo — las defensas que reducen el ASR también reducen la utilidad, y los resultados de IterInject amplían esa brecha, no la cierran.

La evaluación debe asumir adaptatividad. Un guardrail que resiste contra un corpus fijo de cadenas de inyección dice casi nada sobre su comportamiento bajo un optimizador guiado por feedback. Es ya una tercera línea independiente de evidencia — Carlini et al. sobre jailbreaks, Abdelnabi y Bagdasarian sobre integridad contextual, y ahora IterInject sobre IPI específicamente — diciendo lo mismo.

Defensas

El propio artículo cierra con implicaciones defensivas. Lo que sigue es concreto y aplicable hoy:

1. Deje de medir las defensas IPI sólo con benchmarks estáticos. Si la evaluación de su guardrail es una lista fija de cadenas de ataque, replique el bucle de IterInject (o su predecesor público AgentVigil) contra su stack antes de desplegar. Los ASR de una evaluación estática estarán entre 20 y 60 puntos porcentuales por debajo de lo que alcanza un atacante adaptativo.

2. Restrinja la superficie de atención en la capa de agente, no sólo en la capa de prompt. Reduzca el tamaño del bloque no confiable que entra al contexto (chunking, resumen vía un modelo limpio, ingesta sólo por extracción estructurada), mantenga las definiciones de herramientas y el prompt del sistema en un rol o segmento separado, y limite la capacidad por herramienta al mínimo necesario para la tarea en curso. El objetivo es impedir que el contenido inyectado acumule la masa atencional suficiente para cruzar el umbral identificado en el artículo.

3. Detecte en la capa de acción. Honeypots de llamadas a herramientas — herramientas falsas, credenciales falsas, parámetros en lista blanca — dan una señal limpia de compromiso que no depende de analizar la intención en lenguaje natural. Véase AgentShield (10 de mayo de 2026) para una instanciación publicada, y nuestro artículo sobre defensas por análisis de resultados de herramientas para técnicas complementarias.

4. Asuma que Claude Code (y equivalentes) forman parte de su superficie de ataque. El resultado de extensión del artículo no es un bug específico de Claude Code; es un optimizador IPI genérico aplicado a un objetivo con defensas en capas con un éxito no trivial. Trate por defecto como no confiables los contenidos externos que su agente de programación lee — issues, PR, README de dependencias, salidas de herramientas — y condicione las acciones destructivas a una confirmación humana explícita.

5. Limite la tasa y registre el bucle de búsqueda. Un optimizador IPI adaptativo es ruidoso desde el lado API: emite muchas llamadas similares en una ventana corta, con señales de éxito monótonamente crecientes. La detección de anomalías en el lado API sobre similitud de prompts, diversidad de llamadas a herramientas y patrones de reintento por sesión es un control secundario barato, antes incluso de tocar el diseño del agente.

Estado

Elemento	Referencia	Fecha	Notas
Artículo IterInject	arXiv 2605.24659	2026-05-23	Autores SJTU + HKU
Benchmark AgentDojo	spylab.ai / GitHub	en vivo	510 instancias de ataque, cuatro conjuntos; usado por US/UK AISI
Benchmark InjecAgent	arXiv 2403.02691	2024-03	ASR total IterInject: 33–90 % sobre cuatro víctimas
Experimento de extensión Claude Code	Mismo artículo, §extensión	2026-05-23	5 de 9 objetivos comprometidos
Trabajo compañero de evaluación adversarial	The Attacker Moves Second, arXiv 2510.09023	2025-10	Misma conclusión sobre 12 defensas, lado jailbreak
Resultado de Integridad Contextual	arXiv 2605.17634	2026-05-17	Compañero teórico: la separación es el marco equivocado

El encuadre adecuado para quienes construyen no es “otro artículo de IPI”. Es “un procedimiento de búsqueda automatizado se sitúa ahora entre su guardrail y un atacante, y el piso que esa búsqueda alcanza sube cada trimestre”. Recalibre sus evaluaciones IPI contra un optimizador adaptativo, o lea la próxima ronda de cifras de benchmark como una descripción de su propio agente en producción.