Cuando se descubre una vulnerabilidad grave en un producto, el guion habitual es: el fabricante confirma el hallazgo, publica un parche, el ecosistema respira. Con el Model Context Protocol (MCP), el guion se rompió: el fabricante confirmó el hallazgo y decidió no cambiarlo, porque el comportamiento forma parte del diseño del protocolo.
Qué es MCP y por qué se adoptó tan rápido
MCP es un protocolo abierto creado por Anthropic para estandarizar cómo los agentes de IA se conectan a herramientas externas, bases de datos y APIs — en vez de que cada integración se construya de forma distinta y aislada. Su adopción fue extraordinariamente rápida: reportes de la industria hablan de más de 150 millones de descargas de paquetes relacionados con el protocolo en poco más de un año.
Ese ritmo de adopción es, precisamente, lo que convierte cualquier problema de diseño en un problema a escala de industria de un día para otro.
El hallazgo: 200.000 instancias vulnerables, por diseño
Según una nota de investigación de Cloud Security Alliance, que cita hallazgos de OX Security de abril de 2026, el transporte STDIO —el mecanismo de comunicación por defecto de MCP— procesa la configuración entrante pasando parámetros directamente al shell del sistema operativo, sin sanitización ni validación de entrada. El resultado: ejecución remota de código en cualquier máquina con una instancia vulnerable expuesta. La investigación estima aproximadamente 200.000 instancias vulnerables.
Lo distintivo del caso, según la misma nota, es que Anthropic confirmó que este comportamiento es intencional y no modificó la arquitectura del protocolo. No se trata de un error de codificación esperando un parche: es una decisión de diseño que traslada la responsabilidad de mitigar el riesgo a cómo cada organización despliega y aísla sus servidores MCP.
instancias de MCP identificadas como vulnerables a ejecución remota de código a través del transporte STDIO por defecto — sin que exista, ni se planee, un parche que elimine la causa raíz.
Tool poisoning: lo que el agente lee no es lo que tú ves
Más allá del transporte, la misma investigación identifica el tool poisoning como la vulnerabilidad más frecuente e impactante del lado del cliente. La técnica aprovecha una asimetría simple: la descripción de una herramienta que consume el modelo de IA rara vez es la misma que se muestra en la interfaz que ve una persona. Esa descripción puede contener instrucciones ocultas que dirijan al agente a exfiltrar datos, ejecutar acciones no autorizadas o suprimir notificaciones — todo mientras la persona usuaria ve una descripción de herramienta que parece perfectamente normal.
A esto se suma lo que la investigación llama propagación de confianza implícita ("shadowing"): un servidor MCP malicioso puede inyectar descripciones que redefinen cómo el agente entiende herramientas adyacentes en las que sí confía, contaminando la integración completa a partir de un solo punto comprometido.
Qué hacer si tu organización ya conecta agentes de IA a herramientas
1. Inventario real de servidores MCP
La mayoría de las organizaciones no tiene un registro centralizado de qué servidores MCP están corriendo, quién los configuró y a qué credenciales tienen acceso. Sin ese inventario, no hay nada que asegurar.
2. Aísla los procesos MCP
Ejecuta cada servidor en contenedores dedicados, sin acceso directo a credenciales de nivel host. Si un servidor se compromete, el daño debe quedar contenido ahí, no propagarse al resto del entorno.
3. Monitorea comportamiento, no solo firmas conocidas
Un SOC que vigile específicamente el comportamiento de procesos MCP —llamadas inusuales, escalación de privilegios, tráfico de salida inesperado— detecta explotación incluso cuando la técnica exacta usada es nueva.
4. Aplica Zero Trust y valida con pentesting real
Ninguna herramienta conectada a un agente debería heredar confianza automática por estar en la misma integración — el mismo principio que ya explicamos sobre credenciales aplica directo a integraciones de IA. Nuestro servicio de Pentesting incluye evaluación específica de integraciones MCP: probamos tool poisoning, aislamiento entre servidores y qué alcance real obtiene un atacante si uno de ellos cae.
Por qué esto importa ahora, no en un año
Los equipos están conectando agentes de IA a repositorios de código, bases de datos y sistemas internos hoy, muchas veces para acelerar productividad sin que pase por una revisión de seguridad formal. Cuando el propio fabricante del protocolo confirma que un vector de riesgo es parte del diseño y no lo va a cambiar, la seguridad deja de ser un tema de "esperar el parche" y pasa a ser, exclusivamente, una responsabilidad de gobierno y arquitectura de cada organización que lo adopta.
Preguntas frecuentes
¿Qué es el Model Context Protocol (MCP)?
Es un protocolo abierto creado por Anthropic que estandariza cómo los agentes de IA se conectan a herramientas externas, bases de datos y APIs, con una adopción que supera los 150 millones de descargas de paquetes relacionados.
¿Por qué Anthropic no corrige la vulnerabilidad del transporte STDIO?
Porque, según la investigación citada, ese comportamiento es una decisión de diseño intencional del protocolo, no un error. La mitigación recae en cómo cada organización despliega y aísla sus servidores MCP.
¿Qué es tool poisoning?
Insertar instrucciones maliciosas ocultas en la descripción de una herramienta que el agente procesa, pero que la interfaz de usuario rara vez muestra, permitiendo órdenes que nadie autorizó ni vio.
¿Mi empresa usa MCP aunque no lo sepa formalmente?
Es posible, especialmente si algún equipo ya conectó agentes de IA a herramientas internas para acelerar su trabajo. El primer paso es siempre un inventario real de qué servidores MCP existen.
¿Cómo se prueba la seguridad de una integración MCP?
Con pentesting dirigido a integraciones de agentes de IA: técnicas de tool poisoning, aislamiento entre servidores, y qué acceso obtiene un atacante si un servidor conectado resulta comprometido.