Inyección agnóstica a la consulta: secuestrar un agente de código pidas lo que pidas
Un artículo de finales de 2025 muestra que una carga oculta en las descripciones de herramientas de un agente de código se dispara con cualquier consulta, porque ataca el contexto invariable, no la pregunta. Una defensa de junio de 2026 responde a nivel del árbol sintáctico.
¿Qué es esto?
La mayoría de los estudios sobre inyección de prompt indirecta insertan una instrucción maliciosa y confían en que la tarea del usuario se parezca lo bastante como para activarla. QueryIPI, descrito en un artículo publicado en arXiv el 27 de octubre de 2025 (2510.23675), invierte esa premisa. Construye una carga que se dispara sin importar lo que se le pida al agente de código. Los autores lo llaman inyección indirecta agnóstica a la consulta (query-agnostic) y la presentan como el primer método de este tipo dirigido a agentes de código realistas.
El truco consiste en dejar de apuntar a la parte del prompt que cambia —la petición del usuario— y apuntar a la parte que nunca cambia: el prompt del sistema y las descripciones de herramientas. Estos elementos se cargan en cada turno, así que una carga anclada ahí está presente en cada tarea, no solo en la que el atacante adivinó.
Cómo funciona
Un agente de código ensambla su contexto a partir de tres capas: un prompt de sistema fijo, un conjunto de descripciones de herramientas (cada vez más entregadas por MCP) y la consulta variable del usuario. QueryIPI usa una descripción de herramienta como canal de inyección. Como esa descripción se lee en el contexto del modelo en cada invocación, una instrucción escondida ahí queda de forma permanente junto a las órdenes reales del agente.
Lo difícil es lograr que una sola descripción anule de forma fiable una intención de usuario arbitraria. QueryIPI lo consigue con una búsqueda iterativa basada en prompts: refina repetidamente la descripción maliciosa, mide si el agente la sigue a través de un abanico de tareas no relacionadas y conserva las variantes que generalizan. El artículo señala que esta búsqueda se vuelve abordable gracias a una debilidad común —los agentes de código tienden a filtrar su propio prompt interno—, lo que convierte una búsqueda a ciegas en una optimización restringida, casi de caja blanca. Las cadenas concretas no se reproducen aquí: importa el mecanismo, no un payload listo para copiar.
El resultado es una herramienta envenenada que parece normal al inspeccionarla pero orienta al agente hacia la acción del atacante —por ejemplo, ejecutar un comando de shell— sin importar si el usuario pidió refactorizar una función, escribir una prueba o explicar un archivo.
Por qué importa
Los agentes de código encajan casi a la perfección en la lethal trifecta de Simon Willison: tienen acceso a código fuente y secretos privados, ingieren contenido no confiable (dependencias, salidas de herramientas, archivos descargados) y pueden actuar mediante el shell y el sistema de archivos. La inyección agnóstica a la consulta elimina la mayor fuente de incertidumbre del atacante. Ya no necesita que la víctima formule la petición de una manera concreta: cualquier interacción con el agente envenenado es una oportunidad.
También traslada el riesgo a la cadena de suministro de las descripciones de herramientas. Un único servidor MCP malicioso o comprometido, una herramienta con “rug pull” o una entrada envenenada de un marketplace puede portar una carga que funciona contra todos los usuarios posteriores y todas las tareas. Es un modelo de amenaza muy distinto al de un documento único que debe coincidir con una consulta específica.
Defensas
El reflejo —filtrar el mensaje del usuario— no sirve, porque la carga vive en la capa de herramientas, no en la consulta. Los defensores deberían en cambio:
- Tratar las descripciones de herramientas como entrada no confiable. Fijar y revisar las descripciones, compararlas (diff) en cada actualización para detectar rug pulls, y preferir servidores de herramientas firmados o atestiguados frente a endpoints MCP anónimos.
- Aplicar separación arquitectónica. La capacidad de shell y sistema de archivos solo debería activarse en respuesta a instrucciones de un propietario verificado, por un canal de confianza, nunca a partir de contenido o descripciones obtenidas de fuentes externas. Es la Agents Rule of Two aplicada en concreto: no dejar que una entrada no confiable y una capacidad sensible compartan contexto sin una validación humana.
- Reducir la fuga de prompt. Dado que la búsqueda del ataque se apoya en que el agente expone su prompt de sistema y su esquema de herramientas, minimizar esa fuga aumenta el coste del atacante.
- Añadir detección en contexto de código. Una defensa de junio de 2026, CodeSentinel (2606.19235, publicada en junio de 2026), apunta exactamente a esta superficie. Trata la inyección en código como un problema de saneamiento a nivel de cada nodo del árbol de sintaxis concreta (CST), combinando estructura estática, anomalías de verosimilitud por nodo e influencia conductual a nivel de logits. Los autores afirman que supera a defensas previas (CodeGarrison, DePA, KillBadCode) en seis familias de ataque recientes.
Ninguna capa basta por sí sola; la respuesta duradera es mantener el contenido no confiable de las descripciones lejos de la acción privilegiada.
Estado
| Elemento | Detalle |
|---|---|
| Ataque (QueryIPI) | arXiv 2510.23675, primera publicación el 27 oct. 2025 |
| Canal de inyección | Descripciones de herramientas (contexto invariable) |
| Factor clave | Fuga del prompt de sistema / esquema de herramientas en agentes de código |
| Defensa (CodeSentinel) | arXiv 2606.19235, publicada en junio de 2026; saneamiento por nodo CST |
| Clase afectada | Agentes de código LLM con acceso a herramientas/MCP y capacidad de shell |