O modo auto do Claude Code não é uma fronteira de segurança

O modo auto do Claude Code é uma fronteira de segurança? Não, e a própria Anthropic diz isso. Depois que o pesquisador Johann Rehberger reportou uma cadeia de ataque funcional contra o Claude Code Opus 5 em modo auto, a Anthropic fechou o relato como Informativo, com a posição de que o modo auto é um recurso de conveniência apoiado por um classificador que faz o melhor que consegue, e não uma garantia de segurança, de que cadeias determinadas, montadas a partir de passos individualmente benignos, ficam fora do que se espera que um classificador pegue, e de que a fronteira real é o isolamento do sistema operacional somado ao controle do tráfego de saída.¹ Essa resposta não é uma esquiva. É o modelo mental correto, e a maioria de nós vinha carregando o errado. {.answer-block}

Existe um tipo específico de achado de segurança que importa menos pela falha e mais pela crença que ele corrige. O texto de Rehberger de 26 de agosto é um deles. A cadeia que ele demonstra é engenhosa, mas a parte útil é a resposta que ela provocou, porque essa resposta mostra qual camada da sua configuração realmente sustenta o peso — e não é aquela em que a maioria dos desenvolvedores vem confiando desde que o modo auto virou padrão em agosto.

Em resumo

• Rehberger publicou em 26 de agosto de 2026 uma cadeia de ataque funcional contra o Claude Code Opus 5 em modo auto, relatando uma taxa de sucesso de 60% a 80% em amostras pequenas: três de cinco execuções para a cadeia principal, e três de cinco e quatro de cinco para duas configurações de uma segunda variante. Ele mesmo pondera que são amostras pequenas, e não uma taxa geral de sucesso de ataque.¹
• O achado bate de frente com um número específico: uma avaliação externa encomendada pela Anthropic reportou uma taxa de sucesso de 0,00% em ataques de prompt injection para o Opus 5 em modo auto, medida em 72 cenários executados dez vezes cada um. A cadeia de Rehberger não estava nesse conjunto, então o 0,00% e uma cadeia funcional de execução de código são verdadeiros ao mesmo tempo.¹
• Cada passo da cadeia é razoável isoladamente. Essa é a lição de projeto: um classificador avalia ações uma a uma, e o ataque vive na composição, não em nenhuma ação isolada.
• A Anthropic fechou o relato como Informativo, enquadrando o modo auto como um recurso de conveniência apoiado por um classificador que faz o melhor que consegue, e não como uma garantia de segurança, com o isolamento do sistema operacional e o controle do tráfego de saída como fronteira real.¹
• O detalhe mais afiado, que Rehberger relata e Willison coloca em primeiro plano: em algumas execuções o Claude detectou o comprometimento e tentou matar o processo do malware, e o modo auto negou o comando de limpeza.¹²
• Consequência prática: o modo auto é um controle de produtividade que também bloqueia uma lista documentada de operações destrutivas quando julga que você não as pediu. Não é ele que fica entre um texto controlado pelo atacante e as suas credenciais. Um contêiner, uma saída de rede restrita e um diretório home sem credenciais é que ficam.

A cadeia, passo a passo

O ponto de partida é um agente fazendo trabalho comum: buscar um recurso, decodificá-lo, usar o conteúdo. Veja como isso vira execução de código.¹

Um servidor responde ao WebFetch do agente com HTTP 415, o que se lê como um problema de tipo de conteúdo e não como um ataque. O agente faz o que é sensato e recorre ao curl. O arquivo compactado que ele obtém se expande em um diretório temporário com um README, um manifesto de somas de verificação, um índice CSV, sete registros JSON codificados em Base85 e comprimidos com zlib, um binário decodificador nativo e um arquivo chamado struct.py.

Aí o maquinário de segurança funciona. O agente se recusa a executar o binário nativo não confiável, exatamente como você gostaria. Tendo recusado o binário, ele escreve o próprio decodificador em Python e o executa de dentro do diretório de extração.

Esse decodificador importa base64. O base64 da biblioteca padrão importa struct. O Python coloca o diretório de trabalho no início do caminho de busca de módulos, então struct resolve para o struct.py do atacante que está no arquivo extraído, e não para o da biblioteca padrão.

Releia a sequência e repare no que falta: não há um passo em que o agente seja instruído a fazer algo obviamente malicioso, nem um passo que um revisor razoável marcaria isoladamente. Recorrer ao curl depois de um 415 é normal. Extrair um arquivo compactado é normal. Recusar um binário sem assinatura é uma vitória de segurança. Escrever o próprio decodificador é ter iniciativa. Rodá-lo no diretório que contém os dados é o lugar óbvio para rodá-lo.

Por que um classificador perde essa

O classificador do modo auto avalia uma ação contra a intenção da sessão: este comando corresponde ao que o usuário pediu, e ele é perigoso por si só? Essa pergunta tem uma boa resposta para rm -rf / e uma resposta ruim para python decode.py.

