Claude Code deixa de pedir permissão a 14 de agosto

O teste que a Anthropic fez com 1053 programadores reais

Kai Zhou, staff software engineer na Nuro, pôs um agente do Claude Code a trabalhar às 22 horas e deixou-o a funcionar. Quando voltou a verificar às 5 da manhã, o agente tinha produzido três pull requests, e ele não tinha tido de aprovar um único pedido de permissão durante toda a noite para os obter. "Pus um agente a trabalhar às 22 horas e ele continuou a funcionar até às 5 da manhã - e deu-me três PRs de manhã", contou. Este tipo de execução sem supervisão é exatamente o que o modo automático da Anthropic foi criado para tornar habitual em vez de excecional, e a partir de 14 de agosto de 2026 passa a ser o comportamento padrão de qualquer conta do Claude Code nos planos Pro, Max e Team - deixando de ser uma definição opcional que uma equipa tem de procurar e ativar.

Antes de tomar essa decisão, a Anthropic realizou um teste controlado para verificar se eliminar o pedido de permissão é realmente mais seguro ou apenas mais rápido. Recrutou 1053 testadores profissionais pagos e, a meio da sessão, substituiu o pedido de permissão que cada um via por um comando genuinamente perigoso. Os testadores que dependiam da revisão manual detetaram-no em 13,6% dos casos - 143 em 1053. O modo automático, observando as mesmas sessões, bloqueou 89% dos mesmos comandos substituídos - 937 em 1053. No mesmo teste exato, sobre a mesma população exata, a verificação automatizada detetou a ação perigosa cerca de 6,5 vezes mais vezes do que a revisão humana.

O que muda realmente a 14 de agosto

O modo automático não elimina os pedidos de permissão por completo. A Anthropic descreve-o como um sistema que encaminha as chamadas de ferramentas através de um classificador que continua a parar e a perguntar quando uma ação parece irreversível, destrutiva ou dirigida para fora do ambiente - apagar dados, publicar em produção, contactar um sistema que o agente não tem motivo claro para tocar. Se o classificador continuar a bloquear, a sessão volta à aprovação manual após 3 bloqueios consecutivos ou 20 numa mesma sessão, pelo que uma execução autónoma longa tem sempre um ponto de controlo incorporado em vez de decorrer até ao fim sem supervisão, seja o que for que encontre. A Anthropic também acrescentou uma camada dedicada de deteção de injeção de instruções, bem como regras de bloqueio fixo configuráveis que um administrador pode definir para impedir ações específicas, como vias de exfiltração de dados, independentemente do que o próprio classificador decida.

A equipa que o constrói já trabalha assim. "A equipa e eu usamos o modo automático exclusivamente, há muitos meses. Não conseguiria imaginar voltar aos pedidos de permissão", afirmou Boris Cherny, que lidera o Claude Code na Anthropic. Tomislav Reil, Director of Engineering na Adobe, descreveu um padrão semelhante no seu próprio fluxo de trabalho: "O Claude constrói a interface do utilizador e depois volta atrás para verificar se corresponde ao design pretendido, corrigindo automaticamente quaisquer problemas antes de sequer os vermos". Segundo a Anthropic, as equipas que adotaram o modo automático entregam cerca de mais 25% de pull requests, e a partir de 14 de agosto também deixa de cobrar às contas Pro, Max e Team o custo adicional de tokens que o próprio classificador gerava, com a mesma alteração de preços prevista para a Enterprise, que por agora se mantém opcional, dentro de cerca de um mês.

O ponto de partida real nunca foi uma revisão cuidadosa

A comparação para a qual a Anthropic quer chamar a atenção é a taxa de deteção de 89% do modo automático face aos 13,6% da revisão manual. Mas um número distinto, divulgado junto com o anúncio, explica melhor de onde vem essa diferença: os utilizadores do Claude Code já aprovam 97% dos pedidos de permissão que lhes são apresentados. Esse é o ponto de partida honesto para esta decisão, e não se trata de "um revisor humano cuidadoso contra um piloto automático não testado". É um revisor que, por hábito, já aprovava cerca de 19 em cada 20 pedidos, substituído por um sistema que é mensuravelmente melhor a detetar aquele um em 20 que realmente importava. Os dados de produção da Anthropic confirmam isto também fora do teste em laboratório: as sessões que dependiam de aprovação manual registaram danos não intencionais de nível de gravidade 7 ou superior em 6,3% dos casos, contra 2,4% nas sessões com modo automático a realizar o mesmo tipo de trabalho.

Nada disto torna 89% um número definitivo. O próprio teste da Anthropic deixa ainda 11% dos comandos perigosos inseridos que o classificador não teria bloqueado, e a leitura honesta do estudo é "claramente mais seguro do que aquilo que a maioria das equipas fazia na prática", não "resolvido". A Anthropic também reporta uma taxa de sucesso de 0% para ataques de injeção de instruções contra modelos Claude em modo automático na sua própria avaliação, e associa essa afirmação à nova camada de deteção e às regras de bloqueio fixo acima descritas.

Um comentário independente publicado um dia antes do anúncio da Anthropic, do programador e investigador de modelos de linguagem Simon Willison, traçou uma distinção mais nítida que vale a pena ter em conta em qualquer decisão de adoção: detetar danos acidentais e descuidados é um problema diferente de detetar uma instrução deliberadamente maliciosa introduzida no contexto de um agente. O seu exemplo foi um pacote de terceiros comprometido cujas instruções se leem como um passo normal dentro do ambiente - "executar a bateria de testes" - mas que na realidade aciona um pedido malicioso, exatamente o tipo de ação que um classificador treinado para sinalizar trabalho "dirigido para fora do ambiente" poderia deixar passar precisamente por não parecer externo à primeira vista. Isto não é um argumento a favor de manter a revisão manual, que no próprio teste da Anthropic detetou menos de tudo. É uma razão para não tratar o classificador como uma resposta completa a instruções injetadas, apenas às acidentais e destrutivas.

O que decidir antes de 14 de agosto, não depois

Auditem o que o modo automático pode tocar, antes de a definição padrão mudar sob a vossa equipa. O classificador da Anthropic traça a sua própria linha em torno de "irreversível, destrutivo ou dirigido para fora do ambiente" - enumerem as ações no vosso pipeline específico que essa linha pode não apanhar mas que vocês próprios considerariam irreversíveis: escritas na base de dados de produção, rotação de chaves, comandos de deployment, tudo o que alcance um ambiente de cliente. As novas regras de bloqueio fixo da Anthropic permitem a um administrador bloquear essas ações explicitamente; configurem-nas antes de 14 de agosto, não depois de uma sessão já ter executado uma delas.

Definam o vosso próprio limiar de recurso, não o padrão da Anthropic. O gatilho de 3 bloqueios consecutivos ou 20 por sessão para aprovação manual é uma definição padrão, não uma lei fixa, e um teto sem supervisão de 20 ações é uma margem larga para uma única execução noturna como a de Kai Zhou. Reduzam-no para qualquer pipeline que toque em credenciais, dados de clientes ou infraestrutura de produção, e deixem-no no padrão apenas onde um erro seja genuinamente reversível.

Resolvam a questão do registo de auditoria antes de um regulador a colocar. Se a vossa organização estiver no âmbito do NIS2 ou da DORA, confirmem - esta semana, não numa futura auditoria - que as decisões de bloqueio e permissão do modo automático ficam registadas com o mesmo nível de detalhe probatório que o vosso registo anterior de aprovação humana tinha. O anúncio da Anthropic não aborda isto diretamente; verificar isso é tarefa da equipa que adota a ferramenta, não do fornecedor, antes que "removemos os pedidos de permissão" se torne a resposta a uma pergunta sobre supervisão de risco de TIC.

Leia a seguir: Uma mensagem alcançou as chaves SSH  |  A primeira plataforma de agentes de IA que a CISA obriga a corrigir