Um agente isolado não é um agente seguro

Existe um tipo específico de confiança que um time concede no momento em que deixa um agente de IA ler um repositório, tocar um sistema de arquivos ou rodar comandos numa máquina. O fornecedor chama isso de sandbox, sessão isolada, ou promessa de que o código não sai da máquina local. Engenheiros leem essas palavras como uma fronteira de segurança. Em 2026, com frequência incômoda, elas se revelam mais próximas de uma descrição de intenção do que uma descrição do produto que de fato foi lançado.

Duas denúncias no mesmo mês tornaram essa diferença visível em duas ferramentas sem relação entre si. Nenhuma das empresas construiu isso para falhar. As duas lançaram ferramentas de agente mais rápido do que verificaram o que elas realmente faziam com o acesso que recebiam.

O que "isolado" prometia, e o que entregou

O Claude Cowork, produto de agente de código local da Anthropic, executa o agente dentro de uma máquina virtual Linux no Mac do usuário. A proposta é contenção: o agente trabalha dentro da VM, o host fica fora de alcance. Em 23 de julho, pesquisadores de segurança da Accomplish AI divulgaram o SharedRoot, uma cadeia de ataque que rompeu essa contenção. O daemon root da VM monta a pasta que o usuário conecta ao Cowork dentro do convidado como um sistema de arquivos compartilhado e gravável. Encadeado com a CVE-2026-46331, uma falha no kernel Linux no subsistema de edição de pacotes act_pedit que já era pública havia semanas, um processo sem privilégios dentro da VM conseguia chegar a root do convidado e, a partir daí, ler e gravar em todo o compartilhamento — chaves SSH e credenciais de nuvem incluídas. Os pesquisadores relataram que uma única mensagem curta numa sessão nova bastava para disparar a cadeia, sem nenhum aviso de permissão em qualquer etapa.

A resposta da Anthropic, segundo a cobertura, encerrou a denúncia como "informativa", sem lançar uma correção dedicada para o caminho local. A versão mais recente do Cowork agora usa execução em nuvem por padrão, o que tira a VM local da equação na maioria das sessões novas — uma mitigação real, mas que desloca a fronteira de confiança em vez de fechá-la. Quem ainda roda o Cowork localmente, e quem o rodou antes da mudança de padrão, ficou exposto a uma falha de kernel já conhecida através de um compartilhamento de arquivos que não distinguia "a pasta que você conectou" do "resto da sua máquina".

O que "local" prometia, e o que entregou

O segundo caso é um tipo de falha completamente diferente. O Grok Build CLI, da xAI, se vende, como a maioria dos agentes de código, com a premissa de que atua em nome do usuário dentro do próprio ambiente dele. O pesquisador independente @cereblab passou a versão 0.2.93 por um proxy de rede e encontrou a ferramenta enviando muito mais dado do que qualquer tarefa exigiria. Num teste, um repositório de 12 GB gerou cerca de 5,1 GB de tráfego para um bucket do Google Cloud Storage chamado grok-code-session-traces — contra 192 KB no canal real do modelo. Essa proporção, documentada numa análise em nível de rede, não é compatível com a leitura seletiva dos arquivos que uma tarefa precisava. É compatível com o envio do repositório inteiro, histórico de commits incluído, junto com qualquer segredo já commitado e depois removido de um arquivo rastreado.

A xAI desativou a flag de upload no lado do servidor assim que a análise se tornou pública, mas pesquisadores observaram que o trecho de código que permite o envio continua no binário distribuído, controlado apenas por uma flag que a xAI pode reativar sem lançar uma nova versão. Quem rodou o CLI dentro de um repositório git antes da denúncia precisa tratar toda credencial já commitada ali — atual ou histórica — como potencialmente em mãos da xAI.

O padrão não é o bug. É a distância entre os dois.

