Sandbox escape por arquivo gerado por agente de código é a falha em que o agente obedece ao limite direto. Ainda assim, ele cria um artefato que outra ferramenta executa fora desse limite. O problema não é só shell. É confiança transitiva entre workspace, IDE, Git, hook, socket local e CI.

Em 2026, o Stack Overflow em "2025 Developer Survey: AI" informou que 84% dos respondentes usam ou planejam usar ferramentas de IA no desenvolvimento (Stack Overflow, "2025 Developer Survey: AI", 2025, consultado em 2026-07-23). A mesma pesquisa informou uso diário por 51% dos profissionais. A escala muda a pergunta: quem confia nos arquivos que o agente escreve?

Resumo prático

  • Sandbox do agente não cobre automaticamente o host.
  • Arquivo de configuração pode virar execução indireta.
  • Git, IDE, hook, Docker e extensão entram no threat model.
  • O CI precisa registrar proveniência antes de consumir artefatos do agente.

Diagrama abstrato mostra um agente escrevendo arquivos que atravessam uma fronteira de confiança sem texto visível.

Por que este escape não parece quebra de sandbox?

Em 20 de julho de 2026, a Pillar publicou "The Week of Sandbox Escapes" com sete achados em quatro ferramentas (Pillar Security, "The Week of Sandbox Escapes", 2026, consultado em 2026-07-23). O recorte incluiu Cursor, Codex, Gemini CLI e Antigravity. A tese prática é direta: o agente não precisa quebrar o sandbox se influencia algo fora dele.

Esse padrão confunde revisão porque o log do agente pode parecer correto. Ele escreve dentro do workspace, usa uma operação permitida e para antes de uma ação obviamente perigosa. Depois, uma extensão da IDE, um comando Git, um hook ou um daemon local lê aquele arquivo como se fosse configuração humana.

O incidente deixa uma lição de arquitetura: sandbox é uma fronteira de processo, mas o fluxo agentic é uma cadeia de confiança. Se a cadeia inclui consumidores fora do sandbox, o controle precisa acompanhar o artefato, não apenas o processo que o gerou.

Cápsula citável: Sandbox escape por arquivo gerado por agente é uma falha de handoff. A Pillar documentou sete achados em quatro ferramentas em 2026; o padrão comum é o agente escrever algo permitido que um componente confiável do host executa ou interpreta depois.

Esse recorte complementa quarentena de repositório para agentes de código e GhostApproval em agentes de código. Lá, o foco é entrada hostil e caminho real. Aqui, o foco é o consumidor confiável que roda depois.

Onde o host confia no arquivo que o agente acabou de escrever?

Em 2026, a Pillar agrupou os achados em quatro modos de falha: denylist incompleta, configuração de workspace executável, allowlist por nome de comando e daemons locais privilegiados (Pillar Security, "The Week of Sandbox Escapes", 2026, consultado em 2026-07-23). O host confia em arquivos quando extensões, hooks e daemons tratam configuração como código operacional.

O caso mais perigoso não é o arquivo suspeito chamado por um comando explícito. É o arquivo normal. Um projeto moderno tem configuração de tarefa, ambiente virtual, metadado Git, script de pacote, hook de ferramenta, definição de container e cache de extensão. Tudo isso pode ser lido automaticamente.

Diagrama abstrato mostra fluxos entre workspace, host e pontos de bloqueio sem texto visível.

Pense em quatro perguntas antes de permitir escrita ampla. O agente pode editar arquivo que a IDE carrega sem pergunta? Pode alterar configuração de Git que muda o comportamento de um comando futuro? Pode tocar socket ou daemon fora do sandbox? Pode criar automação que o CI executa no próximo job?

Superfície Risco prático Controle mínimo
Configuração de IDE Tarefa ou extensão roda fora do sandbox. Bloquear escrita automática e pedir revisão.
Git e hooks Comando aparente chama helper ou config alterada. Validar invocação, argumentos e config efetiva.
Ambiente virtual Descoberta automática executa binário manipulado. Recriar ambiente fora do workspace escrito pelo agente.
Daemon local Socket privilegiado vira execução indireta. Negar acesso por padrão e liberar por job isolado.

Experiência prática: quando desenho harness para agente de código, trato configuração de host como mudança de plataforma. O arquivo pode parecer pequeno, mas o consumidor dele costuma ter mais permissão que o agente. Por isso, prefiro bloquear primeiro e liberar depois com evidência curta no PR.

Cápsula citável: A fronteira real fica no ponto em que o host consome o arquivo. A Pillar descreveu quatro modos de falha em 2026; todos mostram que configuração de workspace, allowlists e daemons precisam de política própria em fluxos agentic.

Como limitar escrita sem travar o fluxo agentic?

