Cloudflare: cómo la detección de MCP convierte el tráfico de agentes en la sombra en una decisión de seguridad

Cloudflare ha ampliado la detección de tráfico MCP más allá de los nombres de servidor evidentes, exponiendo un conflicto que los equipos de seguridad antes podían pasar por alto. La pregunta sobre cómo funciona Cloudflare empieza ahora con evidencia del protocolo, no con una lista de dominios conocidos. Gateway puede inspeccionar el tráfico HTTP gestionado en busca de rutas específicas de MCP y métodos JSON-RPC, y luego distinguir el tráfico aprobado a través de Portal de las conexiones directas.

Esta distinción importa porque Model Context Protocol, o MCP, permite que los agentes de IA llamen a herramientas externas y recuperen datos privados. Una sola conexión podría alcanzar código fuente, registros de clientes, controles en la nube o sistemas de mensajería. Cuando los empleados configuran servidores remotos sin revisión, la actividad MCP en la sombra resultante se parece al shadow IT, pero con un agente capaz de realizar acciones.

La respuesta de Cloudflare combina descubrimiento con una vía de aplicación. Gateway proporciona la señal de red, mientras que los portales de servidores MCP centralizan los servidores aprobados detrás de un único endpoint. Las políticas de Access rigen las condiciones de identidad y dispositivo, y la prevención de pérdida de datos, o DLP, puede inspeccionar las solicitudes y respuestas de las herramientas. La cuestión sin resolver es si las organizaciones pueden enrutar suficiente tráfico a través de esos controles para que el modelo sea fiable.

Cómo la detección de MCP de Cloudflare interpreta el protocolo

El cambio importante de Cloudflare es pasar de adivinar destinos a reconocer el comportamiento de MCP dentro del tráfico HTTP inspeccionado.

El método de detección más sencillo observa el nombre de host de destino. Un administrador puede buscar en los registros de Gateway endpoints MCP conocidos o nombres de host que contengan mcp. Este enfoque detecta servicios que anuncian su propósito mediante nombres como mcp.example.com.

Una segunda señal proviene de la URI de la solicitud. Los servidores remotos suelen exponer rutas como /mcp, /sse o /mcp/sse. Gateway puede buscar estas pautas en las solicitudes registradas incluso cuando el propio nombre de host parece genérico.

Ambos métodos son útiles para un inventario inicial, pero ninguno demuestra que una solicitud transporte MCP. Una aplicación normal puede usar la misma ruta. Un servidor MCP también puede ocultarse detrás de un nombre de host común y una ruta de API poco llamativa.

Por ello, Cloudflare orienta a los administradores hacia la inspección del cuerpo. MCP codifica mensajes mediante JSON-RPC, un formato de solicitud estructurado que contiene campos como jsonrpc, method y params. Los nombres de métodos estándar crean evidencia reconocible a nivel de protocolo.

Entre los ejemplos se incluyen initialize, tools/list, tools/call, resources/read y prompts/get. Un perfil DLP puede buscar esas cadenas en los cuerpos POST, incluso cuando el dominio y la ruta no revelan nada. Cloudflare publicó expresiones regulares de ejemplo en su arquitectura de MCP que cubren varios métodos comunes y campos de versión del protocolo.

El método initialize es especialmente útil porque inicia la relación entre un cliente MCP y un servidor. Un cliente declara su versión del protocolo, capacidades, nombre y versión. El servidor responde con sus propias capacidades y puede crear una sesión.

Las llamadas a herramientas producen una señal operativa más sólida. Una solicitud que contiene tools/call indica que el agente intenta invocar una capacidad, no solo comprobar si existe un endpoint. Los argumentos también pueden revelar qué datos o acción gestionará la herramienta.

Por tanto, el modelo de cómo funciona Cloudflare se organiza por capas:

• Los patrones de nombre de host identifican servidores MCP conocidos o con nombres explícitos.

• Los patrones de URI identifican endpoints MCP remotos convencionales.

• Los métodos JSON-RPC identifican comportamiento MCP en endpoints menos evidentes.