Nenhuma das empresas planejou isso. Isolar um agente dentro de uma VM é uma decisão de design razoável; enviar contexto de sessão para depuração ou melhoria de produto é uma prática comum em produtos de nuvem. O que os dois casos têm em comum é a distância entre a afirmação que um engenheiro razoável inferiria — "isolado", "seu código fica com você" — e o comportamento real e verificável do produto lançado. Nenhuma das duas lacunas foi encontrada pelo próprio fornecedor. As duas foram encontradas por pesquisadores externos que rodaram a ferramenta e observaram o que ela de fato fazia.

Essa é a lição operacional, e ela tem pouco a ver com escolher outro fornecedor. O próximo agente de código vai fazer uma promessa parecida, e algumas dessas promessas também vão se revelar mais aspiracionais do que arquiteturais. A adoção dessa categoria de ferramenta está correndo bem à frente da disciplina de verificação que os times normalmente aplicam antes de conceder acesso amplo a sistema de arquivos ou rede a qualquer outra coisa.

Trate a ferramenta de agente como um novo fornecedor, não como uma nova configuração

A maioria das organizações de engenharia já tem um processo para integrar um novo fornecedor de SaaS que vai tocar dados sensíveis: uma revisão do fluxo de dados, uma pergunta sobre onde os dados ficam, uma decisão sobre o que ele pode ver. CLIs de agente e assistentes de código costumam pular esse processo. Eles são instalados como se instala um linter — um comando, e minutos depois a ferramenta tem acesso a sistema de arquivos, a shell e, muitas vezes, a rede, dentro de um repositório que também guarda meses de segredos acumulados.

Uma lista curta e concreta é mais útil aqui do que um apelo genérico à cautela:

• Verifique a alegação de isolamento, não apenas leia. "Sandboxed", "isolado em VM" e "roda localmente" descrevem arquiteturas diferentes, com garantias reais diferentes. Pergunte qual é a fronteira de fato — um container, uma VM, um namespace — e trate o histórico de divulgações de segurança do fornecedor como parte da resposta, não como nota de rodapé.
• Observe a rede, não só o diálogo de permissão. Um proxy ou um log de saída de rede em qualquer máquina que rode ferramenta de agente mostra, numa tarde, se a ferramenta envia o que diz enviar. Foi exatamente assim que as duas denúncias acima surgiram — não por auditoria do fornecedor, mas por alguém de fora observando o tráfego.
• Assuma que o histórico commitado não é privado, mesmo com a árvore de trabalho limpa. Todo segredo já commitado num repositório que um agente tocou deve ser tratado como exposto e rotacionado, esteja ou não presente nos arquivos atuais.
• Leia "encerrado como informativo" como uma delimitação de escopo, não como atestado de segurança. Um fornecedor decidir que uma denúncia não atinge o limite do seu programa de recompensas é uma decisão de negócio sobre limiar de severidade. Não é evidência de que a exposição deixou de existir para quem manteve a configuração antiga.
• Reavalie a cada mudança de padrão. Quando um fornecedor muda discretamente o padrão de execução local para nuvem, isso altera quais dados saem da máquina e para onde vão — uma decisão nova a avaliar, não uma correção a comemorar e esquecer.

A lição sobrevive ao fornecedor

As duas empresas provavelmente vão corrigir esses problemas específicos, se ainda não corrigiram. Esse não é realmente o ponto. O ponto é que "agente de IA com acesso local amplo" já é uma categoria permanente de ferramenta dentro da maioria das organizações de engenharia, adotada mais rápido do que a maioria dessas organizações construiu o músculo para avaliar. Dois fornecedores foram flagrados no mesmo mês não porque são descuidados fora do comum, mas porque pesquisadores de fora finalmente olharam.

Um sandbox é uma alegação sobre arquitetura. Se ela se sustenta é uma pergunta empírica, e até uma organização de engenharia checar isso de fato, conceder acesso a um agente não é uma decisão de segurança — é uma aposta de que o texto de marketing e o código lançado concordam entre si.