Elton José logo
Elton José
Claude Code

Permissões Que Você Escreve Como Frase: Como Funciona O Novo Auto Mode Do Claude Code

Permissões Que Você Escreve Como Frase: Como Funciona O Novo Auto Mode Do Claude Code
0 visualizações
17 minutos de leitura
#Claude Code

Permissões Que Você Escreve Como Frase: Como Funciona O Novo Auto Mode Do Claude Code

Tem uma discussão que se repete em praticamente todo time que já escreveu uma política de acesso: a frase que parecia óbvia para quem escreveu vira ambígua para quem lê. "Ninguém mexe em produção sem revisão" soa como regra fechada até alguém perguntar se uma query de leitura conta como "mexer", se um ambiente de homologação com nome parecido está incluído, se "revisão" significa aprovação formal ou só um aviso no canal. Já vi essa conversa em runbook, em política de IAM, em regra de firewall descrita em português para depois virar YAML. O texto nunca é o problema; a tradução dele em decisão automática é.

Foi essa lembrança que me veio quando li, na semana passada, que o Claude Code trocou o modo padrão de execução para o chamado auto mode e que parte das regras de allow e deny, antes sintaxe fixa, agora podem — numa camada específica do sistema — ser escritas como frase solta, em linguagem natural, para um classificador interpretar. Não é a mesma coisa que a discussão do runbook, mas é o mesmo problema de fundo: alguém escreve uma frase pensando numa intenção, e outra coisa — agora um modelo, não uma pessoa — decide o que ela cobre.

Este post é um estudo sobre esse mecanismo, não um relato de uso. Não configurei o auto mode nem testei as regras na prática — o que segue vem da documentação oficial da Anthropic, do post de engenharia em que o time explica como o classificador foi construído, e da cobertura de outros veículos desde o anúncio. Onde eu incluir um cenário de time escrevendo uma regra, deixo marcado que é exemplo hipotético — não teste que rodei.

Quero cobrir como o auto mode decide o que roda sem perguntar, onde exatamente entra a tal "regra escrita como frase" — mais restrita e mais específica do que a manchete sugere — e por que a folga entre o que uma frase parece dizer e o que ela de fato autoriza é onde mora a maior parte do risco.


O Que A Anthropic Trocou De Fato No Claude Code

Até pouco tempo atrás, o comportamento padrão do Claude Code era pedir aprovação a cada ferramenta nova: cada comando de shell, cada escrita de arquivo, cada chamada de rede parava a sessão esperando um "sim". Seguro, mas caro em atenção — a própria Anthropic documentou, em post de engenharia de março, que os usuários aprovavam 93% dos prompts, o sintoma clássico de fadiga de aprovação: a pessoa para de julgar e passa a clicar "sim" por hábito. Uma reportagem de agosto atualizou esse número para 97%.

O auto mode nasceu em março como preview de pesquisa e ficou disponível de forma geral em julho. A partir de 14 de agosto de 2026 passou a ser o modo padrão para novas sessões nos planos Pro, Max e Team — a TechCrunch confirmou a data e citou Boris Cherny, à frente do Claude Code, dizendo que o time interno usa auto mode exclusivamente há meses e "não conseguiria voltar" aos prompts. Em Enterprise, na API da Anthropic e em provedores como Bedrock, Google Cloud e Microsoft Foundry, o modo segue opcional por enquanto, com plano de virar padrão também ali, segundo o The Register.

O mecanismo central é um classificador — modelo à parte, rodando sobre o Sonnet 4.6, cuja única função é revisar cada chamada de ferramenta antes dela executar. A Anthropic descreve duas camadas: a primeira lê o resultado de ferramentas — arquivo, web fetch, saída de comando — antes de entrar no contexto do agente, procurando sinais de sequestro de comportamento (prompt injection). A segunda, o "transcript classifier", avalia cada chamada pendente em duas etapas: um filtro rápido de um único token, treinado para pender ao bloqueio, seguido — só quando sinaliza risco — de uma passada com raciocínio completo, mais cara e mais precisa. A maioria das ações passa pela primeira etapa sem acionar a segunda.

O critério é especificamente comportamento "irreversível, destrutivo, ou direcionado para fora do seu ambiente". No post de engenharia, o time separa quatro motivos pelos quais um agente toma ação perigosa: excesso de zelo (ajuda além do autorizado), erro honesto de escopo (acha um recurso isolado quando é compartilhado), injeção de prompt externa, e desalinhamento genuíno — o caso mais raro. O classificador foi ajustado para os dois primeiros, que aparecem no log interno de incidentes: um branch remoto apagado por interpretação livre de "limpar branches antigas", um token de engenheiro subindo para um cluster interno, uma tentativa de migração contra banco de produção.