• Los campos de usuario y dispositivo vinculan ese comportamiento con una persona o sistema gestionado.

• Las acciones de Gateway muestran si la solicitud fue permitida, bloqueada o tratada de otro modo.

El flujo de trabajo documentado de Cloudflare utiliza el conjunto de datos gatewayHttpRequestsAdaptiveGroups en su API de GraphQL Analytics. Los administradores pueden agrupar los resultados por host, URI, usuario, acción y perfiles DLP coincidentes. Según el tutorial de detección de la empresa, el conjunto de datos admite hasta 30 días de consultas históricas.

Esto no es detección de amenazas consciente del contenido en su sentido más amplio. Una coincidencia con tools/call indica que se invocó una herramienta MCP. No determina si la herramienta es fiable, si sus instrucciones son maliciosas ni si la acción se ajusta a la intención del usuario.

Aun así, el reconocimiento del protocolo cierra una importante brecha de visibilidad. Un equipo de seguridad ya no necesita conocer cada proveedor o endpoint de MCP antes de iniciar una investigación. Puede buscar propiedades del propio protocolo.

Esto genera la tensión central del artículo. La detección puede revelar tráfico MCP directo, pero una señal por sí sola no establece qué conexiones deben seguir disponibles. Cloudflare necesita una alternativa gobernada antes de que un administrador pueda bloquear la ruta no gestionada sin detener el trabajo legítimo.

Shadow MCP sitúa a los equipos de seguridad entre el acceso y la adopción

La presión inmediata recae sobre los equipos de seguridad, que deben separar las conexiones de agentes útiles del acceso no revisado a sistemas sensibles.

MCP estandariza la forma en que una aplicación de IA descubre herramientas, lee recursos, recupera prompts e invoca acciones. El protocolo reduce el trabajo de integración personalizada, lo que también facilita que empleados y desarrolladores añadan servidores sin un proyecto central de despliegue.

Esa rapidez crea un problema de gobernanza conocido. Un usuario puede configurar un cliente MCP con la URL de un servidor remoto y conceder acceso mediante OAuth u otra credencial. El equipo de seguridad quizá nunca vea la configuración dentro de su catálogo de software aprobado.

El riesgo es mayor que una visita a una aplicación web no autorizada. Un servidor MCP expone herramientas a un agente, y esas herramientas pueden conllevar permisos significativos. Según la integración, podrían buscar documentos, leer repositorios, abrir registros de soporte, modificar infraestructura o enviar mensajes.

Una herramienta legítima aún puede recibir datos inapropiados. Un empleado podría pedir a un agente que analice un problema de un cliente y, sin saberlo, enviar información regulada a un servidor externo. Un servidor comprometido o engañoso también podría devolver instrucciones diseñadas para manipular el comportamiento posterior del agente.

Por eso Cloudflare describe las conexiones no gestionadas como shadow MCP. La cuestión definitoria no es si cada servidor desconocido es hostil. Es que la organización no ha revisado el servidor, su operador, los permisos que solicita ni los datos que fluyen a través de él.

Los registros de Gateway pueden convertir esa actividad desconocida en un inventario. Los administradores pueden identificar usuarios, hosts de destino, volúmenes de solicitudes, acciones de políticas y métodos del protocolo detectados. Después pueden investigar qué cliente generó el tráfico y qué finalidad empresarial cumple.

El inventario también permite una aplicación más mesurada. Un equipo podría registrar las coincidencias iniciales, revisar los destinos activos y clasificar cada servidor antes de bloquear nada. Los casos de alta confianza, como el tráfico directo hacia una herramienta remota no aprobada, pueden recibir una política más estricta.

Sin embargo, la cobertura de red gestionada define el límite. Gateway debe actuar como proxy activo del tráfico HTTP relevante. Si un empleado utiliza un dispositivo no gestionado, una ruta de red independiente o un cliente fuera de los controles de la organización, esas solicitudes no aparecerán en los mismos registros.