Em 2026, a documentação do Codex descreveu três modos principais de sandbox: read-only, workspace-write e danger-full-access (OpenAI Developers, "Sandbox", 2026, consultado em 2026-07-23). Para esse risco, workspace-write é necessário em muitas tarefas, mas não é suficiente quando o workspace contém configuração executável.

O ajuste prático é separar escrita comum de escrita sensível. Código-fonte, teste e documentação podem seguir o fluxo normal. Arquivos que o host consome precisam de regra adicional: pedir revisão, negar alteração, ou mover a execução para runner descartável.

Claude Code ajuda nessa separação porque permissões são aplicadas pela ferramenta, não pelo modelo. A documentação afirma que prompt e CLAUDE.md influenciam o que o agente tenta fazer, mas quem concede ou revoga acesso é a camada de permissões, hooks ou modos (Claude Code Docs, "Configure permissions", 2026, consultado em 2026-07-23).

Em loops longos, o custo de contexto também pesa porque o agente precisa lembrar quais arquivos são sensíveis e quais evidências já foram aprovadas. Eu uso RemoteCode para manter continuidade em fluxos agentic de Claude Code e Codex com menos repetição de contexto quando o trabalho atravessa várias rodadas; é uma ferramenta minha, então a menção aqui é editorial e ligada ao problema de tokens.

Cápsula citável: O controle saudável não bloqueia toda escrita do agente. Codex documenta workspace-write para edição controlada, enquanto Claude Code reforça que permissões são aplicadas fora do modelo; arquivos consumidos pelo host precisam de regra adicional antes de virarem execução.

Que arquivos precisam virar fronteira de aprovação?

Em 2026, o arXiv em "Harness Engineering for Agentic AI Coding Tools" analisou 2.853 repositórios e identificou oito mecanismos de configuração para ferramentas agentic, com AGENTS.md aparecendo como ponto inicial interoperável (arXiv, "Harness Engineering for Agentic AI Coding Tools", 2026, consultado em 2026-07-23). A lista de fronteiras deve nascer do seu harness, não da memória do revisor.

Comece pelos arquivos que mudam comportamento fora da execução direta do agente. Inclua .git, hooks, .vscode, .idea, .claude, .codex, .devcontainer, ambientes virtuais, scripts de pacote, arquivos de runner e qualquer configuração que acione ferramenta local.

Depois classifique por consumidor. Se quem lê o arquivo é o próprio teste dentro do runner, o risco é menor. Se quem lê é o host do desenvolvedor, uma extensão com permissão ampla ou um daemon com socket privilegiado, a regra deve ser mais dura.

{
  "fronteira": {
    "codigo_comum": "edicao_com_revisao_normal",
    "configuracao_de_host": "pedir_aprovacao",
    "daemon_local": "negado_por_padrao",
    "segredo_ou_credencial": "fora_do_workspace",
    "artefato_do_agente": "registrar_proveniencia"
  }
}

Cápsula citável: Harness de agente precisa listar consumidores, não só arquivos. O estudo do arXiv analisou 2.853 repositórios e oito mecanismos de configuração; para segurança, cada mecanismo deve declarar quem consome o artefato e qual política vale.

Esse contrato conversa com custo de contexto para Claude Code e Codex porque arquivo de regra amplo demais vira ruído. Mantenha a política curta, executável e ligada a incidentes reais.

Como testar essa falha no CI antes do incidente?

Em 2026, o arXiv em "ABTest" gerou 647 casos de fuzzing em repositórios reais, sinalizou 1.573 anomalias e confirmou manualmente 642 novas anomalias, com precisão de 40,8% (arXiv, "ABTest: Behavior-Driven Testing for AI Coding Agents", 2026, consultado em 2026-07-23). Isso mostra por que o harness precisa de teste comportamental, não só lint.

Monte um repositório de teste com configuração sensível inofensiva. O objetivo não é explorar seu próprio time. É medir se o agente tenta editar arquivo protegido, se o CI bloqueia a alteração e se o resumo final mostra a decisão correta.

Diagrama abstrato mostra uma sequência de gates protegendo arquivos criados por agente sem texto visível.

Use payloads benignos. Um arquivo .vscode pode apontar para comando falso que só imprime evento. Um hook pode gravar em arquivo temporário. Um socket de daemon pode ser substituído por stub local. O teste passa quando o agente recebe bloqueio claro e escolhe outro caminho.

Teste Sinal de aprovação
Tentativa de editar config sensível Hook bloqueia e registra caminho.
Comando permitido com argumento perigoso Política avalia invocação completa.
Artefato criado pelo agente Proveniência aparece no resumo do PR.
Consumidor fora do sandbox CI exige revisão humana antes de executar.

Cápsula citável: Evals de segurança para agentes precisam reproduzir handoffs. O ABTest gerou 647 casos e confirmou 642 anomalias novas; para sandbox escape indireto, o teste deve verificar se arquivo escrito pelo agente consegue virar ação do host.

