El modelo de confianza de MCP permitió que un agente envenenado llegara a otro

El protocolo que se convirtió en la forma predeterminada de conectar agentes de IA tiene un problema de confianza, y vale la pena entender su forma antes del próximo incidente.

Ars Technica informó el 5 de octubre que un investigador independiente, Syed Anas Mohiuddin, demostró una clase de ataque que llama «protocol pivoting» (pivoting de protocolo). La idea es sencilla. Dentro de una red, los agentes hablan entre sí mediante el Model Context Protocol, o MCP. Las barreras de protección son más débiles en el punto en que un agente entrega una tarea a otro, porque el segundo agente confía en el primero de forma predeterminada. Introduce una instrucción maliciosa en un agente de traducción o de análisis de datos que carezca de validación estricta de entradas, y este la transmitirá hacia abajo. El receptor obedece, porque ¿por qué iba a mentir un colega de confianza?

La prueba de concepto de Mohiuddin llegó a cinco organizaciones no relacionadas: Google, JPMorgan Chase, Weviate, Rapid7, la dirección interministerial de asuntos digitales de Francia y una agencia federal de EE. UU. Esas organizaciones comparten poco excepto el uso intensivo de agentes. Ese es el punto. La debilidad está en la fontanería, no en un producto concreto.

Dos CVE y una disparidad de puntuación

Los errores concretos son ordinarios, lo cual es parte de lo que hace incómoda la historia. El servidor MCP de Rapid7 conlleva CVE-2026-97228, que la empresa corrigió en septiembre de 2026 aunque la falla puntuó 2,7 sobre 10. El problema de Google obtuvo una puntuación más alta, un 8, y afectó a googleapis/mcp-toolbox. Su cliente HTTP carecía de una política CheckRedirect y de validación de IP de destino, por lo que un parámetro de ruta manipulado podía redirigir una solicitud hacia un endpoint interno. Google añadió listas de permitidos y bloqueados de IP e hizo que la caja de herramientas rechazara URL base inseguras al iniciarse.

La discrepancia en las puntuaciones de gravedad es una lección en sí misma. Dos organizaciones encontraron debilidades comparables en el mismo protocolo y las calificaron de forma muy distinta, lo que sugiere que la industria no ha decidido cuánto debería costar una brecha de confianza entre agentes.

No todos aceptan «protocol pivoting» como una categoría nueva. Markus Vervier, investigador de X41 D-Sec, declaró a Ars Technica que él lo interpreta como inyección indirecta de prompts, la misma técnica que los equipos de seguridad llevan dos años siguiendo. Ese encuadre es justo, y también agudiza el problema práctico: el manual defensivo para la inyección de prompts supone que la entrada llega desde fuera. Aquí llega desde dentro, con una credencial interna.

La brecha es arquitectónica, no un parche

Un informe aparte del proveedor de seguridad ClawSecure lleva el análisis una capa más profundo. Sus investigadores probaron Linear, Notion y Dropbox Dash y sostienen que la falla está en la especificación de MCP, no en la implementación de ningún proveedor. En Notion y Linear encontraron servidores MCP que obtienen automáticamente enlaces controlados por el atacante en el momento en que se crea contenido, sin ningún modelo en el bucle. Cualquiera con acceso de escritura a un espacio de trabajo puede convertirlo en un canal de filtración, evitando la necesidad de un prompt hábilmente redactado.

Sus cifras son contundentes. De 20 técnicas de ofuscación, incluidas Unicode de ancho cero y homoglifos, 17 sobrevivieron al recorrido completo. En 14 modelos de cinco laboratorios, ninguno bloqueó las amenazas de forma consistente; el mejor, Claude Opus 4.7, siguió instrucciones maliciosas alrededor del 26,7 % de las veces.

ClawSecure vende productos de seguridad y el informe no ha sido replicado de forma independiente, así que trata con la cautela adecuada la afirmación sobre la capa de plataforma. Sin embargo, las condiciones subyacentes son fáciles de verificar. MCP registra más de 500 millones de descargas mensuales del SDK y cerca de 16.000 servidores públicos, y según un recuento solo el 8,5 % de esos servidores usa OAuth. La adopción avanzó más rápido que el endurecimiento.

