Cloudflare publicó el 26 de junio de 2026 una mejora muy concreta para equipos que ya están llevando MCP a entornos protegidos: MCP server portals ahora aceptan conexiones de agentes autónomos y bots usando Access service tokens.

Hasta ahora, mucho diseño de MCP empresarial asumía que detrás había una persona completando OAuth en el navegador. Eso funciona para un builder que opera manualmente. Funciona peor para un agente programado, un job nocturno o un bot que necesita llamar tools sin abrir una pantalla de login.

Diagrama editorial de un bot entrando a un MCP portal de Cloudflare con headers de service token y políticas de Access

Qué cambió exactamente

El changelog dice que el bot puede conectarse al portal con headers CF-Access-Client-Id y CF-Access-Client-Secret. Si el token está autorizado, el bot ve las tools de los servidores MCP enlazados para los que también existe una política Service Auth compatible.

La documentación aterriza el patrón en tres piezas:

una política Service Auth en la aplicación Access del portal;
una política Service Auth en cada servidor MCP enlazado;
Require user auth apagado para cada servidor que el bot debe alcanzar.

Ese último punto es el que más importa. En la API y Terraform, Cloudflare lo mapea al campo on_behalf. Si on_behalf queda en true, el servidor exige OAuth por usuario y queda excluido de sesiones con service token. Si queda en false, el portal usa la credencial administradora.

Por qué esto no es solo comodidad

Para agentes de infraestructura, seguridad o soporte interno, el bloqueo típico no es "no sabemos llamar MCP". Es identidad. Un agente recurrente no tiene un navegador propio, no debería guardar cookies humanas y no debería depender de que alguien refresque una sesión.

Service tokens resuelven parte de esa fricción. Permiten que una automatización llegue a tools protegidas por Access sin convertir el portal en un endpoint público ni pedir OAuth humano en cada corrida.

Pero también cambian el modelo de riesgo: cuando el portal usa credencial admin para upstream requests, ya no estás representando a una persona específica. Estás dando a un proceso una ruta de servicio. Eso exige separar bien qué puede hacer.

Pipeline editorial con on_behalf apagado, credencial administradora y servidores MCP separados por riesgo

Checklist antes de activarlo

No habilitaría esto con todos los servidores MCP de una vez. Haría una migración pequeña:

crea un portal dedicado para bots, no mezcles todo con usuarios humanos;
enlaza solo servidores de bajo riesgo al inicio;
usa service tokens distintos por bot o workflow;
define expiración y rotación del token desde el primer día;
registra qué tools se invocan y desde qué job;
deja los servidores que necesitan identidad humana con Require user auth encendido.

La trampa es pensar que "autónomo" significa "sin gobernanza". En realidad, el patrón correcto es lo contrario: menos fricción interactiva, más diseño explícito de permisos.

Dónde encaja para builders

Este lanzamiento encaja muy bien con agentes que corren inventarios, revisan configuración, consultan documentación interna o ejecutan acciones repetibles de bajo riesgo. Encaja peor para workflows donde cada acción debe representar a una persona distinta, como aprobar gastos, cambiar permisos críticos o leer datos de cliente con reglas finas.

La demanda se infiere por señales actuales: changelog oficial, docs actualizadas de MCP portals, crecimiento de MCP remoto y queries probables como Cloudflare MCP service token, MCP portal Access service token, CF-Access-Client-Id MCP y on_behalf MCP portal. No hay tooling SEO conectado, así que no invento volumen.

Si estás aprendiendo la base de tools y permisos, empieza por el curso gratis. Si ya tienes MCP en producción, esta noticia te deja una regla práctica: los bots no necesitan OAuth humano, pero sí necesitan un perímetro de tools más chico que el de una persona.