Quando uma aplicação pede acesso a uma conta, a autorização costuma virar uma escolha binária: aceitar tudo ou recusar tudo. Isso ficou desconfortável à medida que SaaS, CLIs e agentes passaram a pedir capacidades muito diferentes. Em 20 de agosto de 2026, a Cloudflare apresentou escopos opcionais no OAuth, permitindo que donos de clientes marquem permissões como obrigatórias ou opcionais e que usuários retirem as opcionais durante a autorização.
A proposta não é criar uma lista interminável para decifrar. A tela continua concedendo o conjunto completo por padrão, mas permite limitar o acesso quando o cliente foi configurado para isso. Um agente que consulta uma zona não deveria receber automaticamente permissão para alterar scripts e gravar dados apenas porque poderia precisar desses recursos em outro fluxo.
OAuth permite que uma aplicação aja em nome de alguém sem receber a senha. Cada escopo representa uma capacidade: ler informações, escrever um recurso, executar uma alteração ou acessar uma área da conta. Se uma integração pede mais do que precisa, o usuário entrega acesso excessivo ou abandona a tarefa. A Cloudflare cita servidores MCP como exemplo, pois um servidor pode declarar permissões amplas embora a pessoa queira apenas consultar dados em uma sessão.
Permissão por tarefa
Há um detalhe técnico importante: obrigatório e opcional são avaliados em relação aos escopos pedidos naquela autorização específica, não em relação a tudo o que o cliente tem configurado. Um cliente pode ter user-details.read, workers-scripts.write, workers-kv-storage.write e zone.read, marcando os dois últimos como opcionais. Se pedir os quatro, a pessoa poderá retirar armazenamento e zona. Se pedir só scripts e zona em outro fluxo, somente esses dois entram na avaliação.
Para quem está começando, a distinção é simples: o cliente define o que sabe fazer; o fluxo define o que pretende fazer agora. Separar as duas coisas melhora a explicação e reduz a chance de uma permissão ampla virar padrão. Não é uma garantia automática de segurança, mas é uma estrutura melhor para decidir.
A consequência não fica apenas na tela. Se a pessoa desmarcar escopos opcionais, o token gerado conterá somente as permissões consentidas. Trocar o código de autorização por um token não significa que todos os escopos pedidos foram concedidos. A aplicação precisa consultar e tratar o conjunto recebido, desabilitando apenas a parte que exige a permissão ausente e mantendo o restante quando possível.
Esse princípio combina com menor privilégio. Em vez de entregar ao agente acesso permanente a leitura, escrita e execução, a aplicação pode pedir o mínimo para cada trabalho. A configuração estreita também limita o estrago de um bug, de uma instrução ambígua ou de uma tentativa de injeção de prompt. Para MCP, vale separar ferramentas de leitura e escrita, conferir o conjunto concedido antes de expor cada ferramenta e exigir confirmação para operações destrutivas.
Desenvolvimento responsável
A configuração permite indicar optional_scopes junto dos escopos do cliente. O formato é simples, mas exige mapear cada tarefa, definir capacidades indispensáveis e escrever o comportamento para uma concessão parcial. A suíte deve testar o caminho em que o usuário não concede uma permissão, além das mensagens de erro e dos registros de auditoria. Se um agente muda dados, o sistema precisa registrar identidade, escopos, ferramenta chamada e resultado.
A parte mais interessante não é a nova caixa de seleção. É a mudança de responsabilidade: o desenvolvedor deixa de pensar apenas no que o produto suporta e passa a explicar o que cada tarefa precisa. Escopos opcionais não substituem revisão de código, logs, limites ou supervisão humana. A regra para um projeto pequeno é direta: não peça acesso para a tarefa de amanhã quando a tarefa de hoje precisa de uma única leitura. Comece estreito e amplie mediante decisão explícita.
Fonte: Cloudflare Blog — From all-or-nothing to task-based OAuth consent, publicado em 20 de agosto de 2026. Imagens: Cloudflare Blog.
