Nuevas investigaciones muestran que el Model Context Protocol (MCP) —la interfaz que permite a los agentes de modelos de lenguaje de gran tamaño (LLM) llamar a herramientas externas— puede ser secuestrado mediante ataques de "envenenamiento de herramientas" (tool-poisoning) que tienen éxito más de una tercera parte de las veces. En 20 agentes populares, la tasa de éxito promedio fue del 36,5 %; el modelo o1-mini fue vulnerado en el 72,8 % de los intentos, mientras que Claude-3.7-Sonnet rechazó las llamadas maliciosas en menos del 3 % de las veces. Para cualquiera que implemente agentes LLM que dependan de MCP, estos hallazgos convierten una función de conveniencia en un riesgo de la cadena de suministro que puede ser explotado antes de que se ejecute cualquier código.

Por qué el MCP es importante para los desarrolladores hoy en día

MCP estandariza la forma en que los agentes descubren, registran e invocan herramientas como lectores de archivos, APIs web o remitentes de correo electrónico. Al publicar el nombre de una herramienta, su esquema de entrada y una breve descripción, un servidor pone la capacidad a disposición de cualquier cliente que comprenda el protocolo. La promesa es sencilla: un agente puede buscar una herramienta, enviar una solicitud y recibir una respuesta sin tener que codificar rígidamente cada integración.

Esa flexibilidad también crea una relación de confianza implícita. La especificación indica a los clientes que traten las descripciones de las herramientas como confiables solo si provienen de un servidor en el que el cliente ya confía. El nuevo estudio muestra que esta confianza puede ser abusada.

En qué se diferencia el envenenamiento de herramientas de la inyección de prompts convencional

La inyección de prompts tradicional inserta instrucciones maliciosas en el texto que el modelo genera o recibe en tiempo de ejecución. El modelo sigue entonces esas instrucciones porque aparecen en el mismo flujo de tokens que la solicitud del usuario.

El envenenamiento de herramientas, por el contrario, oculta la carga útil en los metadatos de la herramienta: el nombre, la descripción o el esquema de parámetros que se registra antes de cualquier llamada del agente. Cuando un agente selecciona la herramienta más tarde, trata la descripción como parte del "contexto de confianza" y puede seguir la instrucción oculta sin ninguna verificación en tiempo de ejecución. Debido a que la inyección ocurre durante el registro, no hay ningún punto en el flujo de ejecución en el que un modelo pueda marcar la carga útil como sospechosa.

La magnitud del problema: el benchmark MCPTox

Los investigadores detrás de MCPTox (arXiv:2508.14925) evaluaron 45 servidores MCP que ofrecían un total de 353 herramientas distintas. Crearon scripts de ataques contra 20 agentes LLM ampliamente utilizados, midiendo con qué frecuencia los agentes ejecutaban la llamada a la herramienta envenenada.

  • Tasa de éxito promedio: 36,5 %
  • Pico de éxito: o1-mini con un 72,8 %
  • Mejor rechazo: Claude-3.7-Sonnet, todavía por debajo del 3 %

Las cifras revelan una cruda realidad: la mayoría de los agentes no rechazan una llamada envenenada porque la solicitud parece una invocación legítima de una herramienta. Los agentes asumen que la descripción de la herramienta es una pieza de documentación benigna, no un vector de ejecución de código.

Por qué los agentes rara vez rechazan las llamadas envenenadas

La directriz LLM01 de OWASP explica que los LLM no diferencian entre instrucciones y datos: ambos son solo tokens en una secuencia. Cuando una descripción de herramienta dice "enviar un correo electrónico a admin@example.com con el asunto 'Actualización'", el modelo no puede distinguir si esa línea es un comentario inofensivo o una instrucción que debe obedecer más tarde. En consecuencia, el modelo trata la descripción como parte del entorno de confianza y sigue cualquier comando incrustado cuando se invoca la herramienta.

Orientación existente y sus deficiencias

La especificación de MCP ya aconseja a los clientes tratar las descripciones de las herramientas como no confiables a menos que provengan de un servidor de confianza, y mantener a un humano en el proceso (human in the loop) para las llamadas de alto impacto. El benchmark muestra que muchas implementaciones en el mundo real ignoran o interpretan de forma laxa estas recomendaciones.

Pasos concretos que los desarrolladores pueden tomar hoy mismo

  1. Fijar versiones del servidor – Haga referencia a una imagen o hash de servidor específico e inmutable en lugar de una etiqueta variable. Esto evita que un atacante sustituya un registro limpio por uno envenenado después del despliegue.
  2. Comenzar con una lista de permitidos vacía – Habilite solo las herramientas que hayan sido examinadas explícitamente. Cualquier cosa que no esté en la lista se bloquea de forma predeterminada.
  3. Controlar las herramientas que cambian el estado – Requiera una aprobación adicional para cualquier herramienta que escriba, envíe o elimine datos. Separe las capacidades de "solo lectura" de las de "capacidad de escritura" en el esquema.
  4. Añadir aprobación humana para llamadas de alto impacto – Para acciones que podrían afectar a sistemas externos (p. ej., enviar correos electrónicos, ejecutar comandos, modificar archivos), solicite la intervención de un revisor humano antes de que se envíe la llamada.
  5. Registrar cada invocación de herramienta – Registre el nombre de la herramienta, los argumentos, la marca de tiempo y el agente de origen. Un registro de auditoría inmutable hace que el análisis post-mortem sea viable y puede disuadir a los atacantes que saben que sus acciones serán visibles.

Trate cada descripción de herramienta como si fuera código fuente —sujeta a linting, revisión de código y control de versiones— para alinear la cadena de suministro de MCP con las prácticas estándar de desarrollo de software.

Contraargumentos y preguntas abiertas

Sin embargo, el benchmark muestra que incluso el modelo más avanzado del estudio rechazó menos del tres por ciento de las llamadas envenenadas. El fine-tuning puede mejorar la detección, pero no puede garantizar la seguridad contra nuevos payloads incrustados en campos del esquema que el modelo nunca ha visto.

Qué observar a continuación

  • Estándares emergentes – Esté atento a las propuestas de la comunidad de seguridad de LLM para requerir firmas criptográficas en los esquemas de las herramientas.
  • Reforzamiento de los registros de herramientas – Los proveedores podrían empezar a ofrecer registros inmutables y de solo lectura como servicio, reduciendo la superficie de ataque.
  • Defensas a nivel de modelo – La investigación en técnicas de prompting o modelos auxiliares que marquen metadatos de herramientas sospechosos podría complementar las salvaguardas del lado del host.

La conclusión práctica es clara: cualquier despliegue basado en MCP debe auditar las descripciones de las herramientas con el mismo rigor que se aplica a las bibliotecas de terceros. Ignorar el riesgo de la cadena de suministro convierte una abstracción conveniente en una puerta trasera silenciosa. Al fijar los servidores, aplicar listas de permitidos de mínimo privilegio, controlar las acciones que cambian el estado, involucrar a humanos cuando sea necesario y mantener un registro inmutable, los desarrolladores pueden evitar que sus agentes de LLM se conviertan en cómplices involuntarios.