Toda história de fuga anterior era sobre a parede falhando. Esta é sobre a parede aguentando, e a fuga acontecendo mesmo assim. O agente obedeceu à sandbox, escreveu um arquivo que tinha permissão de escrever, e um programa confiável do outro lado da parede pegou esse arquivo e o executou.

Um agente de código roda numa sandbox para que, quando fizer algo imprudente — e fará, porque lê texto não confiável o dia todo e acredita na maior parte dele —, o dano pare na parede da sandbox. Essa é a promessa. Em 20 de julho de 2026, a Pillar Security publicou sete formas pelas quais a promessa se quebra, em quatro dos agentes mais usados: Cursor, o Codex CLI da OpenAI, o Gemini CLI do Google e o Antigravity. O BleepingComputer cobriu o caso na mesma semana.

Sete não é o número surpreendente. O que os sete têm em comum é: nas palavras dos próprios pesquisadores, "em quase todos os casos, o agente não precisou quebrar a sandbox diretamente. Bastou escrever algo que um componente confiável fora da sandbox mais tarde executaria, carregaria, analisaria ou trataria como seguro."

A jogada: ficar dentro, escrever um arquivo, deixar o host executá-lo

Pense no que a sandbox de um agente de código realmente contém. Ela contém o processo do agente — aquilo que executa as decisões do modelo. Ela não contém os arquivos do agente, porque todo o trabalho é escrever arquivos: código-fonte, configurações, scripts de build. Esses arquivos vão parar no mesmo disco que suas outras ferramentas leem. E suas outras ferramentas não estão numa sandbox. A extensão Python do seu editor não está numa sandbox. Seu git não está numa sandbox. O daemon do Docker não está numa sandbox. Elas confiam no que está no disco, porque até recentemente a única coisa que escrevia nesse disco era você.

Então o agente nunca toca na parede. Ele escreve um arquivo exatamente onde deve, e espera que algo do outro lado o leia. As sete fugas da Pillar são sete versões dessa mesma jogada:

Uma configuração de hook que executa

No Cursor, o agente escreve uma configuração de hook .claude do espaço de trabalho. Hooks devem executar comandos em eventos do editor — então o comando desse arquivo executa, fora da sandbox. Recebeu CVE-2026-48124, corrigida no Cursor 3.0.0.

Um interpretador Python, trocado

O agente edita o interpretador dentro do ambiente virtual de um projeto. A extensão Python do editor — fora da sandbox — o invoca mais tarde, e o binário trocado executa. Rastreado como GHSA-p9g2-cr55-cw9c.

Um comando git confiável pelo nome

A lista de permissão de "comandos seguros" do Codex CLI liberou uma invocação git porque o nome parecia benigno, sem ler os argumentos que a tornavam perigosa. Corrigido no Codex CLI 0.95.0.

Um daemon que é uma segunda máquina

Em vários agentes, o socket do Docker era acessível de dentro da sandbox. Um daemon local privilegiado é todo um segundo lugar para executar código, logo fora da fronteira. Rastreado como GHSA-v4xv-rqh3-w9mc.

O Antigravity acrescentou mais duas do mesmo formato — uma lista de negação do Seatbelt do macOS que deixou passar um caso, e uma configuração de tarefa do VS Code que o agente escreveu e que a IDE depois executou por conta própria. Ambas foram consideradas mais difíceis de realizar, mas rimam com o resto.

A fuga que não é uma fuga. O agente permanece dentro da sandbox e segue todas as regras (à esquerda). Ele escreve um arquivo comum e permitido — uma configuração de hook, um interpretador de ambiente virtual, uma configuração do git, uma definição de tarefa — no disco compartilhado. Uma ferramenta confiável no host que não está numa sandbox — a extensão do editor, o git, o daemon do Docker, o executor de tarefas da IDE — lê esse arquivo como parte do seu trabalho normal e executa o que ele nomeia (à direita). O comando executa fora da sandbox sem que a sandbox jamais seja tocada.

Por que corrigir cada uma não fecha o formato

Cada uma delas recebeu uma correção, e são boas correções. O Cursor lançou a 3.0.0, o Codex CLI lançou a 0.95.0, o socket do Docker foi trancado. Se você usa essas ferramentas, atualize-as. Mas veja o que uma correção precisa fazer aqui. Ela precisa encontrar todo arquivo que o agente pode escrever e que algum outro programa trata como instruções — configurações de hook, caminhos de interpretador, metadados do git, definições de tarefa, regras de lint, o que quer que venha no próximo trimestre — e tratar cada um como um caso especial. Isso é uma lista de negação, e a Pillar aponta as listas de negação como o primeiro de quatro modos de falha recorrentes porque "um perfil de sandbox que parte de 'permitir por padrão' tem de lembrar de cada operação perigosa que o SO expõe". O SO não para de adicionar operações. A lista nunca está completa.

