Cloudflare quiere hacer visible el MCP en la sombra

El 22 de agosto apareció una noticia que, leída rápido, parece de fontanería: Cloudflare ha añadido a su Gateway la capacidad de ver y bloquear tráfico del Model Context Protocol que nadie ha autorizado. Leída despacio, es el momento en el que MCP deja de ser una cosa de desarrolladores curiosos y pasa a ser una categoría de tráfico que un equipo de seguridad tiene que inventariar, igual que en su día pasó con Dropbox o con las extensiones de navegador.

La pieza original está publicada en forkast.news bajo el titular «Cloudflare Gateway Makes Shadow MCP Visible and Blockable». El término shadow MCP no lo ha acuñado Cloudflare, pero es la primera vez que lo vemos convertido en una función de producto dentro de un proveedor de red generalista.

Qué es el MCP en la sombra

MCP es el estándar de Anthropic para que un modelo llame a herramientas externas. Un servidor MCP se conecta de dos formas: como proceso local por stdio, o como servidor remoto por HTTP con su propio flujo de autorización. En Claude Desktop la configuración vive en claude_desktop_config.json, dentro del portátil del usuario. En Claude Code se añade con un comando y una decisión de scope. En ninguno de los dos casos pasa por un ticket de IT.

El resultado es previsible. Un desarrollador conecta en cinco minutos su Claude a Jira, a Drive, a un bucket de S3 o a una réplica de la base de datos, y la organización no tiene registro de ello. La diferencia con el shadow IT clásico importa: un SaaS no autorizado leía datos, mientras que un servidor MCP ejecuta acciones con las credenciales de quien lo instaló, y lo hace a partir de instrucciones que puede acabar dictando un texto de terceros. Ahí es donde entran el prompt injection y el envenenamiento de descripciones de herramientas, porque el modelo confía en lo que la herramienta dice ser.

Qué resuelve un gateway y qué no

Gateway es el secure web gateway de Cloudflare: se sitúa en el camino de salida del tráfico corporativo y aplica política antes de que la petición llegue a su destino. Que sepa identificar endpoints MCP y permitir o denegar según reglas significa dos cosas prácticas. Hay inventario, es decir, qué servidores se están usando y desde qué equipos. Y hay palanca, porque se puede cortar uno concreto sin cortar el acceso a internet del equipo entero.

Conviene no sobrevender el alcance. Un gateway ve tráfico de red, así que lo que captura bien son los servidores MCP remotos. Un servidor local por stdio que solo toca el sistema de ficheros del portátil no genera tráfico que un gateway pueda leer, y ese es justo el perfil de servidor que más se instala a mano. La visibilidad completa sigue necesitando algo en el endpoint, no solo en la red.

A quién le sirve esto hoy

A los equipos de IT y seguridad de empresas donde ya hay veinte o más personas usando Claude Code o Claude Desktop a diario. Si estás en ese grupo, el ejercicio útil no es comprar nada todavía, sino escribir la lista: qué servidores MCP corre cada máquina, con qué tokens y contra qué sistemas. Casi siempre esa lista es más larga de lo que el CTO esperaba.

Y le sirve a quien construye servidores MCP para terceros, que es nuestro caso. Si los gateways corporativos empiezan a filtrar por dominio, un servidor publicado en un dominio estable, con scopes de OAuth documentados y sin puertos raros, es un servidor que se aprueba en la revisión. Uno que sale por un túnel efímero creado durante el desarrollo, no.

Nos parece un movimiento esperable, y llega con un retraso razonable respecto a la adopción real de MCP. Lo que no arregla, y conviene decirlo, es el problema de fondo: el control sobre qué puede hacer una herramienta una vez conectada sigue viviendo en el diseño del servidor y en el alcance del token, no en la capa de red.