O teu agente nunca escapou da sandbox. Não precisou.

O que é um escape de sandbox num agente de código?

Quase nunca é um escape. Nos casos divulgados em 2026, o agente não partiu o seu contentor, não derrotou um hipervisor nem explorou uma falha do kernel. Usou a sua capacidade normal e prevista de escrever ficheiros no projeto em que estava a trabalhar, e um desses ficheiros calhava ser a entrada de um programa que corre com todos os privilégios do utilizador.

Este é o conjunto divulgado, publicado pela Pillar à razão de um artigo por dia. Vale a pena lê-lo como lista, porque o padrão só se torna óbvio no agregado.

Lê a terceira coluna de cima a baixo. Quatro dos sete são uma escrita, não uma fuga. O agente produziu um ficheiro, um processo de confiança consumiu-o, e esse processo não estava na caixa.

Se um agente pode escrever as entradas futuras dos sistemas, nunca esteve dentro de uma sandbox.

A CSA chama-lhe Trust Handoff Flaw e, citando os investigadores da Pillar, define-o com precisão: o agente «fica dentro da caixa e cumpre todas as regras», mas escreve um ficheiro, uma configuração de hook, um interpretador de ambiente virtual, uma entrada de config de Git, uma definição de tarefa, «que outra ferramenta qualquer, não isolada, consome depois de o turno do agente acabar».

Essa definição trabalha mais do que parece. Desloca a fronteira de segurança, de um sítio que consegues configurar para uma relação que provavelmente nunca inventariaste: o conjunto de programas da máquina do programador que leem ficheiros locais ao projeto e agem sobre eles sem perguntar nada.

Porque é que as sandboxes falham sempre da mesma maneira?

Porque há quatro pressupostos que reaparecem no desenho das sandboxes, e o comportamento de um agente invalida os quatro. A nota da CSA nomeia-os, e vale mais enunciá-los como erros de desenho do que como bugs, porque cada um vai voltar no próximo produto que lançar um agente.

Nada disto é exótico. São os modos de falha clássicos da segurança de perímetro, redescobertos num sítio novo, por equipas que lançam depressa numa categoria que não existia há dois anos.

GitSpawn: a mesma falha, no ficheiro que todos os repositórios têm

Se o padrão ainda soa abstrato, a divulgação da Manifold Security no início de setembro de 2026 torna-o concreto, e é a ilustração mais limpa de todo o argumento.

core.fsmonitor é uma definição de desempenho do Git. O seu valor é um comando, que o Git executa para descobrir que ficheiros mudaram. O Git lê-o do próprio .git/config do repositório. Os agentes de código chamam o Git no arranque para saber o ramo e os ficheiros alterados, por isso o comando corre de imediato, com os privilégios do utilizador, antes sequer de existir uma janela de aprovação para mostrar.

É na entrega que convém ser preciso, e a Manifold é-o: «clonar um URL hostil não faz nada, e um fetch ou um pull também não». Um git clone normal não transporta o .git/config do repositório de origem. O repositório tem de chegar sob a forma de ficheiros, com a pasta .git já lá dentro: um ficheiro .zip partilhado, uma pasta sincronizada, uma unidade partilhada, uma pen USB. A partir daí, basta abrir essa pasta com um agente. Não há dependência maliciosa, nem script post-install, nem código para rever, nem nada que um scanner a ler ficheiros de origem assinalasse. A carga está num ficheiro de configuração que a maioria dos programadores nunca abriu.

Três detalhes merecem destaque. Primeiro, as correções são por caminho e não por classe: a Manifold reportou uma segunda via para o Claude Code, através de outra definição do Git, ainda ativa em 2.1.252 depois de a primeira ter sido corrigida. Segundo, vários agentes continuavam confirmados como vulneráveis à data da divulgação: a Manifold conta oito falhas em sete agentes, quatro delas ainda sem correção à data da publicação. Terceiro, os identificadores pedem cuidado. A Manifold não cita nenhum CVE para a sua falha do Claude Code, e o identificador do Claude Code com que é fácil confundi-la, o CVE-2026-55607, descreve outra falha: um escape de sandbox por confusão de caminhos nos worktrees do Git, presente desde a 2.1.38 e corrigida em 2.1.163, muito antes da 2.1.193 em que a Manifold confirmou a sua. Se o teu controlo é «atualizámos», o teu controlo tem um número de versão e uma condição de corrida lá dentro.

O que protege de facto é mais estreito do que parece, por isso vale a pena ser exato. A Manifold dá dois conselhos. Se receberes um repositório sob a forma de ficheiros, inspeciona o .git/config antes de abrires a pasta com um agente, porque «qualquer definição que nomeie um programa pode executá-lo». Se publicas um agente, ou um simples script que chama o Git em segundo plano, limpa a configuração do Git nessas chamadas, por exemplo com git -c core.fsmonitor=false status. O terceiro passo é nosso: atualiza o agente, a tabela acima indica as versões que trazem a correção.

# Um repositorio recebido sob a forma de ficheiros: le a config antes de um agente o abrir
cat .git/config

# Numa ferramenta ou num script que chama o Git em segundo plano, substitui a chave na propria chamada
git -c core.fsmonitor=false status

A definição global que costuma ser recomendada em vez disso, git config --global core.fsmonitor false, não te protege. A documentação do Git enumera os ficheiros de configuração por ordem, sistema, depois global, depois o .git/config do repositório, e esclarece que são lidos «pela ordem indicada acima, e o último valor encontrado tem precedência sobre os lidos antes». O valor do repositório é lido depois do teu valor global, portanto um .git/config armadilhado ganha. A opção -c é a exceção: segundo o manual do Git, o seu valor «sobrepõe-se aos valores dos ficheiros de configuração».

Mesmo bem feito, isto trata do core.fsmonitor e de mais nada. Não faz nada pelo core.hooksPath, pelo .vscode/tasks.json, por um interpretador de venv, por um hook .claude, nem pela próxima chave de configuração que alguém repare que é executável. Não se corrige uma propriedade de desenho com patches.

O que uma sandbox cobre mesmo, e o que não cobre

Por justiça para com a sandbox, que merece mesmo ser usada: faz um trabalho real, e esse trabalho não é pouco. É apenas mais estreito do que o discurso à sua volta.

As últimas quatro linhas são as que contam, e partilham uma propriedade: o agente não faz nada proibido. Os controlos de perímetro detetam violações de fronteira. Nenhuma destas o é.

Falta uma falha que pertence aqui, porque é a mais humana de todas. Em março de 2026 foi aberta uma issue contra o Claude Code a assinalar que a definição sandbox de ~/.claude/settings.json não era aplicada quando o agente corria dentro da extensão do VS Code ou do Cursor: a extensão lançava o binário nativo sem a opção --sandbox, pelo que o perfil Seatbelt do macOS nunca chegava a ser aplicado, mesmo com sandbox.enabled: true. Quem reportou verificou-o escrevendo um ficheiro em ~/Desktop a partir de uma sessão do Cursor. A issue foi fechada como duplicada quatro dias depois, e a única solução alternativa registada é a de quem a reportou: correr a CLI diretamente, ou usar hooks PreToolUse como guarda substituta.

Seja qual for o estado hoje, a classe de problema é permanente: uma sandbox é uma configuração, as configurações têm superfícies onde silenciosamente não se aplicam, e um controlo que acreditas estar ligado é pior do que um que sabes estar desligado.

Então, o que se faz?

Fica com a sandbox. Deixa de a tratar como o controlo. Depois fecha a passagem de testemunho, que é onde está a exposição real.

1. 01

   Inventaria o que lê ficheiros do projeto sem perguntar

   É o passo que ninguém dá, e é o que a CSA reclama. Lista os programas de uma máquina de desenvolvimento que consomem ficheiros do diretório de trabalho e agem sobre eles: o editor e as suas extensões, o servidor de linguagem, o cliente Git, o perfil da shell, o runtime de contentores, o lançador de tarefas, o watcher de testes. Essa lista é a tua superfície de ataque real. A sandbox não aparece nela.

2. 02

   Prefere allowlists a denylists, e modela os argumentos

   Uma denylist exige teres enumerado o sistema operativo. Uma allowlist exige teres enumerado o teu próprio fluxo de trabalho, que é um problema que consegues mesmo terminar. E valida o que um comando faz, não como se chama: o git show estava numa allowlist por causa do nome.

3. 03

   Corta os daemons privilegiados

   Nenhuma sessão de agente devia conseguir alcançar o socket do Docker, a config do Kubernetes ou qualquer endpoint local mais privilegiado do que ela. Este é gratuito. O Cursor fechou-o numa versão e o Gemini CLI seguiu na 0.58.0; a OpenAI não publicou qualquer correção para o Codex.

4. 04

   Trata as escritas de configuração como operações privilegiadas

   Uma alteração a .git/config, .vscode/, .claude/, .cursor/, a um interpretador de virtualenv ou a um workflow de CI não é uma alteração de código. É uma alteração ao que vai executar a seguir. Merece uma via de aprovação diferente da de um componente React, e hoje costuma receber a mesma.

5. 05

   Limpa o ambiente antes de limpares o sistema de ficheiros

   As variáveis de ambiente viajam com o processo. Uma sandbox perfeitamente isolada que herda AWS_SECRET_ACCESS_KEY isolou o sistema de ficheiros e publicou a credencial.

6. 06

   Põe a decisão sobre a escrita, não sobre o perímetro

   Cada ponto acima é uma medida de endurecimento que um caminho determinado acabará por contornar, porque são todas estáticas. O que fecha a classe é avaliar a ação no momento em que acontece, com capacidade de a recusar.

Esse último passo é onde vive o nosso próprio produto, por isso lê os três parágrafos seguintes a saber disso. Se achamos que decorre das provas e não do nosso roteiro é porque a CSA chegou à mesma conclusão estrutural sem vender nada, e porque a solução alternativa que um utilizador deixou no próprio gestor de issues da Anthropic era um hook PreToolUse.

Um hook coloca-se onde a sandbox não consegue. Avalia uma chamada a uma ferramenta antes de ela correr, o que significa que vê a própria escrita: esta sessão está prestes a alterar o .git/config, ou a acrescentar um core.hooksPath, ou a editar um ficheiro de workflow que dispara em forks com permissões de escrita, ou a invocar uma ferramenta cuja descrição mudou desde ontem. São eventos discretos e inspecionáveis, com sujeito e objeto. Uma sandbox vê um processo a escrever bytes num diretório permitido e não tem base nenhuma para se opor, porque não está a acontecer nada proibido.

É outra pergunta, não uma parede mais grossa. A sandbox pergunta «este processo pode estar aqui?». A barreira pergunta «esta ação concreta deve acontecer agora?». O Trust Handoff Flaw existe precisamente porque a primeira pergunta tem uma resposta satisfatória enquanto a segunda nunca chega a ser feita.

E degrada-se com honestidade. As regras no contexto do agente melhoram aquilo que ele propõe, o que é uma melhoria real e probabilística. Os findings no ciclo fazem com que uma alteração proposta seja raciocinada contra o estado real do repositório. Só o hook é determinístico, e preferimos dizer qual dos três é um controlo do que insinuar que são os três. A versão alargada deste argumento está em a segurança dos agentes de código de IA.

Perguntas frequentes

A sandbox chega para proteger um agente de código de IA?

Não, e as divulgações de 2026 mostram porquê com uma clareza pouco comum. Dos sete escapes reproduzidos no Cursor, Codex CLI, Gemini CLI e Antigravity, a maioria não passou por sair da sandbox. O agente escreveu um ficheiro dentro do workspace permitido, e um processo de confiança fora da sandbox executou-o mais tarde. A sandbox limita o dano de um processo que se porta mal dentro da fronteira, o que vale a pena ter. Não consegue fazer nada contra um agente que se porta lindamente e entrega a carga a algo que nunca esteve na caixa.

O que é o Trust Handoff Flaw?

É o nome que a Cloud Security Alliance deu, numa nota de investigação de 22 de julho de 2026, ao padrão por trás dos escapes de sandbox dos agentes de código em 2026. O agente fica dentro da sua fronteira e cumpre todas as regras, mas escreve um ficheiro, uma configuração de hook, um interpretador de ambiente virtual, uma entrada de config de Git ou uma definição de tarefa, que outra ferramenta não isolada consome depois de o seu turno acabar. A nota retoma o resumo de uma linha da Pillar: se um agente pode escrever as entradas futuras dos sistemas, nunca esteve dentro de uma sandbox.

Que agentes de código tiveram escapes de sandbox em 2026?

A investigação da Pillar Security reproduziu escapes no Cursor, no Codex CLI da OpenAI, no Gemini CLI da Google e no Antigravity da Google, sete no total, com pelo menos quatro a receberem correção do fabricante, segundo a contagem da CSA. À parte, a divulgação GitSpawn da Manifold Security de 1 de setembro de 2026 cobriu o goose (CVE-2026-72718, corrigido em 1.44.0), o Claude Code (sem CVE citado: o caminho core.fsmonitor foi corrigido em 2.1.196 e um segundo caminho continuava aberto em 2.1.252), o Hermes Agent (CVE-2026-71963), o Qwen Code e o Grok Build, estes três últimos ainda sem correção à data da divulgação. A Manifold também encontrou o Codex e o Cursor afetados, ambos entretanto corrigidos; o registo que a própria OpenAI publicou para a falha de core.fsmonitor no Codex CLI é o CVE-2026-19592, corrigido em 0.131.0.

Um repositório Git pode correr código só por ser aberto?

Sim, se te chegou sob a forma de ficheiros e não por git clone. core.fsmonitor é uma definição de desempenho do Git cujo valor é um comando que o Git executa para determinar que ficheiros mudaram, e o Git lê-o do próprio .git/config do repositório. Os agentes de código chamam o Git no arranque, por isso o comando corre com os privilégios do utilizador antes de aparecer qualquer janela de aprovação. É essa a descoberta do GitSpawn, e a Manifold é precisa quanto à entrega: um clone normal não transporta o .git/config da origem, por isso o repositório tem de chegar com a pasta .git já lá dentro, como ficheiro .zip partilhado, pasta sincronizada, unidade partilhada ou pen USB. Lê o .git/config antes de abrires uma pasta assim com um agente. git config --global core.fsmonitor false não adianta, porque o Git lê o ficheiro do repositório depois do global e ganha o último valor; só git -c core.fsmonitor=false, no próprio comando, passa à frente.

MicroVM, gVisor ou contentor para o meu agente de código?

Escolhe pelas tuas restrições de desempenho e de GPU, porque para esta classe de ameaça a escolha quase não conta. O Firecracker dá o isolamento mais forte, o gVisor é um meio-termo razoável com um kernel em espaço de utilizador, e os contentores são o chão. Nenhum dos três muda o facto de uma extensão de Python não isolada executar um interpretador que o agente alterou. Gasta o esforço de decisão no que o agente pode escrever e em que programas locais confiam nele, e trata a primitiva de isolamento como uma definição de raio de dano.

Ligar a definição de sandbox do meu agente isola-o mesmo?

Verifica em vez de assumires. Em março de 2026 uma issue contra o Claude Code reportava que sandbox.enabled: true em ~/.claude/settings.json não tinha efeito quando o agente corria dentro da extensão do VS Code ou do Cursor, porque a extensão lançava o binário nativo sem a opção --sandbox e o perfil Seatbelt do macOS nunca era aplicado. Quem reportou confirmou-o escrevendo em ~/Desktop a partir de uma sessão do Cursor. Testa a tua própria configuração tentando uma escrita fora do workspace e vendo se é recusada.

O que é segurança agent-time e em que difere da sandbox?

A sandbox coloca uma pergunta de perímetro: este processo pode estar neste sítio? A segurança agent-time coloca uma pergunta de ação: esta operação concreta deve acontecer agora?, e sabe recusar. A diferença é decisiva perante o Trust Handoff Flaw, porque a escrita que causa a execução posterior não é uma violação de perímetro e parece perfeitamente legítima a uma camada de isolamento. Uma barreira que avalia a chamada à ferramenta vê que o destino é .git/config e recusa-a, coisa que nenhuma força de isolamento fará.

Isto quer dizer que as sandboxes de agentes não servem para nada?

De todo, e abandoná-las seria a lição errada. Uma sandbox limita de forma fiável o dano de uma dependência maliciosa, de um comando destrutivo ou de um ciclo descontrolado, e esses casos são frequentes. A correção é deixar de a descrever como contenção perante um agente adversarial. É um redutor de raio de dano, que se coloca ao lado do controlo de saída de rede, da higiene de credentials e de um ponto de aplicação sobre as próprias ações.