La nueva MCP empresarial traslada la seguridad del protocolo a tus desarrolladores

¿Qué es esto?

El Model Context Protocol afronta su mayor cambio estructural desde que Anthropic lo publicó a finales de 2024. La especificación MCP 2026-07-28 —candidata publicada el 21 de mayo de 2026, versión final prevista para el 28 de julio de 2026, con una ventana de obsolescencia de doce meses para funciones heredadas— lleva a MCP de una herramienta de integración local y monousuario hacia un protocolo sin estado, pensado para despliegues cloud a escala empresarial.

El 25 de junio de 2026, el equipo de investigación de amenazas de Akamai (Maxim Zavodchik, Segev Fogel y Gal Meiri) publicó un modelado de amenazas de la nueva especificación. Su conclusión justifica este artículo: la reescritura cierra realmente varias clases de vulnerabilidades a nivel de protocolo, pero lo hace trasladando las decisiones de seguridad correspondientes a los desarrolladores y operadores de plataforma que implementan los servidores MCP. El protocolo se vuelve más seguro; que un despliegue concreto lo sea depende ahora por completo de la calidad de la implementación.

Cómo funciona

Tres clases de riesgo antiguas se reducen o eliminan. Las sesiones gestionadas por el protocolo —el Mcp-Session-Id de larga duración que un atacante podía robar para suplantar a un usuario— desaparecen a favor de un modelo sin estado. Los servidores ya no pueden enviar prompts no solicitados a los clientes en cualquier momento, lo que cierra un canal que un servidor comprometido podía usar. Y la autenticación pasa a OAuth 2.1 obligatorio, descartando los grants por contraseña e implícitos heredados y exigiendo protecciones como PKCE.

A cambio, aparece un nuevo conjunto de superficies donde la seguridad depende de cómo se escriba cada servidor, no del protocolo:

Eliminado / reducido por el protocolo      Ahora responsabilidad del desarrollador
---------------------------------------  -------------------------------------------
Secuestro de sesión (protocolo)          Integridad del objeto de estado (workflow)
Prompts de servidor no solicitados       Confianza en los metadatos _meta del cliente
Autenticación débil / heredada           Coherencia cabecera / cuerpo (desync)
                                         No mapear secretos en las cabeceras HTTP
                                         Codificar la UI de las MCP Apps (XSS almacenado)
                                         Cuotas en tareas asíncronas largas

Al ser el protocolo sin estado, el servidor entrega al cliente un identificador de seguimiento y un objeto de estado, y confía en que el cliente los devuelva para reanudar un workflow en pausa. Si un servidor usa identificadores predecibles o no verifica la integridad del estado devuelto, un atacante puede adivinar o manipular esos valores para secuestrar el workflow activo de otro usuario o desencadenar acciones entre inquilinos. La especificación pide verificar estos objetos pero no normaliza cómo hacerlo.

Un nuevo objeto _meta permite al cliente adjuntar pares clave-valor arbitrarios a casi cualquier mensaje, sin firma criptográfica. Un servidor que confíe en un {"tenant": "admin"} para el enrutamiento o la autorización puede ser conducido a una escalada de privilegios en una sola petición. Del mismo modo, las nuevas cabeceras HTTP de MCP (Mcp-Method, Mcp-Name) invitan a ataques de desync cuando la cabecera y el cuerpo JSON-RPC discrepan, y una directiva x-mcp-header que mapea argumentos de herramienta en cabeceras filtrará secretos a cada proxy y registro del camino si un desarrollador mapea el campo equivocado. Por último, las MCP Apps —los paneles de interfaz interactivos ahora ascendidos a extensión de primera clase— importan el cross-site scripting almacenado clásico a la superficie del agente (aislado en un <iframe>, pero suficiente para hacer phishing o exfiltrar lo que el panel ve), y las tareas largas baratas de lanzar crean un vector de denegación de servicio de tipo «golpea y huye».

Por qué importa

MCP ya es el tejido conectivo de facto entre los agentes y las herramientas empresariales, y su adopción se acelera precisamente hacia los despliegues multiinquilino y alojados en la nube que esta especificación busca. La pregunta de seguridad pasa de «¿es seguro el protocolo?» a «¿implementó este servidor correctamente las nuevas fronteras de confianza?», y la respuesta variará de un servidor a otro. La ventana de migración (soporte heredado durante doce meses) implica además parques mixtos que ejecutan a la vez semánticas antiguas y nuevas, terreno ideal para los fallos de desync y de gestión de estado. Si tu organización publica o consume servidores MCP, el cambio del 28 de julio es un evento planificado que puedes preparar.

Defensas

Las recomendaciones de Akamai, generalizadas para cualquier equipo que adopte la nueva especificación:

1. Trata todo estado y metadato aportado por el cliente como no fiable. Firma y verifica la integridad de los objetos de estado; nunca tomes decisiones de autorización o enrutamiento a partir de campos _meta sin firmar. Usa identificadores de seguimiento impredecibles y de alta entropía, ligados en el servidor al principal autenticado.
2. Reconcilia cabeceras y cuerpo. Asegura que proxys, pasarelas y servidor coincidan en Mcp-Method / Mcp-Name frente al cuerpo JSON-RPC; rechaza las peticiones contradictorias para cerrar las brechas de desync.
3. Audita los mapeos x-mcp-header. Nunca mapees claves de API, tokens o PII en cabeceras HTTP. Revisa estos mapeos antes del despliegue y en la revisión de código, porque la fuga es silenciosa.
4. Codifica la salida de las MCP Apps. Aplica una codificación de salida estricta y una CSP restrictiva a cualquier HTML aportado por usuario o herramienta que se renderice en los paneles; mantén el sandbox, pero no confíes solo en él.
5. Impón cuotas a las tareas asíncronas. Limita la tasa y acota los recursos de creación de tareas, y liga el trabajo largo a una sesión autenticada y responsable para que un solo cliente que se desconecta no pueda agotar el servidor.
6. Planifica la migración. Inventaría servidores y clientes MCP, rastrea cuáles hablan la nueva semántica sin estado, y evita los despliegues en modo mixto prolongados donde el comportamiento antiguo y el nuevo puedan enfrentarse.

Estado

Elemento	Referencia	Fecha	Notas
Candidata MCP 2026-07-28	modelcontextprotocol.io	2026-05-21	Arquitectura sin estado, MCP Apps, tareas async, OAuth 2.1
Modelado de Akamai	Akamai SIG	2026-06-25	Análisis del desplazamiento de la superficie de ataque
Especificación final	modelcontextprotocol.io	2026-07-28 (previsto)	Ventana de obsolescencia heredada de 12 meses

El titular no es «la nueva especificación MCP es insegura» —elimina riesgos reales a nivel de protocolo—. Es que la responsabilidad de la seguridad se ha trasladado a quienes construyen los servidores MCP, a partir del cambio del 28 de julio. Los equipos que traten la migración como un proyecto de seguridad de implementación, y no como una simple actualización, serán los que eviten heredar las nuevas superficies.