Pesquisadores de segurança demonstraram uma série de escapes de sandbox envolvendo Cursor, OpenAI Codex CLI, Google Gemini CLI e Antigravity, revelando uma fraqueza estrutural que vai muito além de uma vulnerabilidade isolada. Em quase todos os casos analisados, o agente de inteligência artificial não precisou quebrar diretamente a proteção, explorar o kernel ou executar uma técnica sofisticada contra o mecanismo de isolamento. Ele permaneceu dentro do ambiente permitido, respeitou as regras impostas e simplesmente escreveu arquivos que, mais tarde, foram processados por ferramentas confiáveis executadas fora da sandbox.
É justamente essa inversão que torna a pesquisa preocupante. O agente não atravessa a barreira de segurança por conta própria. Em vez disso, ele modifica algo dentro do projeto — uma configuração, um interpretador, um arquivo de tarefa, metadados do Git ou outro componente aparentemente legítimo — e espera que uma ferramenta privilegiada do sistema operacional faça o restante do trabalho. Quando a IDE, uma extensão, um hook ou um daemon local carrega esse conteúdo, o código acaba sendo executado no ambiente real do desenvolvedor.
A investigação foi conduzida durante vários meses pelos pesquisadores Eilon Cohen, Dan Lisichkin e Ariel Fogel, da Pillar Security. Os resultados foram organizados em uma série chamada Week of Sandbox Escapes, reunindo sete descobertas distribuídas entre algumas das ferramentas de programação assistida por IA mais utilizadas atualmente. A maior parte das falhas já recebeu correções ou foi reconhecida pelos respectivos fornecedores, mas o problema revelado pela pesquisa é arquitetural e não desaparece apenas com a atualização de uma lista de arquivos proibidos.
O agente não sai da caixa: o sistema abre a porta para ele
Sandboxes utilizadas por agentes de programação normalmente estabelecem uma divisão aparentemente simples. Dentro do diretório de trabalho, a IA pode ler arquivos, gerar código, executar comandos limitados e modificar o projeto. Fora desse espaço, o computador do usuário deveria permanecer protegido. O problema é que um projeto moderno não é um conjunto passivo de arquivos. IDEs, extensões, sistemas de controle de versão, ferramentas de automação e runtimes locais analisam constantemente o conteúdo armazenado nesse diretório.
Uma extensão Python pode procurar automaticamente por interpretadores. O Git pode carregar configurações e executar mecanismos auxiliares. O Visual Studio Code pode reconhecer tarefas definidas pelo workspace. Sistemas de hooks podem disparar comandos durante determinadas etapas do fluxo de desenvolvimento. O Docker Desktop mantém um daemon altamente privilegiado disponível no computador. Tudo isso acontece fora da sandbox do agente, muitas vezes com as mesmas permissões do desenvolvedor.
Assim, o verdadeiro limite de segurança não termina no processo da inteligência artificial. Ele inclui qualquer arquivo que o agente consiga modificar e qualquer ferramenta externa que confie nesse conteúdo. Um arquivo criado dentro da área permitida pode se transformar em execução arbitrária quando outro componente decide carregá-lo automaticamente.
O gatilho mais perigoso para esse cenário é a injeção indireta de prompt. Uma instrução maliciosa pode ser escondida em um README, em uma issue, em um pull request, em um pacote de dependência, em um comentário de código ou até mesmo em um diff aparentemente normal. Ao analisar o material, o agente interpreta a instrução como parte de sua tarefa e realiza alterações no workspace. Para o usuário, tudo pode parecer apenas uma revisão de código ou uma tentativa de corrigir o projeto. Nos bastidores, entretanto, a IA pode estar preparando um arquivo que será executado por uma ferramenta confiável instalada na máquina.
Os pesquisadores agruparam as descobertas em quatro falhas recorrentes: sandboxes baseadas em listas de bloqueio incapazes de acompanhar toda a complexidade do sistema operacional; configurações do workspace tratadas como simples dados, embora funcionem como código executável; listas de comandos permitidos que verificam apenas o nome do programa e ignoram seus argumentos; e daemons locais privilegiados que ficam completamente fora do alcance das restrições impostas ao agente.
Cursor e Codex foram comprometidos por mecanismos considerados confiáveis
No Cursor, uma das falhas permitia que configurações de hooks controladas pelo workspace fossem utilizadas para obter execução de comandos fora da sandbox. O problema foi registrado como CVE-2026-48124 e corrigido no Cursor 3.0.0. O agente podia modificar uma configuração relacionada aos hooks do Claude dentro do projeto, deixando um comando preparado para ser disparado por um componente executado fora do ambiente isolado.
Outra descoberta envolvendo o Cursor explorava o processo automático de identificação de ambientes Python. O agente alterava um interpretador localizado em um ambiente virtual permitido pelo workspace. Em seguida, a própria extensão Python do editor executava esse interpretador durante sua rotina de descoberta. O agente não precisava iniciar o arquivo diretamente nem violar qualquer regra explícita da sandbox. A extensão confiável fazia isso por ele.
Uma terceira vulnerabilidade aproveitava uma característica pouco lembrada do Git: os metadados de um repositório não precisam obrigatoriamente estar armazenados em uma pasta chamada .git. Ao utilizar uma localização alternativa e manipular o recurso fsmonitor, era possível contornar regras baseadas apenas no nome ou no caminho convencional do diretório. Essa falha também foi corrigida no Cursor 3.0.0, enquanto sua identificação CVE ainda permanecia pendente no momento da divulgação.
No Codex CLI, a brecha estava em uma lista de comandos classificados como seguros. O sistema permitia automaticamente determinadas operações consideradas somente leitura, mas verificava principalmente o nome do comando. O comando git show era tratado como confiável, mesmo quando seus argumentos modificavam completamente o comportamento esperado. Em vez de analisar a invocação inteira e seus efeitos reais, a proteção confiava no rótulo do executável.
A OpenAI corrigiu o problema no Codex CLI 0.95.0 e classificou o relatório como uma descoberta de alta severidade em seu programa de recompensas. A falha também aguardava a atribuição de um CVE durante a publicação da pesquisa. O caso evidencia um erro clássico de segurança: considerar um programa seguro por padrão sem avaliar parâmetros, configurações, variáveis de ambiente e recursos secundários capazes de transformar uma operação aparentemente inofensiva em execução de código.
O socket do Docker abriu uma passagem comum para três agentes
Uma das descobertas mais abrangentes atingiu simultaneamente Codex, Cursor e Gemini CLI. Os três agentes podiam ser executados dentro de sandboxes configuradas para bloquear gravações fora do workspace, mas ainda conseguiam alcançar o socket de um daemon local do Docker. Essa comunicação criava uma rota indireta para operações que o próprio processo da IA jamais poderia realizar.
O daemon do Docker opera fora da sandbox e possui capacidades suficientes para iniciar contêineres, montar diretórios do host, acessar arquivos e executar processos com privilégios elevados. Quando um agente consegue enviar instruções para esse serviço, as restrições aplicadas ao seu próprio processo deixam de ser decisivas. A sandbox pode impedir que a IA grave diretamente em uma determinada pasta, mas não necessariamente impede que ela peça ao Docker para montar essa pasta dentro de um contêiner e realizar a operação em seu lugar.
Esse cenário demonstra por que uma política baseada apenas em permissões de arquivos e comandos locais é insuficiente. Um agente não precisa possuir diretamente determinada capacidade quando pode alcançar outro processo que a possui. Bancos de dados locais, serviços de automação, runtimes de contêineres, sockets Unix, APIs internas e ferramentas de desenvolvimento podem se transformar em pontes entre a área isolada e o sistema operacional real.
A vulnerabilidade relacionada ao Docker foi corrigida, mas a lição permanece válida para qualquer ferramenta agente. A superfície de ataque precisa considerar não apenas aquilo que a IA pode executar, mas também todos os serviços aos quais ela consegue se conectar. Uma sandbox aparentemente restritiva pode continuar perigosa quando permite acesso de rede local ou comunicação com daemons privilegiados.
Google minimizou duas falhas, mas reconheceu a qualidade da pesquisa
Os pesquisadores também encontraram duas vulnerabilidades no Antigravity, plataforma de desenvolvimento agente do Google. Uma delas explorava o modelo de bloqueio utilizado pelo Seatbelt do macOS. Em vez de negar tudo por padrão e liberar apenas as operações indispensáveis, a configuração adotava uma abordagem baseada em proibições específicas. Esse modelo exige que os desenvolvedores prevejam todas as possíveis rotas de escape oferecidas pelo sistema operacional, algo extremamente difícil de manter.
A outra descoberta utilizava arquivos de tarefas do Visual Studio Code armazenados na pasta .vscode. Embora o agente permanecesse limitado ao workspace, ele podia influenciar uma configuração que posteriormente seria interpretada pela IDE fora da sandbox, contornando as expectativas do Secure Mode do Antigravity.
Segundo a Pillar Security, o Google classificou os dois relatórios como vulnerabilidades válidas, mas reduziu sua gravidade por considerar que a exploração dependeria de engenharia social ou da confiança do usuário em um repositório contaminado por uma injeção indireta de prompt. A empresa também teria elogiado a qualidade técnica de pelo menos um dos relatórios.
O argumento da dificuldade de exploração não elimina o risco central. Desenvolvedores abrem repositórios desconhecidos, analisam dependências, recebem pull requests e pedem diariamente que agentes de IA examinem conteúdos produzidos por terceiros. O que antes seria apenas um arquivo malicioso passa a ter um intermediário autônomo capaz de interpretar instruções, modificar o ambiente e preparar uma cadeia de execução sem que o usuário compreenda cada etapa.
Essa classe de problema já havia sido documentada anteriormente pela Cymulate sob o nome Configuration-Based Sandbox Escape. A pesquisa identificou padrões semelhantes em Claude Code, Gemini CLI e Codex CLI: o agente escreve uma configuração dentro do espaço permitido e o código é executado no host quando a ferramenta é iniciada novamente ou quando algum componente confiável processa o arquivo.
A descoberta da Pillar amplia o alerta ao mostrar que o mesmo padrão reaparece em quatro ferramentas pertencentes a três grandes fornecedores. Para equipes que adotam programação agente, a pergunta deixou de ser apenas se a ferramenta oferece uma sandbox. É necessário descobrir quais arquivos o agente consegue alterar, quais configurações possuem comportamento executável, quais comandos ignoram aprovação, quais daemons locais permanecem acessíveis e que tipo de registro existe quando uma ferramenta confiável executa algo influenciado pela IA.
Manter Cursor, Codex CLI, Gemini CLI e Antigravity atualizados é a primeira medida necessária, mas não resolve sozinho o problema estrutural. Repositórios desconhecidos devem ser tratados como conteúdo não confiável, mesmo quando analisados dentro de uma sandbox. Agentes não deveriam acessar sockets privilegiados, configurações executáveis ou serviços locais sem autorização explícita. IDEs e extensões também precisam deixar de executar automaticamente arquivos modificados por agentes sem validação adicional.
O verdadeiro raio de impacto de uma IA de programação não corresponde somente ao processo que executa seus comandos. Ele abrange tudo aquilo que ela consegue escrever e todas as ferramentas que poderão confiar nessas alterações depois. A sandbox continua sendo uma camada importante, mas a pesquisa deixa uma mensagem difícil de ignorar: uma caixa fechada oferece pouca proteção quando o restante do sistema continua disposto a executar tudo o que aparece dentro dela.