A razão mais profunda é uma frase do relatório que se lê como uma definição: "Se um agente pode escrever as entradas futuras dos sistemas, ele nunca esteve numa sandbox para começar." Uma fronteira traçada em torno do processo do agente, numa máquina onde o agente compartilha um disco e um conjunto de daemons confiáveis com todo o resto, está traçada em torno da coisa errada. O raio de alcance, escrevem eles, "não é o processo do agente; inclui tudo o que o agente pode escrever e no que o host depois confia". No laptop de um desenvolvedor, isso é quase tudo.

Onde o Bromure traça a linha

O Bromure Agentic Coding não tenta enumerar os arquivos perigosos, nem ensinar a sandbox sobre hooks, ambientes virtuais e executores de tarefa. Ele move a fronteira. O agente de cada perfil roda dentro de uma VM Linux descartável em Apple Silicon, a um hipervisor de distância do macOS. Nesse modelo, a "ferramenta confiável fora da sandbox" — a extensão Python do seu editor, seu git, o daemon do Docker, o executor de tarefas da IDE — não está do outro lado de uma parede de permissões. Está do outro lado de um hipervisor, e não lê o disco da VM de forma alguma.

Essa é toda a diferença. A jogada da Pillar precisa de duas coisas no mesmo lugar: um disco que o agente pode escrever, e um programa confiável que lê esse disco. Coloque o disco do agente dentro da VM e a segunda coisa desaparece. O agente pode escrever uma configuração de hook, trocar um interpretador de ambiente virtual, plantar uma definição de tarefa — cada arquivo das sete fugas — e não há nenhuma ferramenta do host, sem sandbox, vigiando esse sistema de arquivos para pegá-lo. O que executar, executa dentro da caixa, como o usuário ubuntu descartável, numa máquina que não guarda nada.

Os mesmos sete arquivos, duas fronteiras. Numa configuração normal (à esquerda), a sandbox do agente envolve apenas o processo; o arquivo que ele escreve vai parar num disco que as ferramentas do host, sem sandbox, leem, e o comando executa como você, ao lado das suas chaves e do seu código. Sob o Bromure Agentic Coding (à direita), a fronteira é um hipervisor em torno de toda a VM: o disco do agente fica dentro da caixa, nenhuma ferramenta do host o lê, e o que executar, executa como um usuário descartável contra credenciais-isca, com cada requisição de saída filtrada no proxy do host. Feche a sessão e a caixa é reiniciada.

Há uma segunda metade das fugas que vale nomear, porque o Bromure também responde a ela. Suponha que um arquivo que o agente escreveu de fato seja executado por uma ferramenta dentro da VM — o objetivo de executar código costuma ser roubar algo ou alcançar algum lugar. Ambos são becos sem saída aqui. O código vai atrás das credenciais que fazem a viagem valer a pena, a chave da Anthropic, as chaves da AWS, o token do GitHub, e encontra iscas: um corretor de credenciais no host injeta espaços reservados como brm_…, um kubeconfig sintético e uma chave SSH descartável, e só troca o valor real na fronteira de rede, em requisições para destinos que você já aprovou. E o passo de saída — exfiltrar o butim, ou alcançar um segundo host — cruza o proxy do host, onde o destino verdadeiro é filtrado na saída e onde uma ação destrutiva contra as APIs de nuvem e do git que o perfil expõe, um delete, um drop ou um terminate, encontra uma proteção que pode recusá-la, não importa no que o agente tenha sido convencido.

Antes de tudo isso está a camada que enquadra essas fugas na raiz. Cada uma começa com uma injeção — uma instrução maliciosa num arquivo ou num resultado de ferramenta que o agente lê, mandando-o escrever a configuração envenenada logo de início. O Bromure pontua esse conteúdo não confiável com um detector de injeções no dispositivo antes de o modelo agir sobre ele. Ele pega a maior parte disso, e uma carga suficientemente inédita ainda pode escapar de um classificador, o que é exatamente por que ele fica na frente da caixa descartável em vez de no lugar dela.

A fronteira estava em torno da coisa errada

A lição duradoura da semana da Pillar não é uma lista de sete bugs para corrigir. É que colocar em sandbox o processo do agente, numa máquina onde esse processo compartilha um disco e um conjunto de ferramentas confiáveis com tudo o que você possui, traça a linha em torno da coisa errada. O agente não precisa escapar se pode escrever as entradas de algo que já está do lado de fora.

Corrigir os arquivos conhecidos é certo, e você deve fazê-lo. Mas é uma corrida contra todo formato futuro em que uma ferramenta do host decidir confiar, e essa corrida não termina. O Bromure Agentic Coding sai dela. Ele parte do princípio de que o agente será convencido a escrever o arquivo envenenado, e garante que, quando alguma ferramenta o ler, essa ferramenta esteja dentro de uma caixa descartável com iscas para os segredos e um filtro no fio — não o seu laptop, guardando suas chaves. Essa é a diferença entre uma parede que você tem de ficar corrigindo e uma linha traçada um nível abaixo, onde a escrita não tem leitor. Instale-o e dê ao seu agente uma máquina que não é sua para perder.