Estamos acostumados a ler sobre IA em cibersegurança por um único ângulo: um invasor usando agentes para agir mais rápido. O segundo ângulo importa mais para a sua organização e recebe muito menos atenção. O agente que você roda na máquina do seu próprio desenvolvedor é, ele mesmo, uma nova superfície de ataque. Em dois meses, três grupos de pesquisa independentes publicaram descobertas que apontam todas na mesma direção.

O que esses casos têm em comum não é uma falha no modelo nem uma resposta ruim. O agente nunca saiu do seu sandbox e nunca violou uma regra. O que aconteceu é que o agente leu ou escreveu um arquivo dentro do projeto e, depois, uma ferramenta confiável rodando fora do sandbox executou o conteúdo desse arquivo. O sandbox resistiu. O comprometimento passou por fora dele.

O mecanismo: uma configuração de desempenho do Git com anos de existência

O exemplo mais claro foi publicado pela Manifold Security em 2 de setembro de 2026 com o nome GitSpawn. Ele gira em torno de uma configuração do Git por projeto chamada core.fsmonitor, uma opção de desempenho legítima e documentada cujo valor é um comando que o Git executa para identificar rapidamente os arquivos alterados, em vez de varrer o diretório inteiro.

Agora junte as duas metades:

  • Um agente de programação com IA, ao começar a trabalhar em um projeto, executa automaticamente comandos do Git como git status e git diff para entender o estado do repositório. Esse é um comportamento normal e necessário.
  • Se o repositório tiver um valor malicioso de core.fsmonitor, simplesmente executar esses comandos executa o comando do invasor.

O resultado é que abrir um repositório de código deixa de ser um evento de leitura e passa a ser um evento de execução. Nenhum clique, nenhuma aprovação, nenhum aviso exibido ao desenvolvedor. Segundo o relatório, oito agentes de linha de comando ficaram expostos, e vieram correções para vários deles: goose na 1.44.0, Claude Code na 2.1.196 para o caminho do core.fsmonitor, Codex CLI na 0.131.0, além do Cursor. O relatório apontou quatro caminhos ainda sem correção na data da publicação. A classe foi rastreada sob identificadores como CVE-2026-72718, CVE-2026-19592 e CVE-2026-55607.

Não é um incidente, mas uma classe inteira

Seis semanas antes do GitSpawn, pesquisadores da Pillar Security publicaram, em 20 de julho de 2026, uma série que chamaram de uma semana de fugas de sandbox, documentando sete vulnerabilidades em quatro agentes de programação de três fornecedores: Cursor, Codex, Gemini CLI e Antigravity. A descrição que fazem do mecanismo merece ser lida duas vezes. O agente fica dentro da caixa e segue todas as regras. Ele apenas escreve um arquivo que uma ferramenta confiável fora da caixa depois executa, carrega ou analisa.

  • No Cursor, um arquivo de configuração de hooks controlado pelo workspace permitia a execução fora do sandbox, registrado como CVE-2026-48124 e corrigido na versão 3.0.0.
  • No Codex CLI, a lista de comandos permitidos confiava no git show apenas pelo nome, embora os parâmetros passados a ele possam torná-lo mais do que somente leitura. Corrigido na versão 0.95.0.
  • Um problema no socket do Docker afetava Codex, Cursor e Gemini CLI ao mesmo tempo.
  • No Antigravity, um contorno da lista de bloqueio do Seatbelt do macOS e um problema de configuração de tarefas do editor, ambos classificados pelo Google como difíceis de explorar.

Depois, em 10 de setembro de 2026, a Upstarts Media noticiou uma terceira divulgação, de uma startup chamada Accomplish, sobre sandboxes com vazamentos no Claude Code, no Codex e no Cursor. O número interessante ali não é a vulnerabilidade, mas o tempo de correção: o problema do Cursor foi resolvido em cerca de uma semana, dois problemas da OpenAI em agosto, enquanto o problema da Anthropic levou cerca de cinquenta dias ao longo de dezenas de versões. Três grupos de pesquisa, três relatórios, dois meses, um padrão.

Por que isso importa mesmo que você nunca escreva código

Porque o risco não cai sobre o agente. Cai sobre a máquina que o executa e sobre a rede em que essa máquina está. A estação de trabalho de um desenvolvedor é um dos dispositivos mais privilegiados de qualquer empresa: guarda chaves de acesso a servidores, tokens de deploy e, muitas vezes, uma conexão aberta com um banco de dados de produção. Executar um único comando nela não é pouca coisa.

