ShareLock: el envenenamiento por umbral dispersa un payload MCP entre varias herramientas

¿Qué es esto?

El 25 de junio de 2026, Liwei Liu, Tianzhu Han, Zijian Liu, Zishu Dong y Na Ruan publicaron ShareLock: A Stealthy Multi-Tool Threshold Poisoning Attack Against MCP en arXiv. El trabajo expone un punto ciego en la defensa del ecosistema Model Context Protocol (MCP) frente al tool poisoning: casi todos los escáneres inspeccionan una descripción de herramienta a la vez, y ShareLock muestra cómo colar un payload precisamente bajo esa suposición.

Los ataques de tool poisoning clásicos insertan una instrucción maliciosa en texto plano dentro de la descripción de una sola herramienta, que el agente lee y ejecuta. Es eficaz pero frágil: una cadena maliciosa monolítica es justo lo que la revisión manual y los detectores automáticos están hechos para atrapar. El aporte de ShareLock es eliminar ese punto único de detección. Los autores reportan una tasa de éxito media superior al 90 % en varios LLM de uso general y dos clientes MCP distintos, superando de forma notable al envenenamiento de una sola herramienta frente a la detección basada en descripciones. Es un trabajo académico que describe una clase de ataque y sus defensas; aquí no se reproduce ningún payload operativo.

Cómo funciona

ShareLock toma prestada una idea de la criptografía: el esquema de umbral de secreto compartido de Shamir. Un secreto se divide en n fragmentos de modo que cualquier k de ellos lo reconstruyen, pero cualquier subconjunto menor no revela nada, ni siquiera parcialmente. ShareLock trata la instrucción maliciosa como ese secreto y reparte fragmentos de apariencia inofensiva por varias descripciones de herramientas, en uno o varios servidores MCP.

La consecuencia es lo que lo vuelve sigiloso: por debajo del umbral, los fragmentos ofrecen secreto en sentido informacional. Tomada por separado, cada descripción de herramienta envenenada es realmente inocua: no hay instrucción oculta que encontrar en ella, porque un único fragmento no contiene ninguna matemáticamente. Un escáner por herramienta, un juez LLM que revisa descripciones una a una o un auditor humano que hace muestreos no ven nada accionable.

instrucción maliciosa  ──►  dividida en fragmentos  s1 … sn   (Shamir, umbral k)

   descripción herramienta A  ⊃  s1     ← inocua aislada
   descripción herramienta B  ⊃  s2     ← inocua aislada
   descripción herramienta C  ⊃  s3     ← inocua aislada
        …                                (menos de k fragmentos no revelan nada)

   [disparador de reconstrucción sigiloso plantado en una actualización del servidor]
        ▼
   el agente agrega ≥ k fragmentos  ──►  reconstruye la instrucción oculta  ──►  acción

La reconstrucción es diferida. Los autores describen plantar un disparador de reconstrucción sigiloso durante una actualización rutinaria del servidor: los fragmentos permanecen latentes en las herramientas hasta que el disparador lleva al agente a agregar al menos k de ellos, momento en que la instrucción oculta se reensambla y provoca una brecha de activos del sistema o de datos privados. La evaluación abarca cuatro escenarios multiherramienta y dos clientes MCP, y es la combinación de herramientas, no una sola, lo que resulta peligroso.

Por qué importa

MCP anima a los agentes a cargar muchas herramientas, a menudo desde varios servidores, y la comunidad ha respondido sobre todo con higiene por herramienta: escanear cada descripción, filtrar cada servidor, juzgar cada herramienta. ShareLock muestra que una estrategia de detección limitada a las herramientas individuales puede ser impecable en cada una y aun así estar ciega al conjunto. La superficie de ataque es el conjunto de herramientas instaladas y cómo el agente las compone, una propiedad que ningún control por herramienta puede observar.

La tolerancia a fallos es lo más incómodo. Como la reconstrucción solo necesita k fragmentos de n, un auditor que retire o corrija una herramienta envenenada no ha neutralizado necesariamente el ataque mientras el umbral siga siendo alcanzable. Esto acerca la defensa de MCP al mismo terreno que los servidores MCP maliciosos más allá del tool poisoning y los rug pulls de descripción de herramienta: la amenaza vive en las relaciones y el cambio a lo largo del tiempo, no en una cadena estática.

Defensas

Para los equipos que operan clientes MCP o curan registros de herramientas, la lección es ampliar la unidad de análisis.

Analizar las herramientas en conjunto, no solo una a una. Una detección que puntúa cada descripción por separado es justo lo que ShareLock está diseñado para burlar. Evalúe el conjunto conjunto de herramientas instaladas —correlaciones entre herramientas, tokens inusuales compartidos, descripciones que solo tienen sentido agregadas— en lugar de suponer que la limpieza por herramienta se compone en seguridad global.

Tratar las actualizaciones del servidor como un evento de seguridad. El disparador de reconstrucción se planta en una actualización: fije las descripciones de herramientas a un hash revisado, haga diff de cada cambio y reaudite el conjunto completo de herramientas —no solo la que cambió— antes de confiar.

Restringir y observar en la capa de acción. Como el payload solo importa cuando se convierte en acción, mantenga las defensas clásicas del flujo de control: permisos de herramienta de mínimo privilegio, confirmación humana para operaciones sensibles y supervisión en ejecución que señale a un agente haciendo algo que ningún propósito declarado de herramienta justifica.

Minimizar y verificar la procedencia de la superficie de herramientas. Menos herramientas de menos editores de confianza reduce las probabilidades de alcanzar un umbral de reconstrucción; exija descripciones de herramientas firmadas y con procedencia rastreada para que no puedan dispersarse fragmentos de forma discreta por un marketplace.

Estado

Elemento	Detalle
Divulgación	Preprint arXiv 2606.27027 v1, enviado el 25 de junio de 2026 (CC BY-NC-SA 4.0), 16 páginas
Clase	Técnica de ataque — envenenamiento por umbral multiherramienta de descripciones de herramientas MCP mediante el secreto compartido de Shamir
Mecanismo	Instrucción maliciosa dividida en fragmentos inocuos; disparador de reconstrucción plantado en una actualización del servidor
Evaluación	Cuatro escenarios multiherramienta · dos clientes MCP · LLM de uso general
Resultado reportado	Tasa de éxito media > 90 %; supera al envenenamiento de una sola herramienta frente a la detección basada en descripciones
Fallo defensivo central	Los escáneres por herramienta no pueden ver un payload que solo existe en el agregado de al menos k herramientas