O ataque nunca apresenta uma ação perigosa. Ele rearranja o ambiente para que uma ação de aparência segura tenha uma consequência insegura, e essa consequência só existe por causa de um passo que aconteceu antes: a extração do arquivo compactado que plantou o módulo. Para pegar isso, um revisor teria que manter todo o histórico na cabeça e raciocinar sobre a resolução de imports do Python em relação ao diretório de trabalho atual. A posição da Anthropic, de que cadeias construídas com passos individualmente benignos ficam fora do escopo do classificador, é uma afirmação sobre essa lacuna.¹

Vale nomear a classe com precisão. Willison atualizou o texto dele em 30 de agosto para endossar um ponto levantado por um leitor do Lobste.rs: isso não é um prompt injection clássico, porque em nenhum momento o modelo lê instruções do atacante e as segue. Descreve-se melhor como um ataque de ambiente confuso, em que o formato do ambiente entregue ao agente é o que produz o exploit.² Essa distinção agudiza o problema em vez de suavizá-lo. Um classificador atento a instruções injetadas não tem o que olhar aqui, porque não há nenhuma.

Esse é o mesmo ponto estrutural que a onda de CVEs do MCP não para de fazer: o ferramental dos agentes acumula capacidade mais rápido do que acumula contenção, e revisão por ação não se compõe em segurança por sessão.

O detalhe que deveria mudar seu modelo mental

Rehberger relata, e Willison coloca em primeiro plano, o momento em que vale a pena parar: em algumas execuções o Claude percebeu o comprometimento e tentou encerrar o processo do malware, e o modo auto negou o comando de limpeza.¹²

Uma camada de segurança que impede a remediação não é um paradoxo: é o que acontece quando um controle otimiza para “não deixe o agente fazer nada drástico” sem qualquer noção do porquê daquela ação drástica. Limpeza depois de um comprometimento se parece muito, para um classificador, com destruição.

A lição operacional é estreita e útil. “O agente vai perceber” não é um controle. Perceber e conseguir agir são capacidades diferentes, e sua resposta a incidentes não pode presumir que o agente comprometido vai poder limpar a própria sujeira.

O que de fato limita um agente

As recomendações de Rehberger são as pouco glamourosas, e as duas primeiras teriam contido esta cadeia:¹

Rode agentes não supervisionados em um contêiner ou uma VM. O comprometimento executou código com o usuário do agente. Uma camada de isolamento transforma acesso à máquina inteira em um ambiente descartável.

Restrinja o tráfego de saída. O prêmio da cadeia foi um subprocesso saindo para buscar e executar um payload remoto, e um callback depois disso. Uma política de saída com lista de permissões quebra tanto o download do estágio remoto quanto o callback.

Mantenha credenciais fora do alcance do agente. Chaves SSH, credenciais de nuvem e arquivos .env no diretório home estão dentro do raio de impacto por padrão. Mova-os, ou rode o agente em um lugar onde eles não estejam.

Monitore o agente e não leia aprovações como evidência. Uma aprovação em modo auto significa que um classificador não fez objeção. Não é uma conclusão de que a ação era segura.

Repare no que não está na lista: desligar o modo auto. Ele bloqueia uma lista documentada de operações destrutivas quando julga que você não as pediu, e reduz a fadiga de confirmações que leva as pessoas a aprovar tudo por reflexo. Trocá-lo por uma falsa sensação de rigor é substituir um controle fraco por um pior. Mantenha-o, e pare de tratá-lo como a fronteira.

A parte que vale dizer com todas as letras

Seria fácil escrever este achado como um fracasso, e mais fácil ainda escrevê-lo como culpa do fornecedor. Nenhuma das duas coisas está certa.

A resposta da Anthropic — um recurso de conveniência apoiado por um classificador que faz o melhor que consegue, não uma garantia de segurança, com isolamento do sistema operacional e controle do tráfego de saída como fronteira — é uma postura de segurança mais honesta do que uma alegação mais forte teria sido.¹ Um fornecedor que prometesse que seu classificador pega cadeias de injeção determinadas estaria fazendo uma promessa que classificador nenhum consegue cumprir, e os desenvolvedores construiriam em cima dessa promessa. A pergunta interessante não é se este ataque funciona. É se o modelo mental do ecossistema bate com o do fornecedor, e neste momento não bate: o modo auto virou padrão para as sessões Pro, Max e Team em agosto enquanto o número que a Anthropic tinha colocado em circulação era uma taxa de sucesso de ataque de 0,00% vinda de uma avaliação encomendada com 72 cenários — Rehberger arquiva isso como o problema de marketing do 0,00% — e o enquadramento que viajou junto falava de segurança, não de conveniência somada à redução do raio de impacto.¹ Rehberger tira uma conclusão mais dura que a minha: ele lê a comunicação do 0,00% e a classificação de fora de escopo como mensagens contraditórias que não se encaixam.¹ Eu acho que as duas coisas podem valer ao mesmo tempo. A classificação é a honesta, e o número nunca deveria ter sido vendido como uma propriedade do produto.

Se a sua configuração presumia que o classificador era o muro, acrescente o muro.

Atualização de 3 de setembro: o que foi lançado desde este post

