Cloudflare ha publicado un modelo de amenaza de grado productivo y una arquitectura de políticas para el tráfico del Model Context Protocol, cubriendo detección, aplicación de identidad, bloqueo de prompt injection y prevención de movimiento lateral en tres superficies de control. El anuncio llega cuando la adopción de MCP se ha expandido más allá de los equipos de ingeniería de Cloudflare hacia producto, ventas, marketing y finanzas.

El riesgo central es la velocidad sin límites. Un ingeniero humano implementando en producción o consultando una base de datos sensible está restringido por el juicio humano y el ritmo humano. Un agente de IA no. Una decisión incorrecta puede replicarse en miles de acciones incorrectas antes de que alguien lo note. MCP amplifica esto porque una única línea de configuración conecta un agente a un servidor de herramientas, y el tráfico resultante no tiene una firma de red obvia — MCP no usa un hostname garantizado y no requiere /mcp en la ruta.

La arquitectura de Cloudflare define tres puntos de intervención. Primero: dentro del cliente MCP, un hook que se dispara después de que el modelo selecciona una herramienta puede denegar servidores no aprobados, eliminar argumentos sensibles o solicitar confirmación humana. Este es el intercept más temprano y el único plano que ve servidores MCP stdio locales que no generan tráfico de red. La limitación es la estandarización — los controles deben reproducirse en cada cliente que usan los empleados. Segundo: Cloudflare Gateway inspecciona el tráfego HTTP después de dejar el dispositivo. Con desencriptación TLS, Gateway correlaciona solicitudes a usuarios y dispositivos, aplica políticas DLP y bloquea conexiones directas a servidores no aprobados. Tercero: el propio servidor. AI Security for Apps de Cloudflare dentro del WAF inspecciona el tráfego MCP entrante en busca de prompt injection, fuga de datos sensibles y violaciones temáticas.

La detección de Shadow MCP es la nueva pieza operacionalmente interesante. Cloudflare Gateway ejecuta escaneos multicapa para exponer servidores MCP remotos a los que los empleados están accediendo fuera de portales aprobados. Las capas de detección incluyen coincidencia de hostname para servidores conocidos como mcp.stripe.com, patrones de subdominio comodín, patrones de ruta (/mcp, /mcp/sse) e inspección de cuerpo DLP que escanea payloads POST en busca de marcadores JSON-RPC como "method": "tools/call". El escaneo de cuerpo DLP tiene un límite máximo: solo los primeros 1.024 bytes del cuerpo POST, usando sintaxis regex de Rust.

El enrutamiento de tráfico a través de MCP Server Portals agrega aplicación. Cuando se habilita el enrutamiento Gateway, cada llamada de herramienta desde el portal se proxifica a través de Gateway antes de llegar al servidor upstream. Dos limitaciones: el enrutamiento Gateway solo soporta transporte Streamable HTTP, por lo que los servidores que usan endpoints SSE (/sse) fallarán. La sincronización de herramientas y prompts en background — ejecutándose cada dos horas con credenciales de admin — no se enruta a través de Gateway, creando un punto ciego de visibilidad.

Los incidentes reales ilustran lo que este marco defiende. En junio de 2025, la integración MCP de una herramienta de colaboración en equipo filtró datos de clientes entre instancias, forzando una interrupción de dos semanas. CVE-2025-6514 afectó a un paquete npm ampliamente utilizado para autenticación MCP. La investigación NeighborJack encontró cientos de servidores MCP vinculados a 0.0.0.0 sin reglas de firewall, abiertos a inyección de comandos OS y takeover de host. Un ataque confused deputy documentado vio a un agente con privilegios de alto nivel ejecutar comandos SQL incrustados en un ticket de soporte, comprometiendo una base de datos completa.

La detección de shadow basada en Gateway más el enrutamiento reforzado por Portal proporciona la cobertura más amplia a nivel de red. Pero el límite de escaneo DLP de 1.024 bytes, la restricción de transporte SSE-a-Streamable-HTTP y la brecha de sincronización en background significan que la detección perimetral es necesaria pero no suficiente — las reglas WAF del lado del servidor y los hooks del lado del cliente tienen peso independiente.