O cenário não é teórico no mercado saudita. Compare estes casos com a sua própria empresa:

  • Um prestador externo ou uma agência de desenvolvimento entrega código que sua equipe depois abre com um agente de IA em uma máquina dentro da sua rede.
  • Um projeto de código aberto que um desenvolvedor baixa para testar uma biblioteca ou uma correção rápida.
  • Um arquivo enviado por e-mail ou WhatsApp por um fornecedor, descompactado e aberto direto no editor.
  • Um candidato a uma vaga que envia um projeto de exemplo aberto por um avaliador técnico.
  • Um branch antigo ou um repositório transferido entregue durante uma aquisição ou uma passagem de projeto.

Em todos eles, a suposição implícita é que abrir arquivos para lê-los é um ato seguro. Foi essa suposição que quebrou.

O que fazer nesta semana

Cinco passos, e o primeiro não exige orçamento:

  1. Atualize hoje as ferramentas de agentes em toda a equipe. Existem correções para a maioria dessas ferramentas, e o valor está em todos estarem em uma versão corrigida, não apenas uma pessoa. Comece sabendo quem roda o quê e em qual versão, porque esse próprio inventário costuma não existir.
  2. Trate o código recebido como conteúdo não confiável. Código de um prestador ou de uma fonte aberta não é um documento que você lê, é algo que executa. Abra-o pela primeira vez em uma máquina ou contêiner separado da rede de trabalho.
  3. Separe a máquina de desenvolvimento das chaves de produção. Não mantenha tokens de servidores em produção na máquina em que projetos de origem externa são abertos. Assim, a perda fica restrita àquele dispositivo.
  4. Direcione o deploy por um pipeline central, não por um notebook pessoal. Quando o deploy passa por um único pipeline de build com permissões restritas, comprometer uma única máquina deixa de ser um caminho até a produção.
  5. Inclua uma cláusula nos contratos de desenvolvimento terceirizado. Você tem o direito de especificar como o código é entregue e a partir de qual repositório, e de exigir que o fornecedor mantenha suas ferramentas atualizadas. Isso é uma cláusula contratual, não um debate técnico.

No contexto local, nada disso é uma boa prática opcional. Os Controles Essenciais de Cibersegurança emitidos pela Autoridade Nacional de Cibersegurança (NCA) incluem domínios explícitos para segurança de endpoints, segurança da gestão de mudanças e do desenvolvimento, e segurança de terceiros, enquanto a responsabilidade pela proteção de dados pessoais continua sendo da organização nos termos da Lei de Proteção de Dados Pessoais (PDPL). Se a porta se abriu por meio da máquina de um desenvolvedor que abriu um projeto de um fornecedor, isso não reduz a responsabilidade.

A visão da Origami

Lemos esses três relatórios como uma correção a uma ideia que se espalhou rapidamente: a de que um sandbox basta, desde que o agente esteja trancado dentro dele. Essas vulnerabilidades não quebraram o isolamento. Elas usaram uma ponte legítima que leva algo escrito dentro da caixa até uma ferramenta que roda fora dela. O que significa que a pergunta certa não é se o agente está em um sandbox, mas quais ferramentas leem o que o agente produz e com quais privilégios essas ferramentas rodam.

Uma observação prática do que vemos nos clientes: a adoção de ferramentas de IA dentro das equipes de desenvolvimento anda meses à frente de qualquer política que a regule. Um desenvolvedor testa uma ferramenta, gosta, e ela passa a fazer parte do fluxo de trabalho diário sem decisão, sem revisão e sem inventário. O problema não é a ferramenta. O problema é que ela entrou por uma porta que ninguém vigia. Quando revisamos os ambientes dos clientes, começamos exatamente aqui: quais ferramentas realmente rodam nas máquinas da equipe, com quais privilégios, e o que acontece se um comando for executado em uma delas esta noite. Se você quer uma revisão por esse ângulo, vai nos encontrar na página de contato.

Em resumo

Três divulgações independentes em dois meses dizem a mesma coisa: um agente de programação com IA transforma a abertura de um projeto de uma leitura em uma execução, e basta que um terceiro coloque uma linha em um arquivo de configuração. Saíram correções para a maioria das ferramentas e alguns caminhos continuaram abertos, mas a lição sobrevive a qualquer versão. Qualquer ferramenta que você roda em uma máquina altamente privilegiada faz parte da sua superfície de ataque, esteja ela listada ou não nas suas políticas. Comece com uma pergunta: quem na sua equipe está rodando um agente de IA agora, em qual máquina e em qual versão?

Fontes