Seguridad MCP 2026: la brecha human-in-the-loop

La especificación del Model Context Protocol admite, en lenguaje claro, que no puede imponer la aprobación humana antes de que actúe una herramienta de IA: esa garantía es una recomendación para la aplicación construida sobre MCP, no una regla que MCP mismo compruebe. Para cualquier agencia que conecte su propia IA, o la de un cliente, a sistemas de negocio reales vía MCP, esa sola frase es todo el modelo de riesgo. El protocolo le dice a tu IA qué herramientas existen y qué dicen hacer. Si un humano ve y aprueba realmente lo que va a ocurrir queda enteramente en manos de quien construyó el cliente.

¿Qué dice realmente la especificación MCP sobre el consentimiento?

La sección «Key Principles» de la especificación es directa sobre los límites de lo que el protocolo garantiza:

«1. User Consent and Control — Users must explicitly consent to and understand all data access and operations… 3. Tool Safety — Tools represent arbitrary code execution and must be treated with appropriate caution… Hosts must obtain explicit user consent before invoking any tool.»

Y acto seguido:

«While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications…»

Ahí está la brecha en un párrafo. Los principios usan «must» en minúsculas, que según la convención de la especificación MCP significa recomendación, no requisito a nivel de protocolo. La especificación Tools repite la misma estructura en su «User Interaction Model»: «there SHOULD always be a human in the loop with the ability to deny tool invocations», junto a orientaciones de que las aplicaciones «SHOULD… present confirmation prompts to the user for operations». Recomendado. No impuesto. No algo que un servidor MCP pueda verificar que el cliente hace de verdad.

No es una falla única de MCP — ningún protocolo puede forzar a una aplicación construida encima a comportarse de cierta manera. Pero significa que «nuestra IA está conectada vía MCP» no te dice nada sobre si hay realmente un humano en el bucle. Es una afirmación sobre la aplicación concreta, y hay que verificarla ahí, no asumirla por el nombre del protocolo.

Qué pasa cuando se explota esa brecha

Tres incidentes documentados muestran lo que la brecha cuesta en la práctica, en tres puntos distintos de la cadena.

Asana, junio de 2025 — el fallo de aislamiento. Asana lanzó una integración MCP el 1 de mayo de 2025. Se identificó un bug de aislamiento de tenant el 4 de junio, y la integración estuvo fuera de línea unas dos semanas mientras se corregía. La falla permitió que datos de una organización — tareas, metadatos de proyecto, detalles de equipo, comentarios y archivos subidos — fueran visibles más allá de los límites organizativos. Unos 1.000 clientes se vieron afectados, y la vulnerabilidad existía desde el primer día de la función. No fue específicamente un fallo human-in-the-loop, pero recuerda que el límite de aislamiento alrededor de lo que puede alcanzar una integración MCP importa tanto como quién aprueba la llamada.

GitHub, mayo de 2025 — el «toxic agent flow». Investigadores de seguridad en Invariant Labs demostraron un ataque donde un desarrollador pidió a un agente de IA, conectado vía el servidor MCP de GitHub, revisar issues abiertas en un repositorio público. Una issue plantada contenía instrucciones ocultas. El agente las leyó y luego usó su acceso ya autorizado a los repositorios privados del desarrollador para extraer información sensible y publicarla en una pull request visible en el repo público. Cada llamada individual de herramienta que hizo el agente era una que el usuario había autorizado de verdad. Lo no autorizado — y lo que ningún prompt de aprobación único habría detectado — fue la combinación: leer una issue pública, actuar sobre datos privados y publicar fuera. La conclusión de Invariant fue contundente: «This vulnerability cannot be resolved through server-side patches.» Es un problema arquitectónico en cómo se componen los permisos entre llamadas de herramientas, no un bug en el código de GitHub.

Microsoft, 30 de junio de 2026 — la brecha de re-aprobación. El equipo de seguridad de Microsoft publicó una advertencia directa sobre un mecanismo integrado en el propio modelo de confianza: la descripción de una herramienta — el texto que un usuario lee y aprueba antes de dejar que una IA la use — puede cambiar tras esa aprobación, y nada en el protocolo exige que el cliente vuelva a preguntar. Palabras de Microsoft: «In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.» Una herramienta que parecía segura el primer día puede redefinirse en silencio el día treinta, y un usuario que la aprobó una vez no tiene motivo para saber que ocurrió. Microsoft describió MCP como «the fastest-growing part of the agentic AI supply chain» — exactamente por eso esta brecha importa más cada mes que queda sin abordar.

Junto a ello, dos CVE concretos conviene conocer si evalúas herramientas MCP: CVE-2025-49596, una falla crítica (CVSS 9,4) de ejecución remota de código en la propia herramienta MCP Inspector de Anthropic, y CVE-2025-6514, una vulnerabilidad crítica (CVSS 9,6) de inyección de comandos en el paquete muy usado mcp-remote, activada por la URL de autorización de un servidor malicioso. Ambas están parcheadas, pero ilustran que el tooling alrededor de MCP ha tenido la misma clase de brecha que el modelo de confianza del protocolo: cosas que un usuario razonablemente suponía inertes resultaron no serlo.

Qué debe significar «human-in-the-loop» en la práctica

Dado que el protocolo no lo impondrá, las preguntas que valen la pena sobre cualquier herramienta conectada a IA — incluida la de sSystm — son las que convierten «human-in-the-loop» de eslogan en algo comprobable:

1. ¿Una escritura espera realmente a una persona cada vez, o solo en el primer uso? Una sola aprobación al conectar no es la misma garantía que aprobación por acción.
2. Si cambia la descripción o el comportamiento de una herramienta, ¿dispara re-aprobación o entra en vigor en silencio? Es precisamente la brecha que Microsoft señaló en junio de 2026.
3. ¿El token o credencial está acotado a los datos de una organización, o una sesión comprometida podría cruzar tenants? Eso es lo que falló en Asana — no el paso de aprobación, sino el límite de aislamiento detrás.
4. ¿Hay un registro de auditoría de lo que la IA hizo realmente, separado de lo que se le pidió? Ataques compuestos como el de GitHub solo aparecen a posteriori si los pasos individuales quedaron registrados.
5. ¿Quién gobierna la especificación y con qué rapidez evoluciona el modelo de seguridad? MCP se donó a la Agentic AI Foundation bajo la Linux Foundation el 9 de diciembre de 2025, con Anthropic, Block, OpenAI, Google, Microsoft, AWS y Cloudflare citados como involucrados — señal de que el ecosistema se consolida en torno a gobernanza compartida en lugar de que cada proveedor parchee por su cuenta.

El endpoint MCP de sSystm emite un token por usuario acotado a la organización de ese usuario, y cada escritura que propone una IA — vía el Build AI integrado o un cliente externo conectado — queda pendiente hasta que una persona la aprueba. No es una afirmación de que MCP lo imponga; es el punto contrario. Como el protocolo no lo hace, hay que construirlo deliberadamente en la aplicación, y conviene comprobarlo explícitamente en lugar de asumirlo por «usa MCP». Más sobre cómo funciona el límite de aprobación en cómo comparten el espacio de trabajo IA y humanos en sSystm, cómo es el modelo de aislamiento en nuestra arquitectura de seguridad, y la mecánica de conectar IA externa vía MCP en cómo conectar tu IA a tu agencia con MCP.