Dónde se inyecta importa: los agentes confían más en unas zonas de su entorno que en otras
Un artículo de arXiv del 28 de octubre de 2026 fija el texto inyectado y solo cambia su ubicación: los README y archivos TODO influyen mucho más en los agentes de código que el código o los datos.
What is this?
El 28 de octubre de 2026, un equipo que incluye a Chengquan Guo, Bo Li y Jianfeng Gao publicó “Where You Inject Matters: The Trust Region Effect in LLM Agents” (arXiv:2610.38867, cs.AI, con referencias cruzadas a cs.CR y cs.LG). La mayor parte de la investigación sobre inyección de prompts indirecta pregunta qué dice el texto malicioso. Este trabajo fija el texto y varía solo dónde aparece en el entorno del agente. La susceptibilidad cambia notablemente según la ubicación. Los autores lo llaman efecto de región de confianza: los agentes confían implícitamente en distintas partes de su entorno en distinto grado.
Resultado principal en programación: con GPT-5.4, una instrucción insegura colocada en un archivo de documentación (un README o TODO) fue seguida de media unas 2,6 veces más a menudo que la misma instrucción en un archivo de código o de datos. Es un estudio de medición sobre un punto ciego defensivo, no un exploit.
How it works
Los autores construyeron tres bancos de prueba agénticos: programación (sobre Terminal-Bench-2), uso de herramientas (sobre AgentDojo) y flujo de trabajo diario (sobre DecodingTrust-Agent). En conjunto incluyen 30 tareas benignas, 24 riesgos de inyección y 36 superficies del entorno. Cada inyección se coloca en un nivel grueso (qué superficie: tipo de archivo, correo, mensaje de Slack, reseña) y en un nivel fino (inicio, mitad o final del contenido). El éxito lo juzgan verificadores deterministas basados en scripts, no un LLM, y la métrica solo cuenta las inyecciones que el agente realmente leyó.
Patrones reportados (cifras tal como las da el artículo, que prueba modelos de varios proveedores):
- La superficie importa. En el banco de programación con GPT-5.4, un riesgo de tipo reconocimiento tuvo éxito el 86 % de las veces desde un README y el 61 % desde un TODO, frente al 19 % desde archivos de código y el 30 % desde archivos de datos. En el banco de flujo de trabajo, un riesgo de tipo phishing alcanzó el 23 % vía GitHub, el 17 % vía Slack, el 9 % vía Confluence y el 0 % vía Jira.
- La posición importa menos, pero de forma consistente. El contenido al final de un documento fue el más eficaz en los tres dominios.
- Los modelos difieren mucho. Las tasas de éxito condicionales globales en programación iban de casi cero en algunos modelos de frontera al 67,0 % de Gemini-3.1-Pro, con GPT-5.4 en el 12,2 %.
- Un atacante puede aprender la ubicación. Un atacante pequeño entrenado para optimizar conjuntamente contenido y ubicación alcanzó un 59,1 % de éxito frente al 37,0 % de la optimización solo del contenido, y se transfirió a otro modelo víctima donde las plantillas de referencia obtuvieron 0 %.
Aquí no se reproduce ninguna carga útil. La conclusión es estructural: la confianza de un agente es desigual y aprendible.
Why it matters
Los proyectos suelen tratar la documentación como inerte. El artículo muestra que, para los agentes, los archivos de documentación están entre las entradas más influyentes, lo que coincide con investigación práctica publicada unos días antes. El 22 de octubre de 2026, Forever Security describió cómo una página web puede dejar silenciosamente un AGENTS.md o CLAUDE.md en la carpeta Descargas del usuario; un agente de código lanzado después en esa carpeta lo trata como instrucciones de proyecto de confianza. Según los autores, esto depende de la confianza del agente en su carpeta de trabajo, no de un fallo del producto. Véase también la inyección AGENTS.md en la cadena de suministro y la jerarquía de instrucciones.
Los límites también cuentan. El artículo describe comportamiento, no mecanismo interno; cubre tres bancos de prueba y solo inyección indirecta; y su atacante se entrenó contra un único modelo víctima. Los porcentajes indican riesgo relativo, no tasas de producción.
Defenses
El artículo no propone una defensa concreta; sostiene que las defensas deben tener en cuenta la ubicación al limitar la influencia del contenido no confiable. Pasos prácticos que se derivan:
- Tratar la documentación como entrada no confiable. Los README, TODO, CONTRIBUTING y archivos de instrucciones de agente de repositorios o carpetas que no escribió usted no deben tener autoridad de operador.
- No ejecutar agentes en carpetas escribibles desde la web, como Descargas, y revisar los archivos de instrucciones que no haya escrito antes de que un agente los cargue.
- Proteger la configuración del agente. Alertar sobre cambios inesperados en servidores MCP, URL base de API y proxies, y exigir aprobación para editar la configuración del propio agente.
- Ponderar la confianza por superficie. Cuando su framework lo permita, marcar la procedencia por fuente y limitar las acciones que puede desencadenar el texto de superficies de baja integridad.
- Probar variando la ubicación. Al hacer red teaming de sus agentes, varíe la ubicación y la posición de la inyección, no solo la redacción; una sola ubicación puede subestimar el riesgo.
- Mantener activas las aprobaciones y el sandboxing, y aplicar el mínimo privilegio a herramientas y credenciales.
Status
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Artículo «trust region» | arXiv:2610.38867 | 2026-10-28 | Tres bancos de prueba, modelos de varios proveedores |
| Archivos de instrucciones en Descargas | Forever Security | 2026-10-22 | Codex y Claude Code probados; los autores no reportan declaración de los proveedores |
| Resumen que cita ambos | Adversa AI | 2026-11-02 | Compilación secundaria |
| Estado de parches | n/a | n/a | Hallazgo de comportamiento; sin parche único |