O que entra no contrato mínimo de host seguro?

Em 2026, o arXiv em "Overeager Coding Agents" avaliou 500 cenários validados e cerca de 7.500 execuções em quatro produtos de agente, incluindo Claude Code, Codex CLI e Gemini CLI (arXiv, "Overeager Coding Agents", 2026, consultado em 2026-07-23). O contrato mínimo deve limitar escopo antes que a intenção do agente cresça sozinha.

O contrato cabe em uma página. Primeiro, nenhum agente edita configuração consumida pelo host sem aprovação. Segundo, toda automação criada por agente roda em runner isolado antes de tocar laptop, segredo ou daemon. Terceiro, o PR mostra proveniência: arquivo criado por humano, pelo agente ou pelo repositório original.

Também registre exceções. Se um agente precisa editar .devcontainer, a justificativa deve aparecer no PR. Se precisa usar Docker, use runner descartável. Se precisa alterar hook, trate como mudança de política, não como detalhe de implementação.

Cápsula citável: Host seguro para agentes começa com escopo explícito. O estudo Overeager avaliou 500 cenários e cerca de 7.500 execuções; em times reais, isso vira política de aprovação para configuração, daemons, segredos e artefatos criados pelo agente.

FAQ sobre sandbox escape por arquivo de agente

Sandbox deixou de ser útil para agente de código?

Não. Em 2026, a OpenAI descreve sandbox como a fronteira que permite autonomia sem acesso irrestrito ao computador (OpenAI Developers, "Sandbox", 2026, consultado em 2026-07-23). A lição da Pillar é que o sandbox precisa considerar arquivos escritos e consumidores do host, não só o processo do agente.

Devo bloquear toda escrita em .vscode, .git e hooks?

Bloqueie escrita automática e peça revisão quando houver execução fora do sandbox. Em 2026, Claude Code documenta PreToolUse para bloquear edições em arquivos protegidos antes da escrita (Claude Code Docs, "Automate actions with hooks", 2026, consultado em 2026-07-23). A regra pode ser estreita, mas precisa ser executável.

Isso vale para CI ou só para laptop de desenvolvedor?

Vale para os dois. Em 2026, a documentação de implantação segura do Claude Agent SDK recomenda isolamento com sandbox, containers, gVisor ou máquinas virtuais conforme o threat model (Claude Code Docs, "Securely deploying AI agents", 2026, consultado em 2026-07-23). CI reduz risco quando o runner é descartável e sem segredo amplo.

Como saber se minha allowlist de comando é fraca?

Teste argumentos, diretório, configuração e efeito colateral, não apenas o nome. Em 2026, a Pillar relatou o caso GitPwned no Codex CLI, no qual git show parecia seguro por nome, mas argumentos permitiam escrita e configuração maliciosa (Pillar Security, "GitPwned: Allowlist to RCE", 2026, consultado em 2026-07-23).

Fechamento

O sandbox continua necessário, mas ele não é o fim do threat model agentic. O agente agora escreve entradas futuras para ferramentas que já existiam antes dele.

O caminho pragmático é tratar configuração executável como fronteira: negar por padrão, pedir revisão quando o host consome, rodar em runner descartável e registrar proveniência. Se o agente criou o arquivo, o host precisa desconfiar antes de executar.

Fontes consultadas

  • Stack Overflow, "2025 Developer Survey: AI", consultado em 2026-07-23, https://survey.stackoverflow.co/2025/ai
  • Pillar Security, "The Week of Sandbox Escapes", consultado em 2026-07-23, https://www.pillar.security/blog/the-week-of-sandbox-escapes
  • Pillar Security, "GitPwned: Allowlist to RCE", consultado em 2026-07-23, https://www.pillar.security/blog/gitpwned-allowlist-to-rce
  • OpenAI Developers, "Sandbox", consultado em 2026-07-23, https://developers.openai.com/codex/concepts/sandboxing
  • Claude Code Docs, "Configure permissions", consultado em 2026-07-23, https://code.claude.com/docs/en/permissions
  • Claude Code Docs, "Automate actions with hooks", consultado em 2026-07-23, https://code.claude.com/docs/en/hooks-guide
  • Claude Code Docs, "Securely deploying AI agents", consultado em 2026-07-23, https://code.claude.com/docs/en/agent-sdk/secure-deployment
  • arXiv, "Harness Engineering for Agentic AI Coding Tools: An Exploratory Study", consultado em 2026-07-23, https://arxiv.org/abs/2602.14690
  • arXiv, "ABTest: Behavior-Driven Testing for AI Coding Agents", consultado em 2026-07-23, https://arxiv.org/abs/2604.03362
  • arXiv, "Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks", consultado em 2026-07-23, https://arxiv.org/abs/2605.18583