Nos testes publicados, comparando o classificador com revisão humana num estudo controlado com 1.053 testadores pagos, humanos identificaram um comando perigoso plantado deliberadamente em 13,6% das vezes; o auto mode bloqueou 89%. Em tráfego real interno (10 mil chamadas), o pipeline completo chegou a 0,4% de falso positivo. No conjunto de ações "excessivamente zelosas" reais, a taxa de falso negativo foi 17% — número que a própria Anthropic chama de "o honesto": em boa parte desses casos, o classificador identifica a ação como arriscada, mas erra ao avaliar se o consentimento na conversa cobre o alcance daquela ação específica.


Onde As Frases Entram: Ambiente, Allow E Deny Como Prosa

Aqui está o ponto que a manchete resume bem e que vale destrinchar, porque existem duas camadas de regra no Claude Code e só uma delas funciona como frase solta.

A camada mais antiga, que já existia antes do auto mode, é o sistema de permissões clássico: regras de allow, ask e deny com sintaxe de padrão sobre ferramenta, do tipo Bash(git push *) ou Read(./.env). Isso continua existindo como sempre foi — é sintaxe, não frase, e é avaliada antes de qualquer classificador entrar em cena. Uma regra ask sobre git push sempre força um prompt de confirmação, mesmo em auto mode; uma regra deny bloqueia antes do classificador ser consultado, e nem o classificador nem a intenção do usuário passam por cima dela.

A camada nova, específica do auto mode, é o bloco autoMode, com quatro listas: environment, allow, soft_deny e hard_deny. Aqui a documentação da Anthropic é explícita: "Entries are prose, not regex or tool patterns. The classifier reads them as natural-language rules." Cada item é uma frase, escrita como você descreveria sua infraestrutura para um engenheiro novo. Exemplo real, tirado da documentação, de como preencher o campo environment:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

O propósito do campo é dizer ao classificador o que conta como "dentro" do ambiente — por padrão, o único território confiável é o diretório de trabalho e os remotes já configurados do repositório atual. Qualquer destino fora disso é, para o classificador, risco potencial de vazamento até que alguém o nomeie.

As outras três listas seguem a mesma lógica de prosa, com precedência clara: hard_deny bloqueia de forma incondicional, sem exceção de allow nem de intenção do usuário; soft_deny bloqueia por padrão, mas pode ser liberado por uma exceção em allow ou por intenção explícita na conversa; allow é a lista de exceções ao bloqueio brando. Cenário hipotético de como um time poderia estender isso — uma equipe que roda pipeline de deploy via CLI própria e quer deixar isso claro para o classificador:

{
  "autoMode": {
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ]
  }
}

Vale registrar uma distinção que passa despercebida na cobertura mais rápida do assunto: o CLAUDE.md do projeto também alimenta o classificador diretamente, com o mesmo conteúdo que o próprio Claude lê. Uma instrução do tipo "nunca force push" escrita ali orienta o modelo e o classificador ao mesmo tempo — o que aproxima o auto mode do tema que já tratei em como os steering files e o CLAUDE.md moldam um projeto agêntico: a documentação de projeto passou a ser, além de contexto para humano, insumo direto de um mecanismo de controle.

Um detalhe técnico que muda a leitura de risco: nem toda regra de allow sobrevive à entrada em auto mode. Ao ligar o modo, o Claude Code descarta automaticamente regras amplas demais — acesso irrestrito a shell, interpretadores wildcard como python * ou node *, comandos genéricos de gerenciador de pacote — porque, se continuassem valendo, o classificador nunca chegaria a ver os comandos mais capazes de causar dano. Regras estreitas, como "permitir rodar formatador de código", continuam valendo normalmente. É uma escolha de design que reduz erro silencioso, mas o sistema decide sozinho o que descarta, por uma lista de padrões conhecidos que por definição é incompleta.


Os Limites Da Frase: Onde A Ambiguidade Custa Caro

A documentação da Anthropic é cuidadosa ao descrever como o classificador lê intenção explícita, e esse detalhe é o núcleo do risco real, mais do que a ideia solta de "a IA pode interpretar errado uma frase". A regra é: pedido geral não conta como autorização específica. Pedir para "limpar o repositório" não autoriza force-push; pedir "fazer force-push nessa branch" autoriza. O bloqueio brando (soft_deny) permanece de pé mesmo com a frase genérica na conversa.