El tráfico cifrado añade otra condición. Gateway necesita descifrado TLS para inspeccionar el cuerpo HTTP de una conexión MCP directa. Sin él, los administradores podrían ver el nombre de host de destino, pero no los métodos JSON-RPC ni los argumentos de las herramientas.

Cloudflare gestiona el tráfico de Portal de otra manera. Portal termina la conexión del cliente y crea una nueva conexión con el servidor upstream. Esa arquitectura permite a Gateway inspeccionar el tráfico de Portal enrutado sin depender de la configuración de descifrado TLS de toda la cuenta.

El tráfico directo no recibe ese tratamiento automático. La documentación de Portal de Cloudflare indica que un agente que se conecta directamente a través de un dispositivo gestionado por WARP requiere la configuración normal de descifrado TLS para inspeccionar el cuerpo.

También existen razones legítimas para eximir tráfico de la inspección. Los requisitos de privacidad, las aplicaciones con certificate pinning o las restricciones operativas pueden llevar a los equipos a crear políticas Do Not Inspect. Esas políticas tienen prioridad y pueden dejar fuera del análisis DLP la actividad MCP coincidente.

Estos límites no hacen que la detección sea inútil. Definen lo que realmente significa el panel resultante. Un informe muestra actividad similar a MCP visible en rutas gestionadas e inspeccionadas. No es un censo completo de todas las conexiones de agentes de la empresa.

Esta distinción debería guiar la respuesta a incidentes. Una conexión detectada merece investigación, pero un informe vacío no demuestra que shadow MCP esté ausente. Los equipos de seguridad necesitan cobertura de endpoints, datos de identidad y controles de configuración de clientes junto con la detección de red.

La verdadera disputa es el acceso mediante Portal frente a las conexiones directas

El modelo de seguridad de Cloudflare solo se vuelve aplicable cuando el acceso aprobado mediante Portal sustituye las URL directas de servidores en rutas gestionadas.

Un portal de servidores MCP agrega varios servidores aprobados detrás de un único endpoint HTTP. Los usuarios configuran ese endpoint en su cliente MCP, se autentican mediante Cloudflare Access y reciben solo los servidores y herramientas permitidos por la política.

Portal realiza varias tareas que las conexiones directas distribuyen entre integraciones individuales. Identifica al usuario, evalúa las reglas de Access, gestiona la autenticación upstream, expone herramientas aprobadas y registra solicitudes. Los administradores pueden organizar servidores sin pedir a cada empleado que mantenga una lista independiente de endpoints.

Las políticas de Access pueden usar grupos de identidad, ubicación y postura del dispositivo. Un portal financiero podría exponer herramientas seleccionadas de solo lectura a empleados de finanzas. Un portal de ingeniería podría permitir acciones adicionales únicamente desde dispositivos corporativos gestionados.

Los administradores también pueden ocultar herramientas o prompts individuales. Esto importa porque aprobar un servidor no requiere aprobar cada capacidad que publica. Un servidor con acceso a repositorios podría exponer operaciones de búsqueda y lectura, mientras que su operación de escritura permanece no disponible.

El diseño de Portal de Cloudflare admite servidores upstream sin autenticación y servidores protegidos por OAuth. Los usuarios pueden autenticarse por separado en un servicio upstream, o algunos flujos de trabajo de máquina a máquina pueden usar tokens de servicio de Access. Portal adjunta entonces las credenciales adecuadas al actuar como proxy de una llamada a una herramienta.

Cuando el enrutamiento de Gateway está habilitado, las llamadas en tiempo real pasan de Portal a través de Gateway antes de llegar al servidor upstream. Gateway registra las solicitudes y puede aplicar políticas HTTP y DLP. Los controles de salida también pueden proporcionar a esas solicitudes direcciones de origen predecibles.

Esto crea un patrón práctico de permitir y bloquear. Los equipos de seguridad proporcionan a los empleados un endpoint de Portal aprobado y luego crean reglas de Gateway que detienen las conexiones directas a servidores MCP upstream. La ruta de Portal sigue disponible, mientras que las alternativas no gobernadas quedan restringidas.

