Ciberseguridad

Cloudflare ya detecta tráfico MCP: cómo localizar shadow MCP y bloquear accesos directos

Publicado el 31/08/2026 Análisis y guía práctica en su-ip.es

Cloudflare añade detección de tráfico MCP en Gateway y un panel AI security para localizar shadow MCP y bloquear conexiones directas fuera de portal.

Cloudflare anunció el 14 de agosto de 2026 nuevas capacidades para detectar tráfico MCP y el cambio importante no es solo que la sigla esté de moda. Lo que aparece aquí es una respuesta bastante práctica a un problema real: los agentes de IA pueden conectarse a herramientas y datos externos a gran velocidad, y muchas organizaciones no tienen hoy visibilidad suficiente sobre ese tráfico.

La pregunta útil para una empresa no es si MCP suena moderno, sino cómo localizar servidores MCP no aprobados, diferenciar tráfico legítimo del que se salta el camino gobernado y aplicar una política simple sin romper el trabajo válido. En ese terreno, Cloudflare ha dado un paso interesante: añade señales específicas para identificar MCP en Gateway y cruzarlas con MCP portals dentro de Cloudflare One.

Resumen rápido: qué ha pasado y qué conviene hacer

12 de agosto de 2026: el changelog de Cloudflare activa detección automática de tráfico MCP en Gateway.
14 de agosto de 2026: Cloudflare explica el cambio en detalle y lo conecta con el panel de seguridad para IA y los MCP server portals.
La nueva señal clave es experimental.is_mcp == true dentro de las HTTP policies de Gateway.
El panel AI security permite ver volumen de peticiones MCP, usuarios y servidores observados.
La política base más razonable hoy es detectar MCP, revisar qué tráfico va fuera de portal y bloquear solo el que no pase por un MCP portal aprobado.
Conviene recordar un límite importante: esta visibilidad depende de tráfico inspeccionado con TLS decryption; servidores stdio, tráfico fuera de red o conexiones no inspeccionadas quedan fuera.

Qué ha anunciado Cloudflare exactamente

Según el anuncio oficial de Cloudflare, Gateway ahora puede identificar tráfico MCP inspeccionado usando señales de protocolo, mostrar qué usuarios y servidores lo generan y ayudar a distinguir entre servidores MCP aprobados que pasan por portal y conexiones directas o shadow MCP. La idea no es inspeccionar “IA” de forma genérica, sino reconocer un tipo concreto de tráfico que un agente usa para invocar herramientas y acceder a recursos.

Cloudflare también lo aterriza con un ejemplo operativo bastante claro: un empleado puede conectar Codex, Claude Code, Cursor o VS Code a un servidor MCP con una configuración mínima y sin pasar por el circuito aprobado por seguridad. Si ese tráfico parece una llamada HTTPS cualquiera, la organización puede quedarse sin inventario, sin control de ruta y sin rastro útil sobre qué herramientas se están usando.

Equipo de seguridad revisando flujos de agentes de IA y conexiones a herramientas externas en un centro de operaciones moderno — El problema práctico de MCP no es teórico: cuando un agente puede llamar herramientas externas, la velocidad de una mala decisión también sube.

Por qué shadow MCP se ha vuelto una preocupación real

Cloudflare separa bien dos escenarios que conviene no mezclar. El primero es shadow MCP: un usuario conecta un cliente a un servidor que la empresa no ha aprobado. El segundo es portal bypass: el servidor sí está aprobado, pero alguien se conecta a la URL directa y se salta el portal, sus políticas de acceso, su catálogo curado de herramientas o sus registros.

Ese matiz importa bastante porque la respuesta no es la misma. Un shadow MCP pide descubrimiento, inventario y decisión. Un portal bypass pide enforcement. Cloudflare plantea justo esa ruta: primero detectar, luego decidir qué servidor aprobar y, por último, mover el uso aprobado detrás de un portal para que el tráfico legítimo tenga un camino gobernado.

Qué señales nuevas puedes usar hoy en Cloudflare One

La pieza más accionable del cambio está en las HTTP policies de Gateway. Cloudflare ha añadido el selector experimental.is_mcp, que marca como MCP el tráfico que Gateway consigue reconocer por headers y características del protocolo. La documentación lo deja bastante claro: ese selector puede usarse en políticas de allow, block o isolate.

