MCP: 5 servidores conectados dan 78% de éxito al atacante

El fallo no está en el modelo, está en la cadena de confianza

El Model Context Protocol (MCP), el estándar abierto que conecta a los agentes de IA con herramientas, datos y sistemas reales, arrastra un problema que ninguna actualización del modelo resuelve: conectar cinco servidores MCP a un mismo agente llevó la tasa de éxito de ataque al 78,3% en las pruebas de Unit 42, la unidad de investigación de Palo Alto Networks, según documenta VentureBeat. Cinco servidores no son un escenario extremo: es una semana normal para cualquier equipo que ya superó la prueba de concepto.

Para un founder que está metiendo agentes en producción, la lectura es incómoda. El riesgo no viene de un proveedor desconocido ni de un modelo mal alineado. Viene de la confianza que tu propio agente ya deposita en las herramientas que le conectaste.

MCP estandarizó cómo los agentes descubren y llaman herramientas. Nunca estandarizó cómo se prueba quién llama ni qué puede tocar. Esa asimetría es el hueco por el que entra el ataque.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Cómo funciona el ataque de confianza en cascada?

El mecanismo se llama confianza en cascada, y es más simple de lo que suena. Una vez que el agente trata la salida de un servidor como contexto confiable, un servidor comprometido puede inyectar instrucciones que viajan en cada llamada posterior de herramienta, incluidas las llamadas a servidores que nunca fueron comprometidos.

Ars Technica documentó una variante especialmente incómoda. El investigador independiente Syed Anas Mohiuddin probó agentes de organizaciones como Google, JPMorgan Chase, Weaviate, Rapid7, la dirección digital interministerial del gobierno francés y el gobierno federal de Estados Unidos. La técnica es una forma de inyección de prompts que no ataca al modelo de lenguaje sino a un agente concreto —uno de traducción, uno de análisis de datos— cuyos controles internos son laxos y que reenvía las instrucciones al siguiente agente de la cadena. Como el segundo agente confía explícitamente en el primero, obedece.

El detalle que rompe la intuición: como los servidores MCP guardan credenciales para cada agente, y los agentes están construidos para confiar en el resto de agentes internos, un exploit que el modelo de lenguaje habría rechazado termina funcionando. En muchos casos la cadena desemboca en una falsificación de petición del lado del servidor (SSRF), que permite lanzar peticiones de red no autorizadas desde dentro de tu propio perímetro.

¿Cómo evolucionó la autenticación de MCP y qué quedó viejo en tu stack?

Los changelogs oficiales de la especificación muestran cinco etapas, no un parche único:

2024-11-05 (lanzamiento): sin marco de autorización. Cada implementador decidía cómo autenticar.
2025-03-26: se añade un marco de autorización basado en OAuth 2.1.
2025-06-18: los servidores MCP pasan a clasificarse formalmente como OAuth Resource Servers y se exigen Resource Indicators (RFC 8707) para evitar que un servidor malicioso obtenga tokens destinados a otros servicios.
2025-11-25: se suman los OAuth Client ID Metadata Documents (CIMD) como método de registro recomendado, junto al Dynamic Client Registration (DCR).
2026-07-28: el DCR queda formalmente deprecado en favor de CIMD, se obliga a los clientes a validar el parámetro iss (RFC 9207) y se anuncia como la mayor revisión desde el lanzamiento.

La consecuencia práctica es directa: cualquier servidor construido durante el primer año probablemente arrastra supuestos que la especificación ya abandonó. No es que esté mal escrito; es que la norma se movió mientras el equipo dormía.

Hay un matiz que suele perderse. La extensión Enterprise-Managed Authorization (EMA), ya estable y adoptada por Anthropic, Microsoft y Okta según InfoQ, centraliza el consentimiento en el proveedor de identidad: un solo inicio de sesión y acceso heredado a los servidores que la organización aprobó, con un flujo basado en ID-JAG. Suena a solución completa, pero la propia documentación advierte que no es autorización en tiempo de ejecución por acción. Decide si un usuario puede conectarse a un servidor y con qué alcance; no inspecciona el tráfico después de emitido el token. Siguen haciendo falta controles propios dentro del sistema.

¿Qué dicen OWASP y la NSA sobre lo que el protocolo no cubre?

El OWASP MCP Top 10 pone la mala gestión de tokens y la exposición de secretos como su categoría de máxima prioridad: credenciales hardcodeadas y secretos guardados en la memoria del modelo pueden exponer entornos completos, y muchas veces son recuperables mediante inyección de prompts.

