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

¿Qué es esto?

WebMCP es una capacidad web emergente que permite a un sitio exponer herramientas estructuradas directamente a un agente de IA que controla el navegador — incluidos los agentes que se ejecutan dentro de una extensión. En lugar de adivinar cómo hacer clic en una página, al agente se le declaran herramientas invocables (con nombres, parámetros y descripciones) que puede llamar. Esa comodidad crea una nueva superficie de ataque dinámica: el conjunto de herramientas disponibles para un agente, y los metadatos que las describen, los proporciona la propia página que el agente está leyendo, y pueden cambiar en tiempo de ejecución.

Un artículo de arXiv de junio de 2026, WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents (2606.06387), formaliza este problema como Mid-Session Tool Injection (MSTI) — la manipulación de la superficie de herramientas de un agente durante una sesión activa, en lugar de a través de un manifiesto estático registrado de antemano. Ese mismo mes, Chrome publicó una guía de seguridad oficial para agentes que usan WebMCP (9 de junio de 2026), y el resumen de MCP de julio de 2026 de Adversa AI incluyó la técnica entre las amenazas de agentes destacadas del mes. Dado que se trata de una debilidad de diseño en la forma en que los agentes consumen las definiciones de herramientas, conviene entenderla antes de que la adopción de WebMCP se amplíe.

Cómo funciona

La MSTI funciona porque un LLM trata los metadatos de las herramientas y la salida de las herramientas como parte del mismo flujo de tokens del que lee sus instrucciones — el clásico problema de la inyección indirecta de prompts, aplicado a un registro de herramientas vivo. La investigación agrupa los ataques en dos familias.

El secuestro de herramientas (tool hijacking) cambia qué herramientas ve el agente. Un script de terceros presente en la página puede registrar o cancelar el registro de herramientas después de que el agente ya haya iniciado una tarea, aprovechando ventanas temporales — por ejemplo una carrera de registro (registration race), o la cancelación de un registro en curso mediante la API AbortSignal del navegador — de modo que el agente termina con un conjunto de herramientas que el autor del sitio nunca previó. El encuadre de herramientas (tool framing) deja intacto el conjunto de herramientas pero manipula la percepción que tiene el agente de cada herramienta, colocando contenido engañoso en campos de metadatos como el nombre, la descripción, readOnlyHint o inputSchema. Una herramienta anotada como «solo lectura», o descrita como inofensiva, puede así dirigirse hacia una acción que el usuario nunca autorizó.

La guía de Chrome describe la misma superficie en dos vectores: los manifiestos maliciosos (instrucciones ocultas en los nombres, parámetros o descripciones de las herramientas) y las salidas contaminadas (un sitio de confianza que devuelve datos de terceros — un comentario de usuario, por ejemplo — que llevan instrucciones inyectadas). El flujo conceptual, sin reproducir ninguna carga funcional:

[ web page ] -- declares/mutates --> [ WebMCP tool surface ]
      │                                        │
      │ third-party script                     │ metadata: name, description,
      │ (registration race / AbortSignal)      │ readOnlyHint, inputSchema
      ▼                                        ▼
[ tool set the agent sees ]  ◄── poisoned ──  [ attacker-influenced framing ]
      │
      ▼
[ agent plans + calls tools in the user's authenticated session ]

El artículo informa de altas tasas de éxito para estas manipulaciones en tiempo de ejecución. Como el control inyectado reside en la capa de herramientas y no en el texto visible de la página, puede eludir las defensas que solo inspeccionan el contenido de la página.

Por qué importa

La gravedad proviene de dónde se ejecutan los agentes de navegador: dentro de la sesión autenticada del usuario. Un agente conectado al correo, a un CRM, a un alojamiento de código o a una aplicación de contabilidad hereda todos los permisos que esa sesión ya posee. Una llamada de herramienta secuestrada o mal encuadrada puede entonces leer, enviar, modificar o eliminar datos sin una nueva solicitud de autenticación. La MSTI eleva el riesgo respecto al envenenamiento de herramientas estático, porque el manifiesto que un agente validó al comienzo de una tarea no está garantizado que sea aquel sobre el que actúa momentos después — la confianza establecida una vez no se mantiene durante toda la sesión.

Defensas

La guía de Chrome de junio de 2026 recomienda una defensa en profundidad repartida entre barreras deterministas y probabilísticas, y encaja directamente con la MSTI.

Establezca barreras deterministas: limite los tokens de las respuestas de herramientas entrantes y rechace las cargas que superen el límite; restrinja el conjunto de orígenes web con los que un agente puede interactuar a aquellos relevantes para la tarea actual, reduciendo la superficie de exfiltración; y mantenga al humano en el bucle exigiendo confirmación para las acciones que modifican un estado — asuma que una herramienta modifica el estado salvo que sus anotaciones lo desmientan claramente, y nunca considere readOnlyHint como un control de seguridad.

Añada barreras probabilísticas: aplique spotlighting para que el modelo trate la salida y los metadatos de las herramientas como datos no confiables, no como instrucciones. Chrome describe dos métodos — una delimitación ligera para contenido de bajo riesgo, y la codificación en base64 del contenido no confiable para los casos de alto riesgo (robusta frente a la evasión por inyección de delimitadores, a costa de aproximadamente un tercio más de tokens) — anclados por una instrucción de sistema que indica al modelo decodificar solo para su análisis y nunca ejecutar lo que encuentre.

Superponga clasificadores y críticos: analice las descripciones de las herramientas y la salida de las herramientas en busca de instrucciones inyectadas antes de cualquier llamada, y use un modelo «crítico» aparte — no expuesto al contenido no confiable — para verificar que cada llamada de herramienta planificada se corresponde con el objetivo real del usuario y lleva solo el mínimo de datos necesario. Por último, revalide la superficie de herramientas de forma continua en lugar de una sola vez al inicio de la tarea, trate el registro y la cancelación de registro de herramientas en mitad de sesión como eventos de seguridad, y vigile la producción para detectar anomalías como picos de agotamiento de tokens. Las suites de red teaming de código abierto (por ejemplo Promptfoo) y las herramientas de auditoría de agentes permiten medir si estas mitigaciones se sostienen realmente antes de pasar a producción.

Estado

Elemento	Referencia	Fecha	Notas
Artículo de investigación	WebMCP Tool Surface Poisoning, arXiv 2606.06387	junio de 2026	Formaliza la inyección de herramientas en mitad de sesión (MSTI)
Familias de ataque	Secuestro de herramientas; encuadre de herramientas	junio de 2026	Registration race / AbortSignal; manipulación de metadatos
Guía del proveedor	Chrome — Consideraciones de seguridad para agentes WebMCP	2026-06-09	Barreras deterministas + probabilísticas
Seguimiento del sector	Adversa AI — resumen de seguridad de MCP	2026-07-06	Citada como amenaza de agentes de julio de 2026
Superficie afectada	Agentes de navegador WebMCP, incluidas extensiones	—	Se ejecuta en la sesión autenticada del usuario