)
Última actualización: 4 de noviembre, 2026
¿Qué es el tool poisoning en MCP? El tool poisoning en MCP (MCP tool poisoning) es un ataque en el que un servidor del Model Context Protocol esconde instrucciones maliciosas en la descripción, el esquema o la respuesta de una herramienta. El modelo lee esos metadatos como contexto fiable y los obedece. Los rug pulls y el tool shadowing son variantes: uno cambia la herramienta tras aprobarla y el otro usa un servidor para secuestrar las herramientas de otro.
TL;DR: puntos clave
- En MCPTox, construido sobre 45 servidores MCP reales y 1.348 casos maliciosos, o1-mini alcanzó una tasa de éxito del ataque del 72,8 % (MCPTox, 2025).
- El modelo que más se negó, Claude-3.7-Sonnet, rechazó menos del 3 % de las instrucciones envenenadas, así que el alineamiento del modelo no basta como control (MCPTox, 2025).
- Una descripción envenenada actúa antes de llamar a ninguna herramienta, porque el cliente la mete en el contexto del modelo al cargar la lista (Trail of Bits, 2025).
- La cheat sheet MCP de OWASP tiene 12 áreas de buenas prácticas y pide calcular el hash de la definición completa, con esquemas y anotaciones, y revisar cada cambio (OWASP).
- Cursor hasta la 1.2.4 permitía cambiar una configuración MCP aprobada sin nuevo aviso (CVE-2025-54136, NVD), y postmark-mcp 1.0.16 añadió una copia oculta (BCC) (Qualys, 2025).
- El 55 % de 100 CISO encuestados ya tiene servidores MCP u otras integraciones de agentes con aplicaciones en producción (Andreessen Horowitz, 2026).
De un vistazo: cuatro ataques a herramientas MCP
Respuesta rápida
¿Cómo se frenan el tool poisoning y los rug pulls en MCP?
Trata cada definición de herramienta como una entrada no fiable. Revisa la definición completa antes de aprobarla, calcula su hash, fíjala y bloquea o vuelve a aprobar la herramienta cuando el hash cambie. Impide que las descripciones de un servidor mencionen herramientas de otro. Después inspecciona las salidas en tiempo de ejecución, porque la fijación no ve los cambios en el código del servidor.
| Ataque | Qué cambia el atacante | Cuándo se activa | Defensa principal |
|---|---|---|---|
| Inyección en la descripción | Descripción, nombres de parámetros o texto del esquema | En cuanto el cliente carga la lista de herramientas | Revisión completa, alertas por patrones de instrucción, registro verificado |
| Rug pull | Una definición o un servidor que ya estaba aprobado | Tras la aprobación, en una actualización de la lista o una versión nueva del paquete | Hash y fijación de la definición completa, nuevo consentimiento ante cualquier cambio |
| Tool shadowing | La descripción de un servidor malicioso que apunta a herramientas de otro | Cuando el modelo usa la herramienta de confianza | Aislamiento por servidor, bloqueo de referencias cruzadas, vigilancia de flujos entre servidores |
| Salida envenenada | Los datos que devuelve la herramienta | Tras la llamada, cuando el modelo lee el resultado | Tratar las salidas como no fiables, inspección en ejecución, autorización en código |
Cómo lo investigamos
El 4 de noviembre de 2026 revisamos la cheat sheet y el Top 10 MCP de OWASP, la especificación de herramientas de MCP (2026-07-28), Trail of Bits, MCPTox, el registro NVD del CVE-2025-54136 y el informe de Qualys sobre postmark-mcp. Las tablas y el plan son nuestra síntesis. No hicimos pruebas nuevas.
Qué es el tool poisoning en MCP
El tool poisoning en MCP es una prompt injection indirecta que vive en los metadatos de la herramienta, no en lo que escribe el usuario. OWASP lo define como instrucciones maliciosas ocultas en descripciones, esquemas o valores de retorno que manipulan al modelo. Funciona porque el modelo no distingue la documentación de una herramienta de una orden.
La causa está en cómo MCP comparte herramientas. El cliente pide a cada servidor su lista de herramientas y añade los nombres, descripciones y esquemas al contexto del modelo. Según Trail of Bits (2025), esto permite que un servidor malicioso ataque antes de que se invoque ninguna herramienta. Lo llama "line jumping". El Top 10 MCP de OWASP, aún en beta, recoge el riesgo como MCP03:2025 Tool Poisoning.
OWASP añade un detalle que muchos equipos pasan por alto: el modelo ve a la vez las descripciones de todos los servidores conectados. Un solo servidor envenenado puede influir en cómo el agente usa todas las demás herramientas de la sesión.
Si el protocolo es nuevo para ti, empieza por nuestra guía de seguridad MCP. Para la lista completa de riesgos, consulta nuestra explicación del OWASP MCP Top 10. Para los ataques que llegan por la salida de las herramientas, lee nuestra guía sobre prompt injection en MCP.
Cómo funciona la inyección en la descripción de herramientas
La inyección en la descripción esconde instrucciones en un texto que el usuario casi nunca lee y que el modelo siempre lee. El campo envenenado puede ser la descripción, el nombre de un parámetro o un esquema anidado. Un payload típico pide al modelo leer un fichero sensible, añadir datos a una llamada u ocultar la acción al usuario.
Este es un ejemplo simplificado e ilustrativo de una definición envenenada. El propósito visible es inofensivo y la instrucción oculta es el ataque.
Tres factores lo hacen difícil de detectar:
- Las interfaces suelen resumir. OWASP pide que los clientes muestren los parámetros completos y el comando exacto sin recortes, porque un resumen corto puede esconder un bloque largo de instrucciones.
- El esquema también es superficie de ataque. OWASP pide tratar todo el esquema como posible superficie de inyección, no solo la descripción. Un parámetro opcional extra como
notesda al modelo un sitio discreto por donde filtrar datos. - Los modelos capaces obedecen. Según MCPTox (2025), los modelos más capaces suelen ser más vulnerables, porque el ataque aprovecha que siguen mejor las instrucciones.
La defensa empieza antes de aprobar. Rechaza esquemas que acepten campos no declarados y alerta ante textos como "ignora", "no se lo digas al usuario" o rutas de credenciales. OWASP deja claro, en su guía sobre valores de retorno, que eliminar etiquetas y detectar patrones solo son medidas de alerta adicionales. No demuestran que el texto restante sea seguro.
)
Rug pulls: cuando una herramienta aprobada cambia
Un rug pull ocurre cuando un servidor cambia sus definiciones tras la aprobación inicial y convierte una herramienta de confianza en maliciosa. El servidor se porta bien durante la revisión, entra en la lista de permitidos y después cambia la descripción, añade un parámetro o modifica una anotación. Aprobaste una herramienta que ya no existe.
El protocolo hace que el cambio sea normal, y por eso hay que controlarlo. Según la especificación de herramientas de MCP (2026-07-28), un servidor que declara listChanged debería avisar a los clientes suscritos cuando cambie su lista. La lista también puede variar según la autorización presentada. Un cliente que acepta la lista nueva sin más no tiene ninguna frontera de aprobación.
Dos detalles agravan los rug pulls:
- Las anotaciones cambian el comportamiento sin cambiar el texto. OWASP advierte de que cambiar
readOnlyHintodestructiveHintpuede alterar la aprobación del cliente sin ningún cambio visible en la descripción. Los clientes deben tratar las anotaciones como no fiables salvo que procedan de servidores de confianza. - El código puede cambiar tras una definición estable. OWASP subraya que el hash detecta cambios en los metadatos, no en el código del servidor. Un servidor puede mantener la misma descripción y empezar a devolver salidas envenenadas.
Ambos patrones ya han ocurrido fuera del laboratorio:
| Caso | Qué cambió tras la aprobación | Lección |
|---|---|---|
| Cursor, CVE-2025-54136 (hasta la versión 1.2.4, corregido en la 1.3) | Una configuración MCP ya de confianza podía cambiarse por un comando malicioso sin nuevo aviso | Vincula la aprobación a la configuración exacta y vuelve a pedirla ante cualquier cambio |
| postmark-mcp 1.0.16 (17 de septiembre de 2025) | Un cambio de una línea de código añadió un BCC oculto a cada correo que enviaba el servidor | Los hashes de definición no ven cambios de código, así que verifica también las versiones de los paquetes |
Según la National Vulnerability Database (2025), el fallo de Cursor puntúa 8,8 (alto) en CVSS 3.1. GitHub, como CNA, lo puntúa con 7,2. Según Qualys (2025), postmark-mcp rondaba las 1.500 descargas semanales antes de que su responsable lo retirase.
La regla de OWASP es directa: no des por hecho que la herramienta que aprobaste ayer es la misma hoy. Vuelve a pedir consentimiento cuando cambien las definiciones y verifica la integridad de los paquetes con checksums o firma de código. Nuestra guía sobre registros y listas de permitidos MCP explica cómo montar ese flujo de aprobación.
Tool shadowing: cuando un servidor MCP secuestra las herramientas de otro
El tool shadowing, o escalada entre orígenes, se produce cuando la descripción de un servidor malicioso manipula cómo el agente usa las herramientas de otros servidores de confianza. El atacante no necesita que nadie llame a su herramienta. Le basta con compartir ventana de contexto con tus herramientas de correo, pagos o código.
Una descripción de shadowing puede decir que cada vez que el agente envíe un correo debe copiar a una dirección externa. La herramienta de confianza causa el daño, y sus logs parecen normales porque el servidor hizo lo que se le pidió.
Los controles de OWASP para entornos con varios servidores apuntan a este problema:
- Tratar cada servidor MCP como un dominio de seguridad independiente y no fiable.
- Impedir que las descripciones de un servidor mencionen o modifiquen el comportamiento de herramientas de otro.
- Vigilar los flujos de datos entre servidores, por ejemplo credenciales del servidor A que aparecen en llamadas al servidor B.
- Usar un proxy o gateway MCP para aplicar políticas de aislamiento entre servidores.
Los nombres también importan. Solo son únicos dentro de un servidor, así que la especificación indica que los clientes que agregan servidores deberían desambiguarlos, por ejemplo con un prefijo. OWASP aconseja además mantener los servidores de pagos, autenticación y datos personales apartados de los de uso general.
Cómo detectar el tool poisoning y los rug pulls en MCP
La detección funciona por capas: inspeccionar las definiciones antes de aprobarlas, verificarlas en cada actualización y vigilar el comportamiento en ejecución. Ninguna capa basta sola. La revisión previa no ve los rug pulls, la fijación no ve los cambios de código y la monitorización sola no ve cambios silenciosos de metadatos.
| Capa | Qué revisar | Señal que debe bloquear o alertar |
|---|---|---|
| Antes de aprobar | Descripción completa, nombres de parámetros, cada campo del esquema, anotaciones, editor y nombre del paquete | Texto con forma de instrucción, etiquetas ocultas, rutas de credenciales, campos no declarados, typosquatting |
| En cada conexión | Hash de la definición completa frente al valor fijado | Cualquier diferencia de hash, herramientas nuevas o eliminadas, anotaciones cambiadas |
| Entre servidores | Menciones en un servidor a herramientas de otro | Referencias cruzadas, nombres de herramientas duplicados o casi iguales |
| En ejecución | Argumentos y salidas de las herramientas | Secretos o datos personales en argumentos, instrucciones inyectadas en salidas, datos que pasan de un servidor a otro |
La especificación pide a los clientes mostrar las entradas antes de llamar al servidor, validar los resultados antes de pasarlos al modelo y registrar el uso para auditoría. OWASP añade alertas ante herramientas nuevas, consultas de administrador y frecuencias anómalas, respaldadas por logs centrales.
La validación va en el código, no en el prompt. OWASP aconseja JSON Schema estricto, con additionalProperties: false y patrones en los campos de texto, para aceptar solo parámetros declarados y formatos válidos. Así se cierra el truco del campo extra del ejemplo anterior.
Fijar definiciones de herramientas: qué detecta y qué no
Fijar (pinning) consiste en guardar un hash criptográfico de cada definición revisada y negarse a usar la herramienta si la definición en vivo ya no coincide. Es la defensa central contra los rug pulls, y OWASP recomienda verificar el valor fijado antes de cada ejecución. Convierte un cambio silencioso en una petición de aprobación visible.
Para que funcione en la práctica:
- Calcula el hash de la definición completa. Incluye nombre, título, descripción,
inputSchema,outputSchemay anotaciones. Si solo usas la descripción, no verás cambios en el esquema ni en las anotaciones. - Normaliza antes del hash. Una forma canónica de JSON evita que reordenar claves genere falsas alertas.
- Guarda el valor con contexto. Anota servidor, versión, alcance de las credenciales, revisor y fecha junto al hash. Un servidor puede devolver herramientas distintas según la autorización, así que puede tener legítimamente más de un valor fijado.
- Vuelve a comprobar en cada actualización y falla en cerrado. Las listas pueden estar en caché, así que verifica el hash cada vez que se recargue la lista. Ante una diferencia, bloquea la herramienta y pide nueva aprobación.
- Fija también el código. Verifica las versiones de los paquetes con checksums o firmas, como aconseja OWASP.
| La fijación detecta | La fijación no detecta |
|---|---|
| Descripciones editadas e instrucciones ocultas añadidas después | Lógica maliciosa en el código tras una definición sin cambios, como en postmark-mcp |
| Parámetros nuevos, eliminados o renombrados | Datos envenenados en las salidas |
Cambios en readOnlyHint o destructiveHint | Ataques presentes antes de la primera revisión |
| Herramientas nuevas en un servidor aprobado | Texto de shadowing aprobado por error |
Esa columna derecha explica por qué la fijación necesita inspección en ejecución. Nuestra checklist de buenas prácticas de seguridad en MCP sitúa la fijación junto al sandboxing, el mínimo privilegio y el registro.
Seguridad y gobernanza: frenar el tool poisoning en tiempo de ejecución
El tool poisoning es un problema de ejecución. El texto envenenado llega al cargar la lista de herramientas, el rug pull aparece en una actualización posterior y el shadowing se activa cuando corre una herramienta de confianza. Una política escrita en una wiki no ve esos momentos. Un punto de control en el camino de cada conexión MCP, sí.
Andreessen Horowitz encuestó a 100 CISO de empresas con más de 1.000 empleados. Según Andreessen Horowitz (2026), el 46 % cita entre sus mayores preocupaciones que los agentes excedan sus permisos o queden comprometidos. MCPTox (2025) muestra por qué. Sus resultados principales nombran o1-mini y Claude-3.7-Sonnet, así que tómalos como referencia y repite la prueba con el modelo que uses.
| Defensa | Dónde se aplica |
|---|---|
| Solo servidores y versiones aprobados | Gateway delante de cada servidor MCP |
| Definiciones fijadas y bloqueo de cambios | Gateway o cliente, en cada conexión y actualización |
| Aislamiento entre servidores | Política del gateway entre servidores |
| Detección de inyecciones en salidas | Inspección en ejecución antes de que el modelo vea el resultado |
| Secretos y datos personales en argumentos | Inspección en ejecución y enmascaramiento de datos |
| Auditoría de cada llamada | Logs centrales, exportados a tu SIEM |
NeuralTrust lo aborda como una Runtime Security Mesh. La Agent Gateway (TrustGate) reúne las llamadas a modelos, servidores MCP, herramientas y agentes detrás de un único gateway. Añade RBAC por agente y por herramienta, la identidad del usuario final en cada salto y auditorías criptográficas. Agent Runtime Security (TrustGuard) inspecciona solicitudes y respuestas en línea, incluidos los resultados de herramientas envenenados, y puede permitirlos, bloquearlos o transformarlos. AI Red Teaming (TrustTest) prueba los agentes frente a inyección indirecta y abuso de herramientas antes del lanzamiento. NeuralTrust indica menos de 100 ms de latencia añadida en p95 con PromptGuard y Data Masking activados. El plan Free cubre TrustGate y TrustGuard con 100.000 solicitudes al mes.
¿Por qué defensa deberías empezar?
Empieza donde tu exposición sea mayor. Quien instala servidores de terceros necesita primero revisión y fijación. Quien ejecuta muchos servidores en un agente necesita aislamiento. Los sectores regulados necesitan la auditoría que demuestra que los demás controles funcionaron. La mayoría de los equipos acaba necesitando las tres.
| Si eres | Empieza por | Después añade |
|---|---|---|
| Desarrollador que usa servidores MCP en el IDE | Revisión completa de definiciones, servidores locales en sandbox | Fijación con alertas de cambio, registro aprobado |
| Equipo de plataforma con agentes a escala | Gateway central, lista de permitidos, definiciones fijadas | Aislamiento entre servidores, inspección de salidas |
| Equipo de seguridad en un sector regulado | Aprobación humana para herramientas sensibles, auditoría completa | Red teaming contra poisoning y rug pulls |
En los servidores remotos, el alcance de las credenciales decide hasta dónde llega una herramienta envenenada. Nuestra guía de autenticación MCP explica OAuth y los tokens.
Conclusión
El tool poisoning en MCP convierte los metadatos de las herramientas en un canal de órdenes. La inyección en la descripción planta la instrucción, el rug pull la entrega después de la aprobación y el tool shadowing la dirige contra tus herramientas de más confianza. Las soluciones se conocen: revisar definiciones completas, calcular su hash y fijarlas, fallar en cerrado ante cambios, aislar servidores e inspeccionar salidas en ejecución. Con tasas de rechazo inferiores al 3 % en los benchmarks, coloca esos controles donde pase cada conexión MCP.
Protege las herramientas MCP en producción con NeuralTrust
Pon cada llamada a herramientas MCP detrás de un único gateway, con control de acceso por herramienta, inspección en ejecución y auditoría completa.
)
Comparativas relacionadas
- OWASP MCP Top 10
- Buenas prácticas de seguridad en MCP
- Prompt injection en MCP
- Registros y listas de permitidos MCP
Preguntas frecuentes sobre el tool poisoning en MCP
1. ¿Qué es el tool poisoning en MCP?
Es una prompt injection indirecta en la que instrucciones maliciosas se esconden en la descripción, el esquema de parámetros o la respuesta de una herramienta. El cliente mete esos metadatos en el contexto del modelo al cargar la lista de herramientas, así que el ataque funciona aunque nunca se llame a la herramienta. Trail of Bits lo llama line jumping.
2. ¿Qué es un ataque rug pull en MCP?
Un rug pull ocurre cuando un servidor MCP cambia una herramienta después de que la aprobaras y la vuelve maliciosa. El cambio puede ser texto oculto, un parámetro nuevo, una anotación modificada o código nuevo. Calcula el hash de la definición aprobada, fíjala, bloquea la herramienta hasta que alguien apruebe el cambio y verifica las versiones de los paquetes.
3. ¿Qué es el tool shadowing en MCP?
Es cuando la descripción de un servidor malicioso cambia cómo el agente usa las herramientas de otros servidores de confianza. Por ejemplo, puede ordenar al agente que copie a un destinatario extra en cada correo. La herramienta de confianza ejecuta la acción dañina, así que el aislamiento por servidor y la vigilancia entre servidores son los controles clave.
4. ¿Fijar las herramientas frena todo el tool poisoning?
No. La fijación detecta cambios en los metadatos tras la revisión, lo que frena los rug pulls a nivel de definición. No detecta código malicioso tras una definición sin cambios, salidas envenenadas ni una definición mala aprobada por error. Combínala con revisión previa, versiones de paquetes verificadas e inspección en ejecución.
5. ¿Puede el propio modelo rechazar las instrucciones envenenadas?
Casi nunca. En el benchmark MCPTox, el modelo que más se negó rechazó menos del 3 % de los ataques, y los modelos más capaces solían ser los más vulnerables. Trata el comportamiento del modelo como un extra, no como un control, y aplica la autorización y la validación en código de confianza fuera del modelo.
6. ¿En qué se diferencia el tool poisoning de la prompt injection en la salida de una herramienta?
El tool poisoning vive en la definición de la herramienta, que el modelo lee antes o durante la selección. La prompt injection en la salida vive en los datos que devuelve la herramienta tras una llamada, como una web o un correo. Ambas son prompt injection indirecta, así que trata definiciones y salidas como no fiables.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde dirige la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda impulsada por IA, estrategia de contenidos y SEM. Conecta con él en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Nombrada pionera en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026 y destacada en la Gartner Market Guide for Guardian Agents 2026, la Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
Consultadas el 4 de noviembre de 2026.
- OWASP Cheat Sheet Series, "MCP Security Cheat Sheet".
- OWASP, "MCP Top 10" (beta 2025).
- Model Context Protocol, "Tools" (versión de la especificación 2026-07-28), 2026.
- Trail of Bits, "Jumping the line: How MCP servers can attack you before you ever use them", 21 de abril de 2025.
- Wang et al., "MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers", arXiv, agosto de 2025, revisado el 29 de septiembre de 2026.
- NIST National Vulnerability Database, "CVE-2025-54136", publicado el 2 de agosto de 2025.
- Qualys ThreatPROTECT, "Malicious MCP Server on npm postmark-mcp Exploited in Attack", 30 de septiembre de 2025.
- Andreessen Horowitz, "The New Security Agenda", 2026.
- NeuralTrust, "Agent Gateway (TrustGate)" y precios, páginas de producto.