MCP Security: proteger el Model Context Protocol

El Model Context Protocol conecta aplicaciones de IA con herramientas, fuentes de datos y APIs a través de una interfaz unificada; los servidores MCP actúan como puente, a menudo con permisos de usuario delegados. La integración dinámica de herramientas en tiempo de ejecución, las relaciones de confianza implícitas entre componentes y los contextos compartidos crean rutas de ataque que la seguridad clásica de APIs no cubre. A esto se añade que el protocolo no define ni un control de acceso obligatorio ni una gestión del ciclo de vida de los Tokens: la implementación segura recae por completo en los implementadores.

Entre los riesgos centrales se encuentran el Tool Poisoning (instrucciones ocultas en las descripciones de herramientas), los Rug Pulls (sustitución posterior de definiciones de herramientas ya aprobadas) y la inyección de código a través de entradas del modelo transmitidas sin verificación. El Token Passthrough genera un riesgo de Confused Deputy: el servidor MCP es utilizado de forma abusiva para ejecutar acciones no autorizadas con permisos de usuario ajenos; las claves de API y los Tokens de OAuth almacenados de forma insegura permiten el robo de credenciales. Incidentes reales — desde la exfiltración de repositorios privados de GitHub y la fuga de mensajes de WhatsApp hasta la vulnerabilidad RCE CVE-2025-49596 en el MCP Inspector — demuestran que estos ataques funcionan en la práctica.

La guía de OWASP exige OAuth 2.1/OIDC para todos los servidores MCP remotos, Tokens de corta duración y con alcance restringido, así como la validación de esquemas de todas las entradas y salidas. Los usuarios y las sesiones deben aislarse estrictamente; la ejecución de herramientas debe realizarse en sandboxes endurecidos (contenedores, seccomp/AppArmor) con permisos mínimos y una red segmentada. Los secretos se almacenan en vaults y no deben ser accesibles para el LLM en ningún momento.

Wiz Research recomienda utilizar únicamente servidores MCP de fuentes de confianza y auditarlos antes de su uso como si fueran paquetes de software privilegiados; la instalación y la ejecución automáticas de herramientas son patrones de alto riesgo. Un cliente MCP maduro con diálogos de aprobación, gestión de permisos y Human-in-the-Loop para acciones críticas limita el daño causado por servidores comprometidos. Un MCP-Gateway central y el Allowlisting en el host concentran el registro de auditoría, los guardrails y la aplicación de políticas en un único punto de control.

Todas las llamadas a herramientas y al modelo deberían registrarse — incluidos los parámetros y las identidades implicadas — e integrarse en los pipelines de SIEM y de detección existentes. La NSA recomienda además escanear la propia red con regularidad en busca de servidores MCP no autenticados, vulnerables o no aprobados; dado que los servidores MCP pueden cambiar de puerto de forma dinámica, resultan útiles los escaneos periódicos con informes de diferencias. De forma complementaria, un proceso formal de seguimiento de las vulnerabilidades relacionadas con MCP (CVEs, avisos de fabricantes) debe formar parte de la operación regular.

Ninguna herramienta ni ningún cambio en una herramienta debería pasar a producción sin un proceso formal de aprobación: el escaneo de código (SAST), el análisis de dependencias (SCA) y la revisión manual de seguridad son obligatorios. Los manifiestos de herramientas firmados con fijación de versiones garantizan la integridad; la funcionalidad anunciada en la descripción de una herramienta debe validarse frente al comportamiento real en tiempo de ejecución. Un inventario actualizado de todos los servidores y herramientas MCP en uso, con versiones e historial de parches, acelera el triaje y la respuesta cuando se conocen nuevas vulnerabilidades.