Cloudflare anunció nuevas capacidades de Cloudflare One para identificar tráfico del Model Context Protocol (MCP), mostrar qué usuarios y servidores lo generan y bloquear conexiones directas que no pasan por rutas aprobadas. La noticia no describe una vulnerabilidad específica ni un ataque activo; apunta a un problema operativo que crece con los agentes de IA: las herramientas que antes ejecutaba una persona ahora pueden invocarse de forma automática, rápida y repetida.

Qué anunció Cloudflare

La publicación oficial, fechada el 14 de agosto, explica que Cloudflare Gateway comenzará a clasificar solicitudes MCP inspeccionadas usando señales del protocolo, en vez de depender solo de nombres de host o rutas como “/mcp”. Según Cloudflare, los administradores podrán ver indicios de tráfico MCP en los registros HTTP de Gateway y usar un nuevo selector booleano, `experimental.is_mcp == true`, para permitir o bloquear esas conexiones cuando el tráfico atraviese rutas gestionadas y con inspección TLS.

MCP se ha convertido en una pieza común para conectar agentes de IA con herramientas externas: repositorios, sistemas internos, SaaS, bases de datos o APIs. Esa facilidad es precisamente el riesgo. Un empleado puede configurar Claude Code, Codex, Cursor, VS Code u otro cliente para conectarse a un servidor MCP con muy poca fricción. Si la organización no ve esa conexión, tampoco sabe qué herramientas quedan expuestas ni qué datos viajan dentro de los argumentos enviados al servidor.

El problema de “shadow MCP”

Cloudflare distingue dos situaciones. La primera es “shadow MCP”: conexiones a servidores que la organización no aprobó. La segunda es el bypass de portales: un servidor sí fue aprobado, pero el usuario evita el portal gestionado y conecta directo al endpoint original, saltándose políticas de acceso, catálogo curado de herramientas, auditoría y controles de pérdida de datos.

El nuevo enfoque usa señales como el encabezado `MCP-Protocol-Version` y, en la especificación MCP 2026-07-28, encabezados como `Mcp-Method` y `Mcp-Name`, que facilitan identificar una operación sin leer todo el cuerpo de la solicitud. Cloudflare advierte un límite importante: la ausencia de esos encabezados no prueba que no sea MCP. Clientes antiguos, tráfico local por `stdio`, conexiones fuera de la red gestionada o rutas marcadas como “Do Not Inspect” pueden quedar fuera de la visibilidad.

Qué cambia para empresas

Para equipos de seguridad y plataforma, la novedad no es solo un panel más. Es una forma de convertir tráfico desconocido de agentes en una lista investigable: qué servidores aparecen, qué usuarios los usan, cuántas solicitudes generan y si pasan por un MCP Portal o por una conexión directa. Con esa información, la empresa puede decidir qué servidores aprobar, moverlos detrás de un portal, aplicar identidad mediante Cloudflare Access, registrar actividad y bloquear conexiones detectadas que no lleguen por el camino aprobado.

Cloudflare también dice que sus MCP Portals ahora soportan clientes OAuth pre-registrados, una mejora pensada para proveedores que no usan registro dinámico. Además, la compañía trabaja en permitir que los portales alcancen servidores MCP privados mediante rutas de Cloudflare Gateway, algo relevante porque muchas herramientas empresariales no están expuestas públicamente.

La lectura editorial

La señal de fondo es clara: la seguridad de agentes de IA empieza a parecerse menos a “proteger un chatbot” y más a gobernar tráfico de aplicaciones automatizadas. Si un agente puede invocar herramientas que modifican infraestructura, consultan datos de clientes o crean tickets, la pregunta crítica pasa a ser quién autorizó ese servidor, qué herramienta se llamó, con qué argumentos y por qué ruta salió la solicitud.

Lo confirmado es el anuncio de Cloudflare, la documentación pública de detección de tráfico MCP y la documentación de MCP Portals. Lo que no queda demostrado por esas fuentes es eficacia independiente en entornos heterogéneos, cobertura sobre clientes no conformes o protección de servidores locales. Por eso conviene leerlo como un avance práctico en visibilidad y gobernanza, no como una solución completa para todos los riesgos de agentes.

Fuentes consultadas: Cloudflare Blog y documentación oficial de Cloudflare One.

Redactado por Lía Torres — Perspectiva social y estratégica.