Isso é, na teoria, proteção contra leitura larga demais. Mas o próprio relatório da Anthropic descreve o erro oposto na prática: em boa parte das 17% de falhas em ações zelosas demais, o classificador identifica a ação como arriscada, mas encontra "evidência com formato de aprovação" na conversa e para de checar se aquilo cobre o alcance da ação. Uma aprovação anterior parecida não é um padrão; "podemos consertar isso?" é pergunta, não diretriz — mas nem sempre o classificador segura essa distinção.

Pense num cenário hipotético que ilustra bem essa dinâmica: um squad de plataforma escreve, no campo soft_deny, a frase "não fazer deploy em ambiente de produção sem aprovação humana". Parece cobrir o óbvio. Mas o campo de sensibilidade que decide o que conta como "alvo remoto sensível" tem heurístico padrão — qualquer host ou namespace cujo nome contenha "prod" ou "production" — só substituído quando o time nomeia os alvos protegidos explicitamente. Se esse mesmo time, num cenário hipotético, batizou o ambiente real de produção de "live" por convenção interna antiga, a frase escrita continua tecnicamente correta e o heurístico não cobre o caso: o classificador nunca aprendeu que "live" é produção, porque ninguém disse isso a ele em nenhuma das três formas que ele lê — ambiente, sensibilidade, ou CLAUDE.md. A frase não estava errada; estava incompleta, do tamanho exato da suposição que ninguém verbalizou.

O caso oposto — regra larga demais — tem custo mais operacional que catastrófico, mas ainda real. Outro cenário hipotético: um time escreve em hard_deny "nunca tocar no banco de dados de produção", pensando em bloquear escrita. Como bloqueio incondicional, isso também impede leituras diagnósticas legítimas numa investigação de incidente. Cada tentativa bloqueada conta para o limite de três negativas consecutivas ou vinte no total, que ao ser atingido derruba a sessão de volta para aprovação manual; em modo não interativo (claude -p, usado em CI), o processo é encerrado em vez de esperar um humano que não existe ali. Uma frase pensada como proteção estrita pode quebrar uma automação que dependia de rodar sem parar.

Esses dois exemplos não são falha do classificador em si — são consequência de como regra em prosa funciona: cobre exatamente o que foi dito, não o que a pessoa quis dizer. É o mesmo problema do runbook que abre este post, só que agora o "leitor" processa milhares de chamadas por dia sem parar para perguntar "você quis dizer isso mesmo?" — exceto quando bate no limite de negativas e devolve a decisão para você. A ferramenta que a Anthropic recomenda para reduzir esse risco é claude auto-mode critique, revisão automática que sinaliza regras ambíguas, redundantes ou propensas a falso positivo — um linter de intenção, útil, mas que não substitui pensar no caso de borda antes de escrever a frase.


O Pacote Mais Amplo De Agosto

O auto mode virar padrão não veio sozinho; fez parte de uma leva de mudanças no Claude Code em agosto de 2026 que, juntas, desenham uma direção: menos fricção visível, mais decisão delegada.

A skill /design, preview de pesquisa desde 17 de agosto, traz o fluxo de artboards do Claude Design para o terminal: você descreve o que quer, o Claude publica uma tela com opções editáveis de interface, e a implementação segue da escolhida. O estilo "Concise", a partir da v2.1.237, vai direto ao resultado, cortando narração — mas mantém conteúdo completo em erro, aviso de segurança e confirmação de ação destrutiva, coerente com a lógica do resto do pacote. E o Claude Code passou a continuar sessões automaticamente quando um limite de uso é resetado, em vez de parar e esperar retomada manual.

Do lado de custo: em 10 de agosto a Anthropic tornou permanente o preço promocional do Claude Sonnet 5 — modelo padrão do Claude Code, com janela nativa de 1 milhão de tokens — de 2 dólares por milhão de tokens de entrada e 10 de saída, cancelando o reajuste para 3 e 15 previsto para 1º de setembro. E o aumento de 50% nos limites semanais, em vigor desde maio para Pro, Max, Team e Enterprise com seat, foi estendido pela terceira vez até 31 de agosto, com a Anthropic sinalizando intenção de tornar isso permanente.

Nenhuma dessas mudanças depende do auto mode, mas o conjunto ajuda a entender o momento: a Anthropic baixa o atrito de usar a ferramenta e, ao mesmo tempo, aumenta a superfície de decisão do lado de quem opera — porque baixar atrito em ferramenta agêntica quase sempre significa transferir julgamento de um clique explícito para uma configuração escrita com antecedência.


Autonomia Com Segurança: Onde Isso Se Encaixa