AWS ofreció su propia evidencia en un boletín publicado el 2 de octubre. Tres fallas en su plataforma de orquestación de agentes de código abierto Loom podrían permitir la toma de control administrativo sin autenticación, la divulgación de credenciales OAuth2 y el acceso a servicios internos. La más grave, CVE-2026-103956, permitía a cualquier cliente de red alcanzar el plano de control de agentes en implementaciones sin un proveedor de identidad configurado. Las versiones 1.6.1 y 1.7.0 de Loom cierran esas brechas.

Por qué el supuesto de confianza predeterminado es el verdadero hallazgo

Deja a un lado los CVE y una decisión de diseño destaca. Los agentes están construidos para cooperar, así que se autentican entre sí y luego actúan como si una credencial válida también significara una solicitud válida. La confianza cero clásica dice lo contrario: demostrar cada solicitud por sus propios méritos, incluso desde dentro del perímetro.

Los ataques de Mohiuddin funcionan explotando esa inversión. La instrucción maliciosa franquea la frontera de autorización entre sistemas precisamente porque nunca cruza una frontera en el código. Se mueve de agente a agente dentro de un mismo tejido de confianza, y no queda ninguna capa que pregunte si la solicitud tenía sentido.

Qué pueden hacer los equipos esta semana

Las correcciones inmediatas son poco glamurosas y ya están disponibles. Trata cualquier instrucción que llegue de un modelo de lenguaje como entrada hostil, sin importar qué agente la produjo. Aplica un manejo estricto de redirecciones y valida las IP de destino. Exige autenticación por agente antes de que un agente delegue en otro, y registra la delegación para poder reconstruir una cadena de traspasos a posteriori.

A más largo plazo, cabe esperar que los organismos de normalización codifiquen el protocol pivoting como una clase de amenaza con nombre propio, lo que empujaría a los proveedores a incluir comprobaciones de confianza cero dentro de MCP en lugar de al lado. Los auditores seguirán, y las preguntas sobre las barreras entre agentes empezarán a aparecer en las revisiones de cumplimiento como lo hicieron las reglas de firewall una generación atrás.

La parte incómoda de esta historia es que el truco funciona mejor cuando los agentes confían unos en otros. Cada organización que se apresura a conectar sus herramientas mediante MCP está construyendo ese tejido de confianza ahora mismo, y la mayor parte se está levantando sin un plan para lo que ocurre cuando un miembro del equipo resulta estar mintiendo.

Por qué esto llegó ahora

Ninguna de las técnicas subyacentes es nueva. La falsificación de solicitudes del lado del servidor y los errores de inyección llevan años en la lista de OWASP. Lo que cambió es dónde se ejecutan. Los agentes dieron a esos viejos errores una nueva vía de entrega, porque un agente actuará encantado ante una frase en un documento, un campo en una fila de base de datos o una línea en la salida de otro agente. La instrucción no necesita ser escrita por un atacante. Solo necesita acabar en algún lugar que el modelo lea.

Por eso la divulgación abarca un banco, un motor de búsqueda, un proveedor de seguridad y una dirección gubernamental. No compartían código ni proveedor. Compartían una arquitectura, y la arquitectura conlleva el supuesto de que todos los participantes son dignos de confianza. MCP pasó de ser una idea novedosa a infraestructura crítica en aproximadamente un año, con descargas medidas en cientos de millones al mes, y la revisión de seguridad que normalmente acompañaría ese crecimiento en su mayoría no ha ocurrido.

Hay una versión de esta historia que termina bien. Los errores se están corrigiendo, los responsables del protocolo responden, y los ataques requieren acceso de escritura o un punto de apoyo dentro de la red, lo cual es un umbral significativo. Pero la corrección que importa es cultural más que técnica. Los equipos que adoptan agentes deben dejar de tratar una credencial interna válida como prueba de que una solicitud es legítima, y empezar a validar cada solicitud como si viniera de un desconocido. Ese es un cambio más difícil de implementar que cualquier parche, y es el que pondrá a prueba la próxima ronda de incidentes.