Cloudflare anunció el 3 de noviembre de 2026 que los nuevos AI Gateways requieren autenticación. Además, una vez activada, ya no se puede deshabilitar desde el panel ni desde la API. Los gateways existentes que la tenían apagada pueden continuar así: el anuncio no obliga a activar de golpe todas las instalaciones antiguas.
Para un equipo que utiliza este intermediario entre su aplicación y los proveedores de modelos, el cambio exige revisar cómo envía las credenciales. Copiar la configuración de un gateway antiguo sin autenticación a uno nuevo puede dejar fuera un requisito necesario.
El anuncio formó parte de nuestro resumen de novedades del 3 de noviembre. Aquí desarrollamos las consecuencias para la integración.
Crear y actualizar tienen reglas distintas
Según el anuncio del cambio, al crear un gateway mediante la API se puede omitir el campo authentication o enviarlo como true. La autenticación queda habilitada; enviar false devuelve HTTP 400.
Al actualizar uno existente, omitir ese campo conserva su estado. Enviar true activa la autenticación permanentemente. Intentar pasar a false después de activarla también devuelve HTTP 400. Por tanto, un plan de vuelta atrás no debería depender de apagarla si fallan los clientes: estos deben estar preparados antes del cambio.
La cabecera depende de la API utilizada
La documentación de autenticación distingue dos caminos:
- La API REST de
api.cloudflare.comutilizaAuthorization: Bearer <token de Cloudflare>. - Los endpoints nativos de proveedores en
gateway.ai.cloudflare.comutilizancf-aig-authorization: Bearer <token de Cloudflare>.
Los accesos desde Workers mediante un binding —un enlace configurado entre servicios— ya están preautenticados dentro de la cuenta correspondiente. No necesitan añadir manualmente esa segunda cabecera.
El token de Cloudflare y la clave del proveedor cumplen funciones diferentes. Con BYOK, el almacenamiento de claves de proveedores, el gateway puede insertar la clave guardada cuando falta la cabecera de autorización del proveedor. Si el cliente envía esa cabecera con un valor de relleno, se reenvía ese valor y puede fallar la autenticación del proveedor. Guardar su clave no elimina la autenticación del propio gateway.
Un cambio que conviene ensayar por cliente
Ejemplo hipotético, no ejecutado por Puntoes: un backend de soporte funciona con un gateway antiguo sin token. El equipo crea otro para probar una integración y reutiliza la configuración HTTP anterior. La nueva ruta exige autenticación y las peticiones sin ella fallan, aunque el modelo elegido sea el mismo.
La comprobación útil sería inventariar los clientes y sus endpoints, adaptar la cabecera correspondiente y verificar el recorrido completo en un entorno aislado antes de activar la autenticación del gateway antiguo. También habría que comprobar qué ocurre cuando falta el token y evitar que aparezca en registros o código entregado al navegador. Aquí no hemos creado credenciales ni realizado peticiones de inferencia.
Un token no aísla cada gateway
Cloudflare documenta que el permiso AI Gateway Run tiene alcance de cuenta, sin restricción a un único gateway. Puede permitir consumir claves BYOK configuradas en otros gateways de esa cuenta. La autenticación, por sí sola, no acredita aislamiento entre clientes.
Nuestra lectura práctica es separar tres comprobaciones: quién puede entrar al gateway, qué credenciales permiten llegar al proveedor y dónde se mantiene el aislamiento de cada aplicación. El cambio anunciado resuelve un requisito de acceso; esas otras decisiones siguen necesitando revisión.