Además, el changelog oficial muestra una política base muy fácil de entender: bloquear el tráfico MCP que no llegue a través de un MCP portal. En el anuncio largo, Cloudflare lo expresa como:

experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")
Action: Block

Eso no significa que debas bloquear a ciegas desde el minuto uno. Lo sensato suele ser empezar por observación: revisar usuarios, hosts y volumen en el panel AI security y confirmar qué parte del tráfico corresponde a servidores aprobados, qué parte es experimento interno controlado y qué parte sí parece desvío no gobernado.

Qué hacer hoy si administras seguridad de red o Zero Trust

Comprueba si tu tráfico pasa por Gateway con inspección TLS, porque sin esa capa la detección no verá todo lo que promete el anuncio.
Revisa el panel AI security para identificar servidores MCP observados, volumen y usuarios más activos.
Haz un inventario corto de servidores aprobados, piloto y no aprobados antes de crear reglas duras.
Coloca los servidores válidos detrás de MCP portals cuando tenga sentido, para sumar Access, catálogo curado y trazabilidad.
Empieza con una política de bloqueo acotada para MCP que no llegue desde portal, idealmente tras una fase breve de observación.
Define una excepción temporal clara para equipos que estén probando integraciones legítimas y todavía no hayan migrado a portal.

Si te interesa este tipo de seguridad aplicada y no solo el titular, este artículo enlaza bastante bien con nuestra pieza sobre Certificate Transparency Monitoring de Cloudflare y con el análisis de cómo Cloudflare separa bots de IA entre Search, Agent y Training, porque las tres noticias apuntan al mismo fondo: más visibilidad y más control sobre tráfico automatizado.

Administrador de seguridad definiendo una política para bloquear tráfico MCP directo y permitir solo accesos por portal aprobado — La política mínima útil no consiste en prohibir la IA, sino en distinguir el camino aprobado del que se ha montado por fuera.

Límites importantes que no conviene exagerar

Cloudflare también deja por escrito los límites. La detección depende de tráfico inspeccionado y no cubre igual los servidores stdio, conexiones fuera de la red gestionada, tráfico marcado como Do Not Inspect o cualquier petición que no atraviese Gateway. Dicho de forma simple: esto mejora mucho la visibilidad en red, pero no sustituye tu gobierno de endpoints, tu política de clientes aprobados ni tu inventario interno de herramientas.

Tampoco conviene vender MCP como si todo uso fuese automáticamente peligroso. Hay usos totalmente razonables y útiles. El punto de Cloudflare no es “bloquea agentes”, sino algo más fino: descubre qué están haciendo, decide qué apruebas y obliga a que lo aprobado pase por el camino correcto.

Preguntas rápidas

Qué es la señal `experimental.is_mcp`?

Es un selector nuevo de Cloudflare Gateway para HTTP policies que marca tráfico identificado como MCP. Según la documentación, puede usarse para permitir, bloquear o aislar ese tráfico.

Detecta cualquier uso de MCP en cualquier contexto?

No. Cloudflare aclara que depende de tráfico inspeccionado y que hay escenarios fuera de vista, como servidores stdio o conexiones que no pasan por Gateway.

Qué diferencia hay entre shadow MCP y portal bypass?

Shadow MCP es usar un servidor no aprobado. Portal bypass es usar uno aprobado pero conectando a su URL directa en vez de pasar por el MCP portal gobernado.

Cuál es la política base más fácil de entender?

Bloquear tráfico MCP que no llegue a través de un MCP portal aprobado. El changelog y la documentación de Cloudflare lo muestran como ejemplo directo.

Fuentes oficiales

Conclusión

Cloudflare ha puesto nombre, señal y política a un problema que ya estaba creciendo dentro de muchas empresas: agentes con acceso a herramientas externas sin inventario ni camino gobernado. La novedad no resuelve sola toda la seguridad de la IA, pero sí añade una base operativa mucho más útil para verla y contenerla.

Si tu organización ya experimenta con MCP, lo razonable no es esperar a que aparezca un incidente para ordenar el panorama. Detectar primero, aprobar después y bloquear el acceso directo fuera de portal parece hoy una de las formas más sensatas de empezar.