Noticia8 min

Cloudflare deja pasar MCP portals por Gateway con logs y DLP: la parte útil no es más visibilidad, es mejor control

Cloudflare activó el 20 de marzo de 2026 una integración entre MCP server portals y Gateway para sumar HTTP logs y perfiles DLP. La mejora útil para builders no es otro panel: es poder mirar y filtrar tráfico sensible cuando el agente ya habla con herramientas reales.

CloudflareMCP
Panel editorial inspirado en Cloudflare con portal MCP, filtros de Gateway y políticas DLP sobre tráfico de agentes

Por qué importa

Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.

Una parte incómoda del boom MCP aparece justo cuando el agente deja la demo y entra a sistemas reales: ya no basta con saber que la tool existe. También necesitas ver qué está saliendo, qué está entrando y cuándo deberías bloquear antes de que un prompt termine mandando datos sensibles a un upstream equivocado.

Cloudflare metió una pieza bastante concreta el 20 de marzo de 2026. Sus MCP server portals ahora pueden enrutar tráfico por Cloudflare Gateway para sumar HTTP request logging y DLP scanning. La noticia útil no es “más observabilidad”. La noticia útil es otra: Cloudflare empieza a tratar el portal MCP como un punto de control, no solo como un catálogo de tools.

Composición editorial con un portal MCP pasando por Gateway y dejando rastro HTTP visible antes de llegar a servidores externos

Qué cambia de verdad

El changelog es bastante directo. Cuando activas Gateway sobre el portal:

  • el tráfico del portal aparece en los HTTP logs de Gateway;
  • puedes aplicar perfiles DLP para detectar o bloquear datos sensibles enviados upstream;
  • y el control vive dentro del mismo plano donde ya operas políticas de red.

Eso importa porque uno de los problemas más aburridos de MCP es que muchas implementaciones se quedan a mitad de camino:

  • buen discovery de tools;
  • autenticación razonable;
  • y casi nada de control fino sobre el contenido que el agente termina mandando.

Cloudflare intenta cerrar parte de ese hueco.

Dónde sí suma valor para builders

Yo lo veo especialmente útil en tres casos.

El primero es MCP sobre sistemas internos donde el agente puede tocar tickets, CRM, documentos o datos de clientes. Ahí los logs ya no son decoración; son evidencia operativa.

El segundo es equipos que centralizan varios servidores MCP detrás de un portal. Cuando el catálogo crece, también crece el riesgo de no saber por dónde salió cada request.

El tercero es cumplimiento mínimo sin matar velocidad. Si el equipo ya vive en Cloudflare, meter Gateway en el camino suele ser más realista que inventar otra capa casera para inspeccionar tráfico.

Panel editorial con políticas DLP, rutas permitidas y decisiones de bloqueo sobre tráfico saliente desde herramientas MCP

El detalle que conviene no exagerar

Esto no significa que MCP quede “seguro” por definición.

La propia documentación deja una limitación importante: los AI prompt DLP profiles no aplican aquí. Lo que Cloudflare habilita es DLP sobre el tráfico del portal dentro de Gateway, no una comprensión semántica total de cada flujo agentic.

Además, si tu catálogo de tools ya está mal gobernado, ver mejores logs no arregla permisos excesivos ni endpoints mal expuestos. Solo te da una base mejor para detectar y acotar.

También conviene recordar que un portal puede mezclar servidores sin autenticación y servidores OAuth. Esa flexibilidad es útil, pero también pide disciplina: no todos los servidores merecen el mismo nivel de acceso ni el mismo tratamiento de logs.

Por qué esta historia puede ganar búsquedas buenas

Las queries valiosas aquí son muy de implementación:

  • cloudflare mcp gateway
  • mcp portal dlp
  • cloudflare gateway mcp logs
  • controlar tráfico mcp

No es tráfico de humo. Es gente que ya pasó de “quiero usar MCP” a “cómo no lo dejo sin controles cuando toque datos reales”.

En español hay poco contenido que conecte MCP con red, logging y DLP como parte del mismo problema. Muchas notas se quedan en discovery de tools o en standards. Esta mejora toca la capa menos glamorosa y más importante: qué tan gobernable se vuelve el tráfico cuando el agente ya opera de verdad.

Mi lectura práctica

Si hoy ya tienes un portal MCP o estás por centralizar varios servidores, yo revisaría esto:

  1. qué servidores realmente deben pasar por el portal;
  2. qué datos sensibles podrían viajar en requests;
  3. qué logs necesitas retener para debugging y auditoría;
  4. y en qué casos un bloqueo DLP debe cortar el flujo antes de ejecutar.

Eso no reemplaza una buena arquitectura de permisos, pero sí mejora bastante el último kilómetro entre “el agente tiene tools” y “el equipo puede sostener eso sin volar a ciegas”.

Esta noticia conversa bien con Cloudflare code mode para MCP portals, porque aquella trata de bajar costo y contexto cuando tienes demasiadas tools, y esta se mete en la otra mitad del problema: cómo mirar y filtrar el tráfico cuando esas tools ya se usan de verdad. Si todavía estás aterrizando la base antes de abrir ese frente, el punto de entrada sano sigue siendo el curso gratis.