La rapidez con la que los equipos crean aplicaciones con herramientas de inteligencia artificial también multiplica un riesgo conocido: que un prototipo interno termine expuesto en Internet. Cloudflare ha anunciado una integración de Access directamente en Cloudflare Workers para que esas aplicaciones puedan exigir el inicio de sesión de la empresa antes de que se ejecute su código.
La novedad cambia el punto en el que se aplica la protección. Hasta ahora, las políticas de Access se configuraban por nombre de host. Eso obligaba a preparar reglas para cada dominio desde el que fuera accesible un Worker y dejaba margen para cometer errores al añadir nuevas direcciones. Con el nuevo enfoque, la política se asocia al propio Worker: cualquier dominio o URL vinculado a esa aplicación queda protegido automáticamente.
Autenticación antes de llegar al código
Según Cloudflare, Access intercepta la solicitud antes de que alcance la aplicación. El comportamiento es el mismo si el acceso llega por un dominio personalizado, una ruta, un subdominio workers.dev o una URL de vista previa. Si la protección está activada, el visitante debe autenticarse primero.
Esto resulta especialmente útil en entornos donde se publican versiones de prueba con frecuencia. La compañía permite establecer una política en toda la cuenta para que los despliegues de producción y las vistas previas queden tras el acceso corporativo por defecto. También se puede aplicar la medida a una única aplicación, con autenticación obligatoria en todos sus dominios asociados sin depender de cómo se haya desplegado.
La decisión pretende reducir el trabajo manual en equipos que desarrollan muchas herramientas internas. En lugar de pedir a cada persona que recuerde crear la regla adecuada para cada URL, la organización puede fijar una base común. Es una respuesta práctica a la proliferación de aplicaciones creadas rápidamente, un fenómeno que hace que la seguridad de la publicación sea tan importante como la del código.
Identidad disponible para el desarrollo
La integración no se limita a bloquear accesos no autorizados. Cloudflare indica que permite saber quién visita una aplicación y entregar al código el correo electrónico, el nombre y los grupos de cada usuario autenticado. De esta forma, los desarrolladores pueden usar esos datos para adaptar permisos o funciones internas sin validar por su cuenta un JWT.
El alcance cubre las direcciones asociadas a un Worker, de modo que al incorporar un dominio personalizado no debería quedar una vía paralela sin autenticar. Para una plataforma interna, esa diferencia es relevante: los enlaces de prueba y las URL temporales suelen ser precisamente las que se crean fuera de los flujos más controlados.
Cloudflare también ha publicado como código abierto un ejemplo de plataforma de sitios estáticos internos en la que cada Worker se publica como privado de forma predeterminada. Sirve como referencia de implementación, aunque el anuncio no detalla qué configuraciones concretas adoptará cada organización ni sustituye la revisión de permisos y datos de cada aplicación.
El cambio llega mientras las empresas buscan trasladar los principios de acceso de mínimo privilegio a herramientas desarrolladas por departamentos no especializados. Para quienes ya usan Workers, centralizar la autenticación puede simplificar el despliegue de utilidades corporativas. La reciente mejora de Cloudflare en la vigilancia de Certificate Transparency apunta al mismo objetivo: dar más visibilidad y control sobre los activos expuestos.
La propuesta no elimina la necesidad de diseñar permisos adecuados dentro de cada servicio, pero sí añade una barrera anterior a la ejecución. En un contexto en el que crear una aplicación es cada vez más sencillo, hacer que sea privada desde su primer despliegue puede evitar que una herramienta pensada para el uso interno termine accesible por error.
