Três investigadores passaram meses sem atacar a sandbox

Eilon Cohen, Dan Lisichkin e Ariel Fogel, da Pillar Security, fizeram uma pergunta muito circunscrita sobre as sandboxes que acompanham os agentes de código com IA. Não se as paredes aguentam, mas se as paredes estão no sítio certo. A 20 de julho de 2026 começaram a publicar a resposta numa série a que chamam Week of Sandbox Escapes, um artigo por dia, sobre o Cursor, a CLI do OpenAI Codex, a CLI do Google Gemini e o Google Antigravity.

Em todos os casos o agente comportou-se. Ficou dentro do espaço de trabalho que lhe foi atribuído e não violou nenhuma regra imposta pela sandbox. Escreveu um ficheiro. Um processo fora da sandbox leu depois esse ficheiro, confiou nele e executou o que lá estava escrito. A fuga deu-se sem que o agente chegasse a tocar na fronteira.

A Pillar condensa a conclusão numa linha: o raio de impacto de um agente não é o processo do agente, é tudo aquilo que o agente consegue escrever e em que o anfitrião vem depois a confiar. É essa frase que faz a notícia, e é por isso que corrigir as falhas uma a uma não encerra o assunto.

Um socket explica três dos quatro produtos

A falha mais clara é também a menos exótica. O Codex CLI, o Cursor e o Gemini CLI conseguiam todos alcançar o socket local do Docker a partir de dentro das respetivas sandboxes. Um daemon privilegiado no anfitrião arranca um contentor para quem quer que consiga falar com ele, e esse contentor corre inteiramente fora da sandbox. Um único aviso, GHSA-v4xv-rqh3-w9mc, abrange três dos quatro produtos testados. Está corrigido.

O Codex trazia um segundo problema, de outra natureza. A sua lista de comandos seguros confiava nos comandos pelo nome. Autorizava o git show como operação apenas de leitura, sem modelar aquilo que argumentos perigosos passados ao git show conseguem de facto fazer. Isso ficou corrigido na versão 0.95.0, e o relatório valeu uma recompensa de severidade alta.

Lidos em conjunto, os dois casos revelam o padrão. Ambos são listas de permissões. Ambas foram escritas sobre aquilo que um responsável consegue ver, um caminho de socket e um nome de comando, e não sobre aquilo que essas coisas conseguem fazer assim que estão ao alcance.

As fugas entraram por ficheiros em que o editor já confia

O Cursor rendeu três. Um agente conseguia reescrever o interpretador dentro de um ambiente virtual de Python e esperar que a própria extensão de Python do editor, que corre sem sandbox, o executasse. Conseguia criar um diretório Git com um nome fora do padrão, de modo que as regras de sandbox baseadas em caminhos deixassem de corresponder, e depois deixar que o fsmonitor o apanhasse. E conseguia largar no espaço de trabalho uma configuração de hooks que a ferramenta executava sem sandbox. Esta última tem o CVE-2026-48124 e o aviso GHSA-pc9j-3qc2-95wv, e as três estão corrigidas no Cursor 3.0.0.

As duas falhas da Google vêm da mesma família. O perfil Seatbelt do macOS por trás do Antigravity foi escrito como lista de negação, o que autoriza tudo aquilo que não seja nomeado de forma explícita, e uma configuração de tarefas .vscode conseguia contornar as proteções do Secure Mode. A Google disse aos investigadores que o relatório era de qualidade excecional, classificou depois as falhas como difíceis de explorar por exigirem engenharia social e desvalorizou-as com esse fundamento.

A classificação defende-se nos seus próprios termos e é irrelevante para quem tem estas ferramentas a correr. No caso de um agente, engenharia social significa uma frase num README, um comentário num issue ou um parágrafo na documentação de uma dependência. Ler texto não fidedigno é o dia de trabalho normal de um agente.

A fronteira que comprou não é a fronteira que tem

Todos estes produtos apresentam a sandbox como o controlo que torna aceitável programar de forma autónoma. É a resposta que uma revisão de segurança recebe, e é a razão pela qual as aprovações foram dadas. A investigação mostra que a sandbox governa uma coisa só, o processo do agente. Nunca foi uma afirmação sobre o espaço de trabalho.

A superfície verdadeira é o espaço de trabalho, porque é lido por uma longa lista de processos concebidos anos antes de existirem agentes, todos eles a assumir que foi um humano a escrever aquilo que estão a ler. A extensão de Python. O daemon do Git. O socket do Docker. O hook de pre-commit. O instalador de dependências. O runner de CI que clona o ramo. Nenhum foi construído para tratar o conteúdo de um repositório como entrada hostil, e agora todos fazem exatamente isso.

Ou seja, o objeto da governação está errado. Os responsáveis têm andado a aprovar agentes. O que precisa de uma política é o espaço de trabalho, e a regra é curta: um repositório onde um agente de IA pode escrever é entrada não fidedigna para todos os processos a jusante, em pé de igualdade com um ficheiro carregado por um desconhecido.

O que mudar esta semana

Comece pelo socket, porque um único aviso abrangeu três dos quatro produtos. Nenhum agente de código precisa de aceder a um socket do Docker, e retirar esse acesso é uma alteração de configuração e não um projeto. Depois atualize as versões. O Cursor 3.0.0 e o Codex CLI 0.95.0 são as linhas corrigidas, e as ferramentas de desenvolvimento atualizam-se por utilizador e não por frota, pelo que um fornecedor publicar a correção não é o mesmo que os seus engenheiros a terem instalada.

A mudança duradoura é no sítio onde os agentes correm. Um ramo em que um agente tenha mexido deve chegar à CI como não fidedigno, o que na prática significa que a pipeline não executa hooks, tarefas nem interpretadores fornecidos por esse ramo enquanto uma pessoa não aprovar o diff. É uma decisão de pipeline e não de ferramenta, e sobrevive à divulgação seguinte.

Ao abrigo da NIS2, um incidente que começa no editor de um programador e acaba na sua pipeline de produção tem de ser comunicado nos mesmos prazos que qualquer outro. O dever não distingue entre um atacante que enganou um engenheiro por phishing e um agente que leu um README envenenado, pelo que o controlo tem de ficar onde a pipeline o consegue impor.

Leia a seguir: A correção do nginx saiu, o exploit chega em agosto  |  A ServiceNow corrigiu primeiro a nuvem dela, a sua casa só 103 dias depois