La política debe dirigirse al destino correcto. Cloudflare indica que las reglas DLP para tráfico de Portal deben coincidir con el nombre de host del servidor MCP upstream, no únicamente con el dominio de Portal. Portal es el punto de entrada orientado al cliente, pero Gateway evalúa la solicitud reoriginada que viaja hacia el servidor real.

La disposición se parece más a una puerta de enlace de aplicaciones que a un simple directorio. Proporciona un punto de control donde confluyen la identidad, la selección de herramientas, el registro y los controles de datos. Ese punto de control es lo que transforma el descubrimiento en gobernanza.

Sin embargo, la URL directa sigue siendo una debilidad central. Cloudflare advierte que ocultar un servidor de un Portal no impide que un usuario se conecte a su dirección original. Si el servidor ascendente continúa siendo accesible públicamente, la política del Portal por sí sola no puede evitar la evasión.

Por tanto, las organizaciones necesitan un control de aplicación fuera de la interfaz del Portal. Pueden proteger un servidor con Access cuando controlan su nombre de host, restringir el tráfico entrante a direcciones de salida conocidas o bloquear destinos directos mediante Gateway. Los servicios de terceros requerirán los controles que admita su modelo de despliegue.

La elección no es Cloudflare frente a otro proveedor de seguridad. El principal conflicto es entre el acceso gobernado mediante Portal y las conexiones directas configuradas por los usuarios. Todas las funciones principales se orientan a esa disputa.

Los registros del Portal identifican la actividad aprobada. La detección de Gateway busca tráfico fuera de la ruta aprobada. Access establece quién puede usar el Portal. DLP evalúa los datos que atraviesan la ruta gestionada. La política de red intenta cerrar la ruta directa.

Este modelo también ofrece a los desarrolladores un destino utilizable una vez que comienza la aplicación de controles. Una prohibición general de MCP empujaría la experimentación fuera de los canales oficiales. Un Portal curado permite a los equipos mantener disponibles las herramientas aprobadas mientras seguridad revisa servidores adicionales.

El resultado depende de la disciplina operativa. Alguien debe ser responsable del catálogo de servidores aprobados, revisar los permisos de las herramientas, mantener las políticas de Access y responder a los destinos detectados recientemente. La centralización reduce los controles dispersos, pero no elimina esas decisiones.

Las heurísticas de protocolo generan cobertura, no certeza

Cloudflare puede identificar indicadores sólidos de MCP, pero esos indicadores no demuestran que una conexión sea segura, maliciosa o esté correctamente gobernada.

Los patrones de detección son heurísticos. Un cuerpo que contiene "method":"tools/call" se parece mucho a MCP, pero otra aplicación JSON-RPC podría usar el mismo nombre de método. Una implementación personalizada de MCP también podría producir un formato que quede fuera de una expresión regular redactada de forma restrictiva.

Las tolerancias de espacios en blanco ilustran el problema. Las expresiones de ejemplo permiten una cantidad limitada de espacios alrededor de los campos JSON. Los campos reordenados deberían seguir siendo detectables cuando cada patrón se dirige a un campo concreto, pero la serialización y el escape alternativos pueden complicar la coincidencia.

El tráfico cifrado o no compatible crea brechas mayores. DLP no puede inspeccionar un cuerpo HTTPS directo a menos que Gateway lo descifre. Los servidores MCP locales que se comunican mediante entrada y salida estándar no atraviesan ninguna puerta de enlace HTTP.

Streamable HTTP es el transporte remoto más importante en el diseño actual de Cloudflare. La especificación de transporte de MCP define solicitudes HTTP que transportan mensajes JSON-RPC e identificadores de sesión opcionales. Esas estructuras regulares ayudan a Gateway a reconocer el protocolo.

La ruta de Portal enrutada de Cloudflare admite Streamable HTTP. Si un servidor ascendente solo admite el antiguo transporte Server-Sent Events, el enrutamiento de Gateway fallará para ese servidor. El Portal intenta usar Streamable HTTP cuando el enrutamiento está habilitado, pero el servicio ascendente debe admitirlo.

