Conclusiones clave
El 28 de julio de 2026, Model Context Protocol (MCP) adoptará oficialmente una arquitectura sin estado y preparada para entornos empresariales.
Al pasar a un modelo sin estado e incorporar aplicaciones con interfaces de usuario enriquecidas y tareas asíncronas, el protocolo traslada por completo a los desarrolladores la responsabilidad de crear límites de seguridad críticos.
La actualización elimina importantes riesgos de seguridad históricos, como el secuestro de sesiones a nivel de protocolo, las instrucciones no solicitadas del servidor y los métodos de autenticación poco seguros.
Sin embargo, la introducción de un estado gestionado por la aplicación, interfaces de IA interactivas y enriquecidas, y tareas asíncronas de larga duración crea nuevas vías de abuso.
Si estas nuevas capacidades no se protegen adecuadamente, podrían facilitar el acceso no autorizado a datos de clientes, campañas de phishing dirigidas a los usuarios a través de experiencias de IA de confianza, la elusión de los controles de seguridad empresariales y la interrupción de los servicios mediante el uso indebido de flujos de trabajo de procesamiento en segundo plano.
La próxima especificación MCP 2026-07-28 representa la evolución arquitectónica más importante de Model Context Protocol (MCP) desde su creación. Lo que comenzó como una herramienta local de integración de IA para un único usuario se está transformando en una plataforma capaz de admitir implementaciones nativas de la nube a escala empresarial.
Tras la publicación de la versión candidata el 21 de mayo de 2026, está previsto que la especificación definitiva se publique el 28 de julio de 2026, junto con un periodo formal de retirada progresiva de 12 meses para determinadas funciones heredadas.
Evolución de la superficie de ataque
Para ofrecer esta base preparada para entornos empresariales, la actualización modifica por completo la forma en que el protocolo gestiona los datos y la ejecución. Introduce una arquitectura sin estado compatible con solicitudes de múltiples intercambios, nuevos encabezados HTTP estandarizados y un objeto universal _meta para los mensajes contextuales. Además, la especificación formaliza las aplicaciones MCP y las tareas asíncronas, al tiempo que otorga a la integración de OAuth un papel fundamental.
Aunque gran parte del debate en torno a estas funciones se centra en la escalabilidad y la interoperabilidad, su impacto estructural en la superficie de ataque del protocolo es igualmente significativo. A medida que evoluciona el modelo de seguridad, algunos riesgos históricos a nivel de protocolo se mitigan o desaparecen por completo, mientras que nuevas responsabilidades recaen directamente en los desarrolladores de aplicaciones MCP (Figura 1). En definitiva, aunque estos cambios mejoran la base del protocolo, las decisiones de implementación pasan a determinar la estrategia de seguridad general.
Fig. 1: Evolución de la superficie de ataque de MCP en la nueva especificación
Superficies de ataque reducidas o eliminadas
Las versiones anteriores de MCP presentaban varios riesgos de seguridad debido a las sesiones gestionadas por el protocolo, las comunicaciones iniciadas por el servidor y unos requisitos de autenticación menos maduros. La nueva especificación rediseña o elimina varios de estos mecanismos, lo que reduce la superficie de ataque a nivel de protocolo. Entre estos mecanismos se incluyen:
Secuestro de sesiones a nivel de protocolo
Solicitudes del servidor no solicitadas
Métodos de autenticación poco seguros
Secuestro de sesiones a nivel de protocolo
Las versiones anteriores de MCP se basaban en un proceso de inicialización con estado que establecía una sesión de larga duración mediante el encabezado Mcp-Session-Id. Estos identificadores de sesión suelen ser objetivos de gran valor, ya que los atacantes que consiguen obtenerlos pueden suplantar a usuarios autenticados.
La nueva especificación elimina por completo estas sesiones gestionadas por el protocolo y, con ello, este vector de ataque concreto. Sin embargo, ahora los desarrolladores deben crear sus propios mecanismos seguros de gestión del estado, que analizaremos más adelante en esta entrada de blog.
Solicitudes del servidor no solicitadas
Las versiones anteriores de MCP permitían que los servidores enviaran solicitudes o instrucciones inesperadas a los clientes en cualquier momento mediante Eventos enviados por el servidor (SSE).
Las nuevas reglas limitan estrictamente este comportamiento, lo que impide que los servidores comprometidos interrumpan de forma silenciosa a los usuarios con interacciones maliciosas no solicitadas.
Métodos de autenticación poco seguros
La actualización obliga a adoptar unos requisitos estrictos de OAuth 2.1, lo que reduce drásticamente los riesgos de autenticación. Al eliminar los flujos de concesión heredados basados en contraseña e implícitos y exigir mecanismos de protección modernos como Clave de Prueba para el Intercambio de Código (PKCE)), el protocolo limita considerablemente las posibilidades de filtración o explotación de credenciales y tokens.
En conjunto, estos cambios reducen de forma significativa la superficie de ataque relacionada con la autenticación y el alcance potencial de una sesión comprometida que existían en implementaciones anteriores de MCP.
Nuevas superficies de ataque introducidas por la especificación
Aunque el protocolo elimina varias clases de vulnerabilidades, también introduce nuevas áreas en las que la seguridad depende en gran medida de la calidad de la implementación, entre ellas:
Secuestro de flujos de trabajo entre agentes
Manipulación de metadatos controlados por el cliente
Confusión de encabezados y exposición de datos a través de estos
MCP Apps y ataques de scripts entre sitios (XSS) almacenados
Riesgos de explotación en tareas de larga duración que se ejecutan en segundo plano
Secuestro de flujos de trabajo entre agentes
La transición hacia una arquitectura sin estado introduce retos de seguridad sutiles. En los entornos empresariales, las interacciones con IA no siempre consisten en una conversación sencilla basada en una única solicitud, sino que suelen requerir una secuencia de eventos. Por ejemplo:
Solicitar aclaraciones: una herramienta podría detenerse a mitad de una tarea para pedir al usuario información que falta
Comprobar el progreso: una tarea de larga duración podría requerir que el sistema solicitara actualizaciones periódicamente
Pausar flujos de trabajo: un proceso complejo podría detenerse durante una hora a la espera de la aprobación de una persona y, después, reanudar la ejecución exactamente desde el punto en el que se había quedado
Como el nuevo MCP no tiene estado, no utiliza sesiones permanentes para recordar la identidad de cada participante. En su lugar, introduce identificadores de seguimiento y objetos de estado que el servidor entrega al cliente. Después, el cliente los vuelve a enviar cuando está preparado para reanudar el flujo de ejecución, lo que, en la práctica, le otorga un control total sobre el estado de la tarea.
El problema de seguridad es sencillo: como estos identificadores de seguimiento y objetos de estado proceden directamente del cliente, el servidor no puede confiar en ellos sin validarlos. La Figura 2 muestra que, si un servidor MCP utiliza identificadores de seguimiento predecibles o no valida de forma estricta la integridad del objeto de estado recibido, un atacante podría adivinar o modificar estos valores para:
secuestrar el flujo de trabajo activo de otro usuario;
acceder a información perteneciente a otro agente;
desencadenar acciones no autorizadas entre distintos clientes.
Fig. 2: Ilustración de la adivinación de identificadores de seguimiento y la manipulación del estado
Aunque la especificación oficial de MCP advierte expresamente a los desarrolladores de que deben verificar la integridad de estos objetos, no establece ningún estándar ni implementación concretos, por lo que la responsabilidad de crear esta capa de seguridad recae por completo en los desarrolladores de cada servidor.
Manipulación de metadatos controlados por el cliente
La nueva especificación introduce un objeto _meta que permite a los clientes adjuntar metadatos personalizados a prácticamente cualquier mensaje de MCP. Incluso en una única solicitud sencilla, un atacante podría proporcionar pares clave-valor maliciosos, como {"tenant": "admin", "authenticated": true}.
Dado que estos campos no cuentan con firma criptográfica, si un servidor confía en estos metadatos sin validarlos para tomar decisiones de enrutamiento o autorización, una sola solicitud maliciosa podría provocar de inmediato una escalada de privilegios o el acceso a datos de otros clientes.
Confusión de encabezados y exposición de datos a través de estos
La especificación introduce encabezados HTTP específicos de MCP, como Mcp-Method y Mcp-Name, que ayudan a los intermediarios, proxies, gateways y servidores a interpretar de forma coherente las solicitudes de MCP y enrutarlas correctamente.
Sin embargo, estos encabezados también introducen dos nuevos riesgos de seguridad:
Ataques por confusión de protocolos (desincronización): los atacantes pueden enviar valores contradictorios entre los encabezados HTTP y el cuerpo de la solicitud JSON-RPC, aprovechando las discrepancias entre dos protocolos de comunicación distintos: HTTP y JSON-RPC, para desincronizar la infraestructura de back-end. Esta incoherencia puede hacer que los proxies y los servidores de back-end interpreten de forma distinta una misma solicitud, lo que permite a los atacantes eludir los controles de seguridad, evitar la supervisión u ocultar acciones maliciosas.
Filtración de datos mediante x-mcp-header: esta nueva directiva permite a los desarrolladores asignar determinados argumentos de las herramientas directamente a encabezados HTTP. Esto ayuda a los proxies a enrutar el tráfico con mayor rapidez sin tener que analizar todo el cuerpo de la solicitud. Sin embargo, si los desarrolladores asignan por error datos confidenciales, como claves de API, tokens o información de identificación personal (PII), estos datos se trasladan directamente a los encabezados. Una vez allí, quedan expuestos a todos los balanceadores de carga, proxies y sistemas de registro presentes a lo largo de la ruta.
MCP Apps y ataques de scripts entre sitios (XSS) almacenados
Una de las novedades más interesantes de MCP es la conversión de MCP Apps en una extensión de protocolo de primer nivel. MCP Apps son los paneles visuales interactivos que aparecen dentro de aplicaciones de IA como Claude Desktop (por ejemplo, formularios y paneles interactivos, visores de documentos, y pantallas de seguimiento de flujos de trabajo y tareas).
Aunque estas interfaces enriquecidas mejoran considerablemente la experiencia del usuario, también trasladan al ecosistema de IA riesgos tradicionales de los navegadores web, como el script entre sitios (XSS) almacenado. Por ejemplo, un atacante podría almacenar código HTML o JavaScript malicioso a través de una herramienta MCP. Cuando otro usuario (o un agente de IA) visualiza ese contenido, el script malicioso se ejecuta automáticamente dentro de la interfaz de la aplicación.
Aunque la especificación de MCP exige que los agentes ejecuten estos scripts dentro de un <iframe> aislado para impedir que los atacantes lleguen a tomar por completo el control del agente de IA, los usuarios siguen estando expuestos a riesgos. Un atacante todavía podría utilizar el panel comprometido para mostrar contenido engañoso, llevar a cabo campañas de phishing destinadas a obtener información confidencial mediante indicaciones falsas, robar cualquier dato del usuario que esté visible en ese panel concreto y enviar la información sustraída a sus propios servidores (Figura 3).
Fig. 3: Ilustración de la explotación de MCP Apps mediante XSS almacenado
Riesgos de explotación en tareas de larga duración que se ejecutan en segundo plano
La introducción de tareas de larga duración crea un importante vector de ataque de denegación de servicio (DoS) basado en interacciones unidireccionales. Dado que crear una tarea supone un coste reducido para el cliente, pero exige muchos recursos al servidor, un atacante puede enviar una única solicitud para iniciar una operación costosa (que consuma CPU, memoria o almacenamiento de base de datos) y desconectarse de inmediato.
Este método de explotación asíncrona unidireccional obliga al servidor a seguir procesando cargas de trabajo pesadas incluso después de que el cliente se haya desconectado, lo que puede agotar fácilmente los recursos del servidor.
Conclusión
La especificación MCP 2026-07-28 marca la transición del protocolo desde el uso local hasta las implementaciones a escala empresarial. Desde el punto de vista de la seguridad, estos cambios no son meras mejoras incrementales. Transforman de forma fundamental dónde recaen las responsabilidades de seguridad: las decisiones de seguridad que antes aplicaba el propio protocolo se delegan cada vez más en los desarrolladores de servidores MCP y los operadores de plataformas.
A medida que se acelera la adopción de MCP en entornos de nube, la principal cuestión de seguridad ya no es si el protocolo en sí es seguro. En su lugar, los equipos de seguridad deben determinar si las aplicaciones creadas sobre MCP implementan correctamente los nuevos límites de confianza, los mecanismos de gestión del estado y los modelos de ejecución introducidos por la especificación.
Para proteger adecuadamente estas nuevas superficies de ataque, los equipos de seguridad deben tratar todos los datos y metadatos de estado proporcionados por el cliente como entradas no fiables, mediante la aplicación de una verificación criptográfica estricta, la codificación de salida para los paneles visuales generados por IA y cuotas de recursos sólidas para las tareas asíncronas.
Para afrontar este cambio, se necesita una arquitectura de defensa proactiva que bloquee los ataques antes de que lleguen a la infraestructura de back-end.
actúe ahora
Akamai permite a las organizaciones actuar desde ahora. Al aprovechar nuestra plataforma existente de seguridad del Edge, las API y las aplicaciones, y ampliarla con inteligencia específica para MCP, ayudamos a los equipos a identificar dónde está surgiendo MCP, aplicar medidas de protección prácticas durante las fases de experimentación y gestionar el riesgo a medida que aumenta la exposición.
Este enfoque permite a las organizaciones adoptar MCP hoy mismo y confiar en Akamai para seguir evolucionando la protección, la visibilidad y el control a medida que se amplía el uso de MCP.
Etiquetas