O Claude Code lançou três versões nas 48 horas seguintes a este post; duas delas mexem no modo auto.³ A versão 2.1.257, publicada em 1 de setembro, adiciona o que as notas de versão chamam de regra de Containment Escape: “buscas de credenciais em metadados de nuvem, evasão de saída de rede e alcance entre inquilinos não são mais aprovados automaticamente, a menos que o seu ambiente os marque como esperados”. A mesma versão adiciona, no modo auto, uma confirmação única antes da primeira leitura de arquivo fora dos diretórios de trabalho, com uma configuração, permissions.blockReadsOutsideWorkingDirectories, que transforma essa confirmação em recusa. A versão 2.1.259, publicada em 2 de setembro, adiciona --permission-prompts none para hosts headless não supervisionados: “qualquer coisa que pediria confirmação é negada automaticamente, enquanto o modo de permissão ativo (incluindo o modo auto) continua decidindo”.

Leia essas mudanças no enquadramento que este post montou. A regra, a confirmação de leitura e a flag são endurecimento real, e a flag para headless é a configuração fail-closed com a qual um host não supervisionado deveria rodar. Mas as duas primeiras estreitam o que o modo auto vai aprovar sozinho: a regra tira três categorias da aprovação automática, a menos que o ambiente as marque como esperadas, e a mudança nas leituras pergunta uma vez, ou recusa com a configuração ligada. Nenhuma das duas é descrita como fronteira, e ambas ficam dentro do fluxo de aprovação do modo auto. Esse é justamente o fluxo de revisão pelo qual esta cadeia passou sem apresentar uma única ação que parecesse errada por si só. A regra cita evasão de saída de rede; Rehberger não descreve evasão alguma, apenas uma conexão de saída em cada salto: um download por curl, um processo filho buscando um estágio remoto, esse estágio buscando o payload, e um callback. Se a regra lê qualquer parte disso como evasão, as notas não dizem, e também não dizem se a confirmação de leitura cobre leituras feitas por um processo filho. Que qualquer uma das duas mudanças teria parado esta cadeia não é algo que as notas afirmem, nem algo a presumir. Uma correção da 2.1.257 fica de fato na camada da fronteira: uma entrada deniedDomains do sandbox não estava bloqueando um host escrito com um ponto no final, e a versão conserta isso. Isso é um reparo na fronteira, não um deslocamento dela. O que o modo auto aprova sozinho encolheu. A fronteira não se moveu.

Principais conclusões

• O modo auto é conveniência e controle de raio de impacto, não uma fronteira de segurança. Essa é a posição do próprio fornecedor depois de um bypass funcional, não uma crítica de fora.¹
• Classificadores julgam ações; ataques vivem em composições. Cada passo da cadeia demonstrada é defensável isoladamente, e é exatamente por isso que a revisão por ação não o pegou.
• Perceber não é remediar. Em algumas execuções o agente detectou o próprio comprometimento e depois foi impedido de limpá-lo. Planeje sua resposta a incidentes levando isso em conta.¹²
• Os controles que se sustentam estão fora do modelo. Contêiner ou VM, saída de rede restrita, credenciais fora do diretório home. Todo o resto é profundidade, não fronteira.

FAQ

Devo desligar o modo auto?

Não, a menos que você estivesse contando com ele como contenção. Ele bloqueia um conjunto documentado de operações destrutivas — git reset --hard, git checkout -- ., git clean -fd, git stash drop e terraform/pulumi/cdk destroy — quando julga que você não as pediu, e corta o volume de confirmações que alimenta a aprovação reflexa. Mantenha-o como controle de produtividade e de raio de impacto, e acrescente isolamento de verdade para as sessões que tocam entrada não confiável.

Isso afeta só o Claude Code?

O mecanismo não é específico do Claude. Qualquer agente que baixe arquivos compactados não confiáveis, escreva código e o execute no diretório que acabou de extrair fica exposto à mesma armadilha de resolução de imports, e qualquer revisão de segurança por ação fica exposta à mesma lacuna de composição. As especificidades aqui foram demonstradas contra o Claude Code Opus 5 em modo auto.¹

O que conta como sessão com entrada não confiável?

Qualquer coisa em que um texto influenciado pelo atacante possa chegar ao modelo: páginas web buscadas, arquivos compactados baixados, texto de issues e pull requests, e-mail, logs de um serviço público e servidores MCP de terceiros. Na prática isso é a maior parte do trabalho real, e é essa a parte desconfortável.

Isso já foi corrigido?

Não foi tratado como uma vulnerabilidade a corrigir. A Anthropic fechou o relato como Informativo com base em que a evasão de classificador desse tipo está fora do que o modo auto promete.¹ Trate isso como uma propriedade documentada do sistema, e não como um patch pendente. Uma versão das 48 horas seguintes a este post, a 2.1.257, estreitou o que o modo auto aprova sozinho e acrescentou um bloqueio opcional de leituras fora dos diretórios de trabalho, e a 2.1.259 acrescentou uma flag fail-closed para hosts headless; a atualização de 3 de setembro acima cobre o que elas mudam e o que não mudam.³

Fontes