Cloudflare dividió el acceso a Workers en roles y ámbitos en lugar de una única lista grande de permisos

A medida que más equipos y agentes de programación autónomos comenzaron a desplegar directamente en la Plataforma para Desarrolladores de Cloudflare, el modelo de permisos existente obligaba a una elección incómoda: conceder roles amplios, a nivel de toda la cuenta, que permitieran a un agente tocar cada Worker, base de datos y bucket de la cuenta, o construir a mano suficientes permisos individuales para cubrir cada caso, lo que se vuelve inmanejable a medida que crece el número de recursos y acciones.

La solución de Cloudflare fue dejar de tratar el acceso como una única lista plana y, en su lugar, definir dos dimensiones independientes. Cuatro roles —Solo lectura de metadatos, Solo lectura de contenido, Editor y Administrador— describen niveles de capacidad, desde ver registros y métricas sin ver el código, hasta leer el código sin editarlo, pasando por editar sin eliminar, hasta el control total. Por separado, cada rol puede aplicarse en uno de tres ámbitos: cada recurso de la Plataforma para Desarrolladores, cada recurso de un producto (todos los Workers) o un único recurso con nombre (un Worker específico).

Los dos ejes se combinan de forma independiente. Una canalización de CI/CD puede recibir el rol Editor con ámbito limitado exactamente al único Worker que despliega, de modo que un token filtrado pueda actualizar ese Worker pero no pueda eliminarlo ni tocar ninguna otra aplicación. Un agente de depuración puede recibir Solo lectura de metadatos con ámbito limitado a un Worker, de modo que pueda inspeccionar registros y trazas sin leer nunca el código fuente. Cloudflare diseñó la misma estructura de dos roles por ámbitos para extenderla más adelante a otros recursos de la Plataforma para Desarrolladores, como las bases de datos D1 y los buckets R2, en lugar de inventar nuevos permisos para cada producto.

Separar «qué puedes hacer» (rol) de «dónde puedes hacerlo» (ámbito) como dos ejes independientes

Combinar cuatro roles con tres ámbitos produce doce niveles de acceso precisos a partir de un vocabulario pequeño y fijo, en lugar de una explosión combinatoria de permisos puntuales por recurso.

Limitar el ámbito a un único recurso (un Worker) significa que un token de agente comprometido o mal configurado tiene un radio de impacto contenido: no puede ver ni tocar ningún otro recurso de la cuenta.

La misma estructura de rol/ámbito se diseñó para extenderse a otros productos (D1, R2, KV) sin rediseñar el modelo cada vez.

Durable Objects hereda el acceso del rol de su Worker principal en lugar de necesitar su propio sistema de permisos, lo que evita que el modelo se fragmente aún más.

Cuando las necesidades de acceso se multiplican con más agentes, no añadas más permisos individuales: divide el control de acceso en dos ejes ortogonales, capacidad y ámbito, que se combinan en lugar de multiplicarse.

Cloudflare también añadió respuestas de error 403 contextuales que enlazan directamente a la documentación que describe qué permiso falta, de modo que un agente o desarrollador que se topa con un muro de permisos pueda autocorregirse en lugar de quedarse atascado con una respuesta genérica de «Forbidden». La empresa dijo que planea extender el mismo modelo de rol y ámbito a las bases de datos D1, los buckets R2 y los espacios de nombres KV a continuación.