La guía de la NSA publicada en mayo de 2026, mapeada contra la lista de OWASP, deja una observación que conviene subrayar: solo dos de las diez categorías de riesgo viven en el texto que el agente lee y sobre el que actúa. Las otras ocho —credenciales, alcance, identidad— están en la infraestructura, donde el protocolo no impone restricciones. No es un protocolo inseguro por descuido: es un protocolo que resolvió la interoperabilidad y dejó la identidad a cargo de cada equipo.

Y la adopción no espera. Según la encuesta State of Model Context Protocol in Software 2026 de Stacklok, casi la mitad de las empresas de software consultadas ya usa MCP en producción y 19% reporta uso amplio en producción, dato difundido en el anuncio de Radware sobre protección de servidores MCP.

¿Por qué Figma dice que MCP "no es un protocolo perfecto"?

En la primera edición de Config en India, Figma anunció 20 nuevos socios de MCP, entre ellos Amp, ClickUp, Linear, Mistral, Notion y Sarvam Agents. Su cofundador Dylan Field acompañó el anuncio con una advertencia: "creo que MCP no es un protocolo perfecto y que tiene muchísimo margen de mejora", dijo, según TechCrunch. El CEO explicó la razón de fondo para no abrirlo todo: cuanto más dato expone la empresa vía MCP, mayor es la probabilidad de abuso.

Ese es el dilema que ningún CTO rodea. Más superficie de integración es más producto y más riesgo en la misma decisión.

Dos escenarios de despliegue, dos posturas

Herramienta interna, detrás del firewall. Menos exposición, pero no cero. La gobernanza interna de MCP de Microsoft, descrita en su blog Inside Track, emite tokens de corta vida y mínimo privilegio incluso para tráfico puramente interno: interno no es sinónimo de confiable.

Servidor remoto o SaaS multiinquilino con endpoint expuesto a clientes. El escenario de mayor apuesta. La guía de Azure recomienda un gateway con identidad que rechace cualquier llamada sin token válido y ligado a una audiencia, más un registro que fije las definiciones de herramientas para que un rug pull —una dependencia confiable que cambia de comportamiento en silencio— lo detecte la detección de deriva y no tu producción.

¿Centralizado o por servidor?

Consistencia entre servidores: la aplicación por servidor depende de cada desarrollador; un gateway de identidad es uniforme por construcción.
Detección de un servidor comprometido: por servidor solo funciona si ese servidor registra bien; el gateway puede fijar definiciones de herramientas y alertar sobre desvíos.
Encaje: por servidor, una sola herramienta interna. Gateway de identidad, cualquier despliegue que pase de un puñado de servidores.

Microsoft y la NSA convergen, de forma independiente, en la misma respuesta: empuja identidad, alcance y auditoría a una capa delante de todos los servidores, en lugar de confiar en cada uno por separado.

¿Qué significa esto para tu startup?

No necesitas un departamento de seguridad para cerrar el hueco más grande. Necesitas dejar de tratar cada servidor MCP como un detalle de integración y empezar a tratarlo como un actor de identidad con permisos propios.

1. Levanta el inventario antes de la próxima integración. Si no puedes listar cuántos servidores MCP tienes, qué exponen y qué agentes los llaman, no tienes gobernanza: tienes suerte. Un registro con definiciones de herramientas fijadas y alertas de deriva cuesta una tarde de trabajo y detecta el escenario más caro.

2. Trata cada servidor como OAuth Resource Server, sin excepciones. Token con audiencia específica, alcance mínimo y vida corta. La guía de Microsoft lo dice con un ejemplo que sirve para cualquier equipo: no concedas acceso completo al buzón cuando basta con lectura.

3. Deja de cachear credenciales al arrancar el servidor. Un token que vive en la memoria del proceso no se puede revocar de forma real. Tráelo en el momento de la llamada.

4. Valida el parámetro iss ahora, antes de que sea obligatorio, y no apuestes por DCR. Quedó formalmente deprecado en julio de 2026.

5. Prueba la inyección cruzada, no solo la directa. La mayoría de los equipos prueba si su agente obedece un prompt malicioso. Casi nadie prueba si el agente A reenvía instrucciones al agente B. Ese es exactamente el vector que documentaron las pruebas sobre agentes corporativos y de agencias públicas.

Conclusión

El modelo de autorización de MCP cambió en cada revisión desde su lanzamiento y ya hay más endurecimiento señalado. Lo estable no es una versión: es la dirección. Patrones formales de resource server, validación explícita de emisor y gobernanza centralizada en lugar de confianza ad hoc.

Para un CTO que decide cómo conectar la siguiente integración, la brecha entre velocidad de despliegue y gobernanza de identidad no es una nota al pie del proyecto. Es el proyecto.