Inyección por la vía de error: cuando los mensajes de error de las herramientas tienen autoridad

¿Qué es esto?

En junio de 2026, el artículo VATS: Exploiting Implicit Authority in Error-Path Injection via Systematic Mutation (arXiv:2606.07992) describió un rincón poco examinado de la seguridad de los agentes: el bucle de gestión de errores de los agentes con herramientas. A medida que el Model Context Protocol (MCP) estandariza cómo los agentes autónomos invocan herramientas, también estandariza cómo esas herramientas informan de los fallos — y una llamada de herramienta fallida devuelve un mensaje de error que regresa directamente al contexto del modelo.

La hipótesis del artículo es sencilla e incómoda: un mensaje de error de herramienta porta una autoridad implícita. Cuando un modelo ve Error: ..., conmuta a un modo de razonamiento correctivo («hay que arreglarlo»), y ese modo es más complaciente que su postura normal. Un atacante que controle el contenido de una cadena de error puede aprovechar esa complacencia. Es una variante de la inyección de prompt indirecta: la instrucción maliciosa nunca proviene del usuario, llega disfrazada de retroalimentación del sistema.

Cómo funciona

VATS — Vulnerability Analysis of Tool Streams — es un marco de pruebas guiado por mutación. En lugar de elaborar una sola carga a mano, hace evolucionar sistemáticamente cadenas adversarias a lo largo de siete dimensiones estructurales y lingüísticas, buscando la formulación y la ubicación que maximizan el cumplimiento. El vector más eficaz identificado es el posicionamiento estructural: intercalar la instrucción inyectada dentro del contexto de error circundante, de modo que se lea como parte del diagnóstico que el modelo intenta atender.

La razón por la que esto supera a la inyección ordinaria reside en el propio razonamiento del agente. El texto de un documento no confiable compite con la tarea del usuario por la atención; un mensaje de error, en cambio, es la tarea en ese instante — el agente ha sido entrenado e instruido para recuperarse de fallos, por lo que trata el canal de error como entrada procedimental confiable en vez de como un dato del que desconfiar. La distinción importa: la misma frase es más peligrosa etiquetada como error que enterrada en una página web recuperada. Una dinámica afín se documentó en Causality Laundering: Denial-Feedback Leakage in Tool-Calling LLM Agents (arXiv:2604.04035), donde las rutas de denegación y retroalimentación filtran una influencia que el diseñador nunca previó.

Aquí no se reproduce ninguna carga útil. El mecanismo — un texto de error controlado por el atacante se lee como una instrucción autoritativa — es toda la lección, y la forma estructural (colocar la instrucción donde el modelo espera una corrección) basta para comprender el riesgo sin un exploit funcional.

Por qué importa

La cifra clave es la brecha, no el valor absoluto. En cuatro modelos de vanguardia — Gemini 3.1 Pro, GPT-5.5, GLM-5.1 y Qwen3-Coder — la inyección por la vía de error triplicó aproximadamente la tasa de éxito de la inyección de prompt indirecta estándar, alcanzando hasta el 100 % de cumplimiento en evaluación controlada. Todos los modelos probados eran susceptibles, lo que apunta a una debilidad de clase en la gestión de fallos más que a una peculiaridad de un proveedor.

Dos consecuencias para quien opere agentes con herramientas. Primero, su frontera de saneamiento de entradas probablemente esté incompleta. Los equipos que filtran los documentos recuperados y la entrada del usuario suelen dejar pasar la salida de las herramientas — sobre todo la salida de error — suponiendo que la escribió el runtime y no un atacante. Cualquier herramienta que refleje contenido controlable por el atacante en una cadena de error (una consulta de búsqueda reflejada, un nombre de archivo, un cuerpo HTTP, un mensaje de un parser) se convierte en un canal de inyección. Segundo, esto se suma a la trifecta letal: un agente con acceso a datos privados, exposición a contenido no confiable y una vía de exfiltración gana una manera más, muy eficaz, de ser manipulado.

Defensas

La vía de error debe tratarse como dato no confiable, no como instrucción privilegiada.

• Etiquete la procedencia y consérvela. Marque la salida de las herramientas — errores incluidos — como un canal distinto y de menor confianza, y preserve esa etiqueta a lo largo del contexto, conforme a una jerarquía de instrucciones en la que la intención del desarrollador y del usuario prevalezca sobre cualquier retorno de herramienta.
• Sanee y plantille las cadenas de error. Haga que el runtime sustituya el texto bruto de herramienta/excepción por un objeto de error fijo y estructurado (código + mensaje seguro). No inserte verbatim, en el error visible para el modelo, subcadenas accesibles al atacante (consultas, nombres de archivo, cuerpos de respuesta).
• Elimine los imperativos del canal de error. Un error debe describir un estado, nunca solicitar una acción. Detecte y neutralice el contenido con forma de instrucción que llegue por la salida de herramienta antes de que reingrese al contexto.
• No permita que un error escale privilegios de forma automática. Un fallo debe disparar reintento / aborto / consulta a un humano, no una nueva llamada de herramienta más amplia. Mantenga la verificación antes de confirmar en la ruta de recuperación de errores, no solo en la de éxito.
• Pruebe los modos de fallo. Haga red team deliberado sobre el bucle de error — la mayoría de las evaluaciones de agentes solo inyectan vía documentos y turnos de usuario, dejando sin probar el canal de error, donde VATS halló un 100 % de cumplimiento.

Estado

Elemento	Detalle
Divulgación	arXiv:2606.07992, junio de 2026
Vector	Inyección indirecta vía mensajes de error de herramientas (bucle de error MCP)
Modelos evaluados	Gemini 3.1 Pro, GPT-5.5, GLM-5.1, Qwen3-Coder
Efecto	~3× el éxito de la IPI estándar; hasta 100 % de cumplimiento en pruebas controladas
Técnica más eficaz	Posicionamiento estructural (instrucción intercalada en el contexto de error)
Requisito previo	Influencia del atacante sobre la salida de error de la herramienta