O Claude Code tentou se salvar. O modo automático impediu

O modo automático do Claude Code foi criado para reduzir a quantidade de decisões de segurança deixadas para quem programa. Um novo ataque relatado por Johann Rehberger sugere que essa proteção pode falhar de uma forma desconfortável: em alguns testes, o agente percebeu que havia sido comprometido, tentou encerrar o processo malicioso e teve o comando de limpeza bloqueado pelo próprio Auto Mode.

O caso importa para qualquer desenvolvedor brasileiro que esteja colocando agentes de código em repositórios reais. A promessa de produtividade é atraente. Mas um agente com acesso a arquivos, rede, credenciais e comandos de terminal também amplia a superfície de um ataque de cadeia de suprimentos.

O que o Auto Mode pretende resolver

O Auto Mode substitui parte das aprovações manuais por um classificador de segurança. Em vez de pedir confirmação para cada ação, o Claude Code avalia se um comando pode seguir adiante. A Anthropic passou a tratar esse modo como padrão e divulgou resultados fortes: uma avaliação de terceiros, encomendada pela empresa, registrou 0,00% de sucesso em ataques contra o Opus 5 com o Auto Mode ativado, em cenários predefinidos da avaliação.

Esse número ajuda a explicar a confiança no mecanismo. Também mostra por que a descoberta chamou atenção. Segurança de agentes não é só identificar um comando perigoso isolado. É entender uma sequência de ações que parece comum em cada etapa, mas produz uma consequência hostil no conjunto.

Simon Willison, que repercutiu a demonstração em 27 de agosto, descreve Johann Rehberger como um pesquisador reconhecido em prompt injection. Segundo o relato, Rehberger reportou até 80% de sucesso em uma pequena amostra; outras variantes ficaram em 60%. Esses resultados são uma alegação do pesquisador, não uma medição independente do Runzos. Ainda assim, o mecanismo apresentado merece atenção técnica. A demonstração de Embrace The Red detalha o ataque. Willison publicou os detalhes e a recomendação de isolamento.

Como um ZIP vira execução de código

O fluxo relatado começa quando o agente é induzido a baixar e descompactar um arquivo ZIP. Isso, por si só, parece uma tarefa ordinária em muitos projetos. O problema aparece depois: ao executar um código que importa o módulo Python base64, o interpretador pode carregar um arquivo local chamado struct.py, extraído anteriormente do ZIP malicioso.

Esse detalhe transforma uma ação aparentemente banal em execução de código controlado por terceiros. O ponto central não é que todo ZIP seja perigoso. O risco nasce quando um agente recebe instruções de conteúdo não confiável e trabalha com permissões suficientes para baixar, extrair e executar artefatos sem uma barreira externa.

É aí que prompt injection deixa de ser uma discussão abstrata. Um arquivo, uma documentação copiada, uma issue ou uma dependência pode carregar instruções destinadas ao agente. Se ele interpreta esse material como orientação operacional, a automação passa a operar dentro do caminho definido pelo invasor.

A falha mais preocupante aconteceu na limpeza

Na demonstração, houve execuções em que o Claude detectou o comprometimento e tentou encerrar o processo malicioso. O Auto Mode negou o comando de limpeza. Na leitura de Willison, o classificador permitiu a criação do processo e depois bloqueou a ação que buscava interrompê-lo.

Esse é o trecho que muda a conversa. Uma camada de segurança que decide quais comandos passam precisa funcionar bem em contextos que mudam rápido. Um comando de encerramento pode parecer suspeito fora de contexto. Depois de uma invasão detectada, porém, ele pode ser a ação mais importante disponível.

A lição não é desligar todo recurso automático. É evitar transformar o classificador em última linha de defesa. Um agente capaz de agir sozinho deveria ter permissões limitadas antes de receber uma tarefa. Quando essa limitação depende apenas da interpretação do próprio agente, o erro pode ficar caro.

O recado para quem usa agentes em projetos brasileiros

Em equipes pequenas, é comum que a máquina de desenvolvimento reúna chaves SSH, acesso à nuvem, variáveis de produção e diretórios pessoais. Esse ambiente é conveniente para programar. Também concentra ativos demais para um agente que pode processar conteúdo adversarial.

A recomendação operacional destacada por Willison e Rehberger é clara: rodar agentes desacompanhados em contêiner, máquina virtual ou sandbox do sistema operacional. O ambiente deve restringir a saída de rede, ser monitorado e não expor diretórios pessoais, chaves SSH ou credenciais de nuvem ao processo do agente.

Para quem já experimenta ferramentas autônomas, vale comparar essa arquitetura com o uso local de assistentes de terminal. O guia do Runzos sobre ChatGPT no Linux e OpenAI Codex ajuda a situar onde esses agentes entram no fluxo de desenvolvimento. A diferença decisiva está no escopo: sugerir código é uma coisa; baixar arquivos e executar comandos em nome do usuário exige outra camada de controle.

Produtividade com agentes depende de confiança, mas confiança não substitui contenção. O episódio do Auto Mode reforça uma regra simples para repositórios reais: se existe chance de conteúdo hostil chegar ao agente, o ambiente precisa assumir que algo pode dar errado e limitar o estrago possível.

O que revisar antes de ativar o modo automático

Antes de entregar autonomia a um agente de código, confira quatro pontos. Primeiro, rode-o em ambiente isolado. Segundo, entregue apenas as credenciais necessárias para aquela tarefa. Terceiro, limite a rede quando não houver razão para acesso externo. Por fim, monitore arquivos criados, comandos executados e conexões abertas.

O ataque relatado ainda precisa ser acompanhado por reproduções e respostas técnicas da Anthropic. Mas o alerta já é útil. O modo automático pode reduzir atrito no desenvolvimento. Ele não elimina a necessidade de uma sandbox bem configurada.