La sincronización en segundo plano es otra excepción. Los Portals recuperan periódicamente herramientas y prompts de los servidores ascendentes, pero Cloudflare afirma que esas solicitudes de sincronización no pasan por Gateway. Solo las llamadas a herramientas de usuarios en tiempo real reciben la inspección enrutada documentada.

La cobertura de DLP también tiene límites específicos del producto. Cloudflare afirma que sus perfiles de prompts de IA no se aplican al tráfico de MCP Portal porque esos perfiles esperan rutas y formatos de API distintos. Los administradores deben utilizar perfiles DLP estándar.

Las reglas Do Not Inspect siguen siendo efectivas para el tráfico de Portal. Aunque el enrutamiento de Portal permite el descifrado automático, una exención explícita impide la inspección de la carga útil. Por tanto, una excepción amplia podría eliminar la protección de DLP de un servidor ascendente aprobado.

Las políticas de identidad también tienen salvedades. Cloudflare documenta que la MFA independiente, la justificación de propósito y la autenticación temporal no se aplican a servidores autorizados mediante un Portal. Los selectores de correo electrónico, grupo, país y postura del dispositivo siguen siendo aplicables.

Estas restricciones importan porque un Portal puede parecer más restrictivo que su ruta de políticas real. Un administrador podría asignar un requisito a nivel de servidor y asumir que los usuarios lo encontrarán durante la autorización del Portal. La documentación de Cloudflare indica que varios controles de refuerzo no funcionarán de ese modo.

Los equipos de seguridad también deben separar la detección de protocolos de la seguridad semántica. Una solicitud puede atravesar un Portal aprobado, no coincidir con ninguna regla DLP y aun así desencadenar una acción insegura. DLP busca patrones de datos definidos, no si eliminar un proyecto se ajusta a la intención del usuario.

La inyección de herramientas plantea un problema relacionado. Un servidor ascendente puede devolver contenido que influya en la siguiente decisión de un agente. La inspección de red puede registrar o bloquear cadenas sensibles, pero no necesariamente reconocer instrucciones manipuladoras integradas en contenido por lo demás válido.

Lo contrario también es cierto. Una conexión MCP en la sombra no es automáticamente un incidente. Un desarrollador podría estar probando una fuente de datos pública e inofensiva. La conexión sigue sin estar gobernada, pero su impacto empresarial y de seguridad requiere contexto.

Por ello, los falsos positivos y los falsos negativos deben formar parte del modelo operativo. Los equipos deberían tratar las coincidencias de nombre de host y URI como pistas, y luego utilizar señales del cuerpo, atribución de usuarios, datos del cliente y revisión del servidor para tomar una decisión. Las reglas de bloqueo de alto impacto deberían basarse en algo más que una coincidencia genérica de ruta.

Un despliegue gradual puede reducir las interrupciones. Los administradores pueden comenzar con el registro, establecer el tráfico esperado del Portal e identificar destinos directos comunes. Después pueden bloquear conexiones en la sombra de alta confianza mientras crean un proceso de aprobación para nuevos servidores.

La versión más sólida combina controles de red y de endpoints. Gateway observa el tráfico remoto que cruza rutas gestionadas. La gestión de endpoints puede controlar qué clientes y configuraciones instalan los usuarios. Access y las restricciones ascendentes dificultan la evasión una vez que existe una ruta aprobada.

Cloudflare ha proporcionado las piezas para esa arquitectura. No ha eliminado la necesidad de diseñarla.

Tres señales mostrarán si el modelo MCP de Cloudflare se sostiene

La próxima prueba es si las empresas pueden convertir la visibilidad de MCP en un enrutamiento coherente, bloqueos significativos y una gobernanza medible de las herramientas.

La primera señal es la proporción de tráfico detectado que se desplaza a través de dominios Portal aprobados. Es probable que las búsquedas iniciales en Gateway revelen una mezcla de servicios conocidos, experimentos y falsos positivos. El modelo gana credibilidad cuando la actividad MCP directa disminuye después de que haya alternativas aprobadas disponibles.

Los equipos de seguridad deberían medirlo como un resultado de enrutamiento, no solo como un recuento de bloqueos. Un número creciente de solicitudes bloqueadas podría demostrar que la política funciona, pero también puede indicar que los usuarios siguen intentando evadir la ruta aprobada. Una migración exitosa significa que la actividad legítima continúa a través del Portal.

La segunda señal es la calidad de las políticas a nivel de herramientas y datos. Un Portal que expone todas las capacidades de todos los servidores aprobados centraliza el acceso sin aplicar muchas restricciones. Los despliegues más sólidos seleccionarán herramientas, usarán condiciones de identidad y aplicarán perfiles DLP tanto a las solicitudes como a las respuestas.

Gateway de Cloudflare puede bloquear una solicitud de herramienta cuando el contenido saliente coincide con un perfil DLP estándar. También puede bloquear la respuesta cuando el servidor ascendente devuelve datos sensibles coincidentes. El cliente MCP recibe un error en lugar del contenido protegido.

Estos controles se vuelven más valiosos cuando las organizaciones los ajustan a flujos de trabajo reales. Las credenciales, la información financiera, los identificadores de clientes y los documentos propietarios conllevan riesgos diferentes. Una política que bloquea todo frustrará a los usuarios, mientras que una que nunca se activa ofrece poca protección.

Los equipos de seguridad deberían rastrear los métodos de herramientas bloqueados, las categorías de datos coincidentes, los servidores afectados y los resultados para los usuarios. También deberían revisar si los agentes reintentan repetidamente solicitudes bloqueadas. Los intentos repetidos pueden revelar un comportamiento deficiente del cliente o un flujo de trabajo que necesita un diseño aprobado más seguro.

La tercera señal es la rapidez con la que Cloudflare y el ecosistema MCP cierran las brechas de cobertura conocidas. La adopción de Streamable HTTP debería reducir el número de servidores ascendentes que no pueden usar el enrutamiento de Gateway. Unos mejores controles de endpoints podrían mejorar la visibilidad de las configuraciones locales y no gestionadas.

Los cambios de protocolo también importarán. Los patrones de detección construidos en torno a los métodos JSON-RPC actuales deben seguir la especificación a medida que evoluciona. Una cabecera estable u otra señal de transporte estandarizada podría facilitar la clasificación, pero los equipos de seguridad no deberían asumir que todos los clientes adoptarán nuevos campos de inmediato.

El comportamiento de los competidores aportará otra pista sin cambiar la disputa central. Es probable que los proveedores de puertas de enlace web seguras y endpoints añadan sus propias clasificaciones MCP, inventarios de servidores o controles de agentes. Esa presión puede mejorar los métodos de detección y revelar dónde se quedan cortos los enfoques basados únicamente en red.

La ventaja de Cloudflare es la integración arquitectónica. Su Portal, Access, Gateway, DLP, salida y controles de aplicaciones pueden participar en una misma ruta de políticas. Su desafío es demostrar que los clientes pueden configurar esos componentes sin dejar vías de evasión significativas.

Por tanto, la historia del cómo de Cloudflare trata menos de un único detector que de un ciclo de retroalimentación. Encontrar tráfico MCP directo, investigarlo, aprobar los servidores necesarios, enrutarlos mediante un Portal y bloquear la ruta no gestionada. Después, repetir el proceso a medida que los usuarios adopten nuevas herramientas.

Las organizaciones que consideren este modelo deberían comenzar con una pregunta práctica: ¿qué rutas de red gestionadas y qué clientes de agentes puede observar realmente hoy su equipo de seguridad?

A partir de ahí, pueden inventariar las señales MCP, compararlas con el tráfico aprobado del Portal y elegir dónde la aplicación de controles tiene suficiente confianza. El objetivo no es etiquetar cada conexión MCP como peligrosa. Es garantizar que los agentes lleguen a herramientas sensibles mediante una ruta que la organización pueda autenticar, inspeccionar y auditar.