Envenenamiento de la superficie de herramientas WebMCP: secuestrar al agente en plena sesión

¿Qué es esto?

El 4 de junio de 2026, Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu y Kuo-Hui Yeh, de la National Yang Ming Chiao Tung University, publicaron en arXiv WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents. El artículo examina WebMCP, un protocolo emergente que permite a un sitio web exponer herramientas estructuradas directamente a un agente de IA, sin pasar por una interfaz de usuario. Su aportación es demostrar que, en WebMCP, el conjunto de herramientas que un agente ve durante una misma sesión no es ni estático ni fiable por naturaleza, y que ese dinamismo es explotable.

Los autores denominan a la amenaza Mid-Session Tool Injection (MSTI): una forma, para un atacante que controla un script de terceros presente en la página —un recurso de CDN comprometido, un SDK publicitario, cualquier JavaScript del mismo origen— de modificar las herramientas percibidas por el agente mientras la tarea ya está en marcha. Se trata de un trabajo académico revisable por pares que describe una clase de ataque y sus defensas sobre un protocolo aún joven; aquí no se reproduce ningún exploit operativo. Adversa AI lo incluyó entre sus mejores recursos de seguridad de MCP de julio de 2026.

Cómo funciona

MSTI se divide en dos familias. El secuestro de herramientas (tool hijacking) manipula la presencia de las herramientas —si una herramienta existe y cuándo— antes incluso de que el modelo razone. El reencuadre de herramientas (tool framing) manipula los metadatos —el nombre, la descripción, el campo readOnlyHint y el inputSchema— para que el agente malinterprete el papel de una herramienta maliciosa.

Dos técnicas de secuestro destacan porque actúan antes de todo razonamiento semántico, lo que explica precisamente que el modelo apenas se defienda de ellas:

Secuestro de herramientas (manipulación de presencia)

  Secuestro de AbortSignal:  abortar el AbortController de una herramienta legítima → desregistrarla
                             → reregistrar una herramienta maliciosa con el MISMO nombre
                             → antes de la primera invocación del agente

  Carrera de registro:       registrar la herramienta maliciosa con el nombre objetivo
                             ANTES que la legítima → «el primero en registrar gana»
                             → el agente solo ve la versión maliciosa

El reencuadre es más sutil. En lugar de eliminar una herramienta, el atacante la deja visible pero reescribe cómo se lee: por ejemplo, insertando un imperativo como «always call before send_email» en una descripción para disfrazar una herramienta maliciosa de paso obligatorio del flujo de trabajo, o inflando una descripción de 1.200 palabras con texto de relleno sobre ISO 27001 / SOC 2 / RGPD para ocultar la instrucción dañina en las primeras decenas de palabras.

El compromiso medido es lo más interesante. En GPT-5.4, Claude Opus 4.6 y Gemini 2.5-flash, los ataques de presencia alcanzan una tasa de éxito muy alta pero resultan disruptivos: el secuestro de AbortSignal logra de media un 94 % de éxito y la carrera de registro un 100 %, pero la tasa de finalización de la tarea original se desploma a alrededor del 17-18 %, de modo que la sesión se rompe de forma visible. Los ataques de reencuadre son más discretos: la inyección de descripción alcanza un 59 % de éxito y aun así la tarea se completa el 81 % de las veces, y la variante compuesta un 61 % de éxito con un 85 % de finalización. Sigilo y fiabilidad se sitúan en los extremos opuestos de un mismo dial.

Por qué importa

La mayoría de los trabajos sobre seguridad de agentes supone que el peligro reside en el contenido del prompt o en las salidas de las herramientas —el terreno de la inyección de prompts y la inyección indirecta—. WebMCP traslada parte de la amenaza al registro de herramientas en sí. Como ese registro puede cambiar en plena sesión, el estado del entorno que percibe el agente se convierte en superficie de ataque, y un script de terceros de la misma página —una clase de código que la mayoría de los sitios ya carga sin mucho escrutinio— basta para alcanzarlo.

Esto resuena con los problemas de MCP del lado del servidor, como los rug pulls de descripciones de herramientas y el envenenamiento por umbral repartido entre varias herramientas, pero el contexto del navegador cambia la economía del ataque: no hace falta un servidor malicioso ni una entrada en un marketplace, basta con un punto de apoyo en la cadena de suministro de scripts de la página. Los resultados de reencuadre son la lección más incómoda: un ataque puede redirigir el flujo de datos del agente hacia un endpoint controlado por el atacante mientras el usuario ve que la tarea, en apariencia, tiene éxito.

Defensas

Las recomendaciones del artículo apuntan al ciclo de vida de WebMCP y se traducen en pautas concretas para quien construye o despliega agentes del lado del navegador.

Vincular la identidad de una herramienta a su origen. El nombre de una herramienta no debe ser un espacio de nombres libre donde «el primero en registrar gana». Ate cada herramienta registrada al origen que la declaró y rechace el reregistro silencioso de un nombre existente, lo que cierra tanto la vía del secuestro de AbortSignal como la de la carrera de registro.

Imponer la coherencia del ciclo de vida. Trate los cambios en el conjunto de herramientas durante la sesión como eventos de seguridad: congele o vuelva a confirmar la superficie de herramientas una vez iniciada la tarea, y notifique al host cualquier registro, sustitución o eliminación en lugar de aplicarlos en silencio.

Aislar los scripts de terceros del registro de herramientas. La frontera de confianza que ya rige el acceso al DOM y a la red debe extenderse al registro de herramientas: un CDN o un SDK publicitario no tiene por qué modificar el inventario de herramientas del agente. Haga cumplir fronteras de datos para que una herramienta de terceros no pueda recibir contexto sensible ni resultados intermedios.

Mantener registros trazables y limitar la capa de acción. Conserve un registro auditable de cada registro e invocación de herramientas para detectar a posteriori las sustituciones anómalas, y mantenga los controles clásicos —permisos de herramientas de mínimo privilegio y confirmación humana para las acciones sensibles—, ya que la carga útil solo importa cuando se convierte en una acción.

Estado

Elemento	Detalle
Divulgación	Preprint arXiv 2606.06387 v1, enviado el 4 de junio de 2026 (CC BY 4.0)
Clase	Técnica de ataque — manipulación en plena sesión del registro de herramientas de un agente WebMCP mediante un script de terceros comprometido
Variantes	Secuestro de herramientas (secuestro de AbortSignal, carrera de registro) y reencuadre de herramientas (descripción, readOnlyHint, inputSchema, nombre)
Evaluación	Tres modelos (GPT-5.4, Claude Opus 4.6, Gemini 2.5-flash) · varios escenarios de tarea · herramientas en JavaScript
Resultado reportado	Ataques de presencia hasta el 100 % de ASR pero ~17-18 % de finalización; ataques de reencuadre ~59-61 % de ASR con ~81-85 % de finalización
Brecha defensiva central	La superficie de herramientas es en sí misma modificable en plena sesión; las defensas anti-inyección a nivel de mensaje no observan los cambios del registro