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. 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 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.

Clonar um repositório já chega. 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.

Dois 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 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. Se o teu controlo é «atualizámos», o teu controlo tem um número de versão e uma condição de corrida lá dentro.

A mitigação recomendada pela Manifold vale a pena hoje, cabe num comando, e mostra bem como uma correção por incidente é estreita:

# Auditar um repositorio que vais abrir com um agente
git config --get core.fsmonitor

# Desativar o mecanismo globalmente
git config --global core.fsmonitor false

# Ou neutraliza-lo nas chamadas em segundo plano
git -c core.fsmonitor=false status

Isto fecha o core.fsmonitor. 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, e a solução alternativa proposta era 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.

É 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.

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.

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 e eliminou uma classe inteira em três produtos.

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.

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.

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 sugerida 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 resume assim: 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. À parte, a divulgação GitSpawn da Manifold Security em setembro de 2026 cobriu o goose (CVE-2026-72718), o Codex (CVE-2026-19592), o Claude Code (CVE-2026-55607) e o Hermes Agent (CVE-2026-71963), com o Qwen Code e o Grok Build também confirmados como vulneráveis nessa altura.

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

Sim, e é essa a descoberta do GitSpawn. 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. Auditar é um comando, git config --get core.fsmonitor, e desativar globalmente é git config --global core.fsmonitor false.

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.