O recorte técnico do auto mode é interessante por si só, mas o motivo de eu achar que vale a pena entender o mecanismo com esse nível de detalhe é mais amplo: é o mesmo problema que já aparecia em outras peças do ecossistema de agentes, só que resolvido de um jeito específico — delegar a decisão de segurança a um segundo modelo, configurado por frase.

Já escrevi sobre a ideia de que autonomia de agente em produção precisa ser desenhada com limite explícito, não concedida de uma vez — o conceito de bounded autonomy como forma de dar segurança a agentes em produção. O auto mode é uma implementação concreta disso: em vez de "roda tudo" ou "pergunta tudo", desenha um limite móvel, definido pelo classificador e ajustável pelas frases de environment e soft_deny. A diferença é que aqui o limite não é só código de política — é também linguagem natural, e herda a ambiguidade que ela sempre teve fora de máquina nenhuma.

Há também conexão direta com o padrão que discuti em permission-hungry e a lethal trifecta em agentes: a combinação de acesso a dado sensível, capacidade de executar ação com efeito colateral e exposição a conteúdo não confiável. O desenho do classificador ataca essa combinação — a camada de prompt-injection filtra o terceiro elemento antes que contamine a decisão, e o bloqueio de exfiltração ataca os outros dois. Mas a lista de blocos default, por mais de vinte regras, continua sendo finita e escrita por gente que não conhece a infraestrutura do seu time — daí o campo environment existir, e a responsabilidade de preenchê-lo recair sobre quem opera, não sobre quem construiu a ferramenta.

E há uma tensão que já apontei em Claude Code, alta e o preço da confiança em ferramentas de IA: quanto mais a ferramenta funciona bem na maioria dos casos, menor a vigilância sobre os casos em que ela erra. É o mesmo mecanismo psicológico que levava à aprovação de 97% dos prompts manuais — agora aplicado a uma camada que deveria ser mais criteriosa, não menos. Se o time confia demais no classificador porque ele "quase sempre acerta", a revisão humana da configuração de environment e soft_deny — o único ponto onde ainda existe julgamento humano explícito nesse fluxo — corre o risco de receber a mesma atenção de carimbo que os prompts recebiam antes.


Conclusão

O que fica mais claro depois de estudar esse mecanismo é que "escrever permissão como frase" não é, como a manchete sugere à primeira leitura, substituir sintaxe por conversa informal. É um sistema de duas camadas — regra de padrão sobre ferramenta, que continua rígida, e regra de prosa sobre ambiente e intenção, nova e carregando a ambiguidade que qualquer texto em linguagem natural carrega. A Anthropic parece ciente disso: a documentação insiste em exemplos concretos, no comando critique para revisar frases escritas, e na distinção entre pedido genérico e intenção explícita. Isso não elimina o risco, mas mostra que ele foi reconhecido no desenho, não descoberto depois.

Não tenho como avaliar, a partir do que li, se 0,4% de falso positivo e 17% de falso negativo em ações zelosas demais é um patamar aceitável para o seu time — depende do que está em jogo em cada ambiente, e a própria Anthropic é explícita: o auto mode substitui bem o --dangerously-skip-permissions, mas não substitui revisão humana cuidadosa em infraestrutura de alto risco. O que dá para afirmar com mais segurança é que a qualidade da frase escrita em environment ou soft_deny é hoje um artefato de segurança, não um detalhe que se preenche uma vez e esquece. Ela envelhece como um runbook envelhece: quando o time renomeia um ambiente ou adota um serviço que ninguém lembrou de listar, a frase antiga continua tecnicamente correta e materialmente incompleta.

Talvez o ponto mais honesto para fechar seja este: dar mais autonomia a um agente sempre foi uma aposta em quão bem a intenção humana se traduz em algo que a máquina execute sem checar de novo a cada passo. Sintaxe fixa força a pessoa a ser explícita demais para ser prática; frase solta deixa a pessoa ser natural demais para ser precisa. O auto mode escolheu o segundo lado dessa troca, com um classificador tentando cobrir a distância entre os dois. Se essa aposta se paga depende menos do modelo que julga as ações e mais de quanto cuidado cada time coloca nas poucas frases que realmente decidem o que ele pode fazer sozinho.

Fontes:

Newsletter

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

Um resumo semanal com os melhores posts sobre IA, engenharia de software e tecnologia, enviado no melhor momento para continuar a conversa depois da leitura.

Foto de Elton José

Escrito por

eltonjose

Engenheiro de software e estrategista de produtos digitais, focado em IA pragmática e em transformar experiências de trabalho remoto em aprendizados aplicáveis. Compartilho frameworks e decisões reais que uso em consultorias e projetos.

  • Principais temasClaude Code, Agentic AI
  • Formato do conteúdoGuia prático + insights de carreira