A Cloudflare dividiu o acesso ao Workers em funções e escopos, em vez de uma única grande lista de permissões

À medida que mais equipes e agentes de programação autônomos passaram a implantar diretamente na Plataforma de Desenvolvedor da Cloudflare, o modelo de permissões existente impunha uma escolha desconfortável: conceder funções amplas, no nível da conta, que permitiam a um agente acessar todos os Workers, bancos de dados e buckets da conta, ou construir manualmente permissões individuais suficientes para cobrir todos os casos — o que se torna inviável à medida que o número de recursos e ações cresce.

A solução da Cloudflare foi deixar de tratar o acesso como uma lista única e plana e, em vez disso, definir duas dimensões independentes. Quatro funções — Somente Leitura de Metadados, Somente Leitura de Conteúdo, Editor e Administrador — descrevem níveis de capacidade, desde visualizar logs e métricas sem ver o código, passando por ler o código sem editá-lo, editar sem excluir, até o controle total. Separadamente, cada função pode ser aplicada em um de três escopos: todos os recursos da Plataforma de Desenvolvedor, todos os recursos de um produto (todos os Workers) ou um único recurso nomeado (um Worker específico).

Os dois eixos se combinam de forma independente. Um pipeline de CI/CD pode receber a função Editor com escopo restrito exatamente ao único Worker que ele implanta, de modo que um token vazado possa atualizar esse Worker, mas não possa excluí-lo nem acessar qualquer outra aplicação. Um agente de depuração pode receber Somente Leitura de Metadados com escopo em um único Worker, para inspecionar logs e rastreamentos sem nunca ler o código-fonte. A Cloudflare projetou essa mesma estrutura de funções vezes escopos para, mais tarde, estendê-la a outros recursos da Plataforma de Desenvolvedor, como bancos de dados D1 e buckets R2, em vez de criar novas permissões para cada produto.

Separar 'o que você pode fazer' (função) de 'onde você pode fazer' (escopo) como dois eixos independentes

Combinar quatro funções com três escopos produz doze níveis precisos de acesso a partir de um vocabulário pequeno e fixo, em vez de uma explosão combinatória de permissões avulsas por recurso.

Restringir o escopo a um único recurso (um Worker) significa que um token de agente comprometido ou mal configurado tem raio de impacto contido — ele não consegue ver nem acessar qualquer outro recurso da conta.

A mesma estrutura de função/escopo foi criada para se estender a outros produtos (D1, R2, KV) sem redesenhar o modelo a cada vez.

Os Durable Objects herdam o acesso da função do Worker pai, em vez de precisarem de seu próprio sistema de permissões, o que evita que o modelo se fragmente ainda mais.

Quando as necessidades de acesso se multiplicam com mais agentes, não adicione mais permissões individuais — divida o controle de acesso em dois eixos ortogonais, capacidade e escopo, que se combinam em vez de se multiplicar.

A Cloudflare também adicionou respostas contextuais de erro 403 que remetem diretamente à documentação que descreve qual permissão está faltando, para que um agente ou desenvolvedor que esbarre em uma barreira de permissão possa se autocorrigir em vez de ficar preso a uma resposta genérica de 'Forbidden'. A empresa afirmou que planeja estender o mesmo modelo de função e escopo a bancos de dados D1, buckets R2 e namespaces KV em seguida.