GhostApproval em agentes de código é o alerta de que aprovação humana não basta quando o diff mostra um caminho e o sistema escreve em outro. O risco não está só no agente decidir mal. Está na UI, no sandbox e no caminho canônico que o agente realmente toca.

Em 8 de julho de 2026, a Wiz publicou "GhostApproval: A Trust Boundary Gap in AI Coding Assistants". A pesquisa relatou variações do padrão em 6 assistentes: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity e Windsurf (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", 2026). Para quem usa Codex, Claude Code ou agentes em CI, a lição é direta: resolva symlinks antes de confiar no prompt.

Resumo prático

  • GhostApproval troca confiança em "aprovar diff" por confiança em caminho canônico.
  • Symlink dentro do repo pode apontar para arquivo sensível fora do workspace.
  • Sandbox, permissões e MCP precisam validar alvo real, não só caminho aparente.
  • CI deve registrar symlinks suspeitos antes de aceitar PR agentic.

Diagrama abstrato mostra caminhos divergentes entre workspace e alvo real sem texto visível.

O que o GhostApproval realmente quebrou?

Em 2026, a Wiz relatou GhostApproval em 6 assistentes de código e disse que 3 fornecedores corrigiram rapidamente o problema: AWS, Cursor e Google (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", 2026). O padrão quebra a confiança entre o caminho exibido ao usuário e o arquivo que recebe a escrita.

O ataque usa uma ideia antiga: um arquivo dentro do workspace é, na verdade, um symlink para fora dele. O agente lê instruções, decide editar o arquivo aparente e a camada de execução segue o link até um alvo sensível, como configuração de shell ou chave de acesso.

O ponto perigoso é a diferença entre "o usuário aprovou" e "o usuário entendeu o alvo real". Se a tela mostra um arquivo local inofensivo, mas a escrita cai fora do workspace, a aprovação vira ritual. Ela existe formalmente, mas não informa o risco.

Esse recorte complementa a quarentena de repositório para agentes de código. A quarentena decide quando um repo desconhecido pode executar. GhostApproval decide se uma operação de escrita já autorizada ainda respeita o limite do workspace.

Cápsula citável: GhostApproval não é só um bug de symlink. É uma falha de fronteira em agentes de código: o usuário aprova um caminho aparente, enquanto o runtime pode escrever no alvo resolvido fora do workspace. A correção precisa unir UI, sandbox e resolução canônica.

Por que aprovação humana não basta quando o caminho é falso?

Em 2026, a MITRE descreve CWE-451 como UI que não representa informação crítica corretamente, permitindo que origem ou conteúdo sejam obscurecidos ou falsificados (MITRE, "CWE-451", 2026). Em GhostApproval, o prompt de aprovação falha exatamente aí: ele não mostra o alvo real da escrita.

Wiz chama isso de quebra de consentimento informado. O humano continua no loop, mas o loop não entrega a informação necessária para decidir. Em alguns casos relatados pela pesquisa, o agente reconhecia internamente que o caminho era perigoso, enquanto a interface mostrava apenas o nome benigno do arquivo.

Para times de engenharia, isso muda a revisão. "O agente pediu aprovação" deixa de ser evidência suficiente. A evidência útil é outra: caminho aparente, caminho resolvido, operação pretendida, permissão aplicada e escopo do sandbox.

Também muda a forma de tratar modos automáticos. Em março de 2026, a Anthropic publicou que usuários do Claude Code aprovavam 93% dos prompts de permissão e que o auto mode buscava reduzir fadiga de aprovação (Anthropic, "How we built Claude Code auto mode", 2026). Se quase tudo é aceito, o prompt precisa ser mais confiável, não apenas mais frequente.

Cápsula citável: Aprovação humana só protege agentes de código quando o prompt mostra o alvo verdadeiro. A MITRE classifica ocultação de informação crítica como CWE-451; GhostApproval aplica essa falha ao diff agentic, onde o caminho aparente pode mascarar o arquivo resolvido.

Em 2026, a MITRE define CWE-61 como falha em considerar que um arquivo pode ser symlink para fora da esfera de controle pretendida (MITRE, "CWE-61", 2026). A auditoria correta resolve o caminho antes da escrita e bloqueia quando o alvo sai do workspace autorizado.

Comece pelo inventário. Antes de deixar o agente editar, peça ou rode uma checagem de links simbólicos no repo. O objetivo não é proibir todo symlink. É separar symlink esperado, como cache ou worktree, de link que aponta para home, .ssh, configuração do agente, credenciais ou diretórios de sistema.

Em Linux e macOS, uma checagem mínima é comparar o caminho do link com o alvo real. Em revisão humana, o que importa é ver a resolução completa antes do diff:

find . -type l -print0 | while IFS= read -r -d '' link; do
  printf '%s -> %s\n' "$link" "$(realpath "$link")"
done

Depois aplique política. Links que resolvem para fora do repo entram em quarentena. Links que resolvem para ~/.ssh, arquivos de shell, diretórios de configuração de IDE, chaves de nuvem ou settings do agente devem bloquear escrita automática. Se o caso for legítimo, ele precisa de justificativa explícita.

Fluxo abstrato mostra validação entre caminho aparente e caminho real sem texto visível.

Experiência prática: eu trato symlink como dado de entrada, não como detalhe do filesystem. Em repo desconhecido, o agente pode sugerir que "é só ajustar a configuração". Antes da edição, eu quero ver o alvo resolvido e a razão para aquele link existir.

Cápsula citável: A defesa contra GhostApproval começa com resolução canônica de caminho. CWE-61 descreve exatamente o risco de operar em arquivo que resolve para fora da esfera pretendida; em agentes de código, o diff deve mostrar o link e o alvo real antes da aprovação.

Como ajustar Codex, Claude Code e MCP depois disso?

Em 2026, a documentação do Codex afirma que, por padrão, o agente roda com rede desligada e escrita limitada ao workspace local (OpenAI Developers, "Agent approvals & security", 2026). Em modos como workspace-write com on-request, esse limite precisa incluir caminho resolvido, não só prefixo textual.

No Codex, evite danger-full-access em repositório que ainda não passou por inventário de symlink. Se uma tarefa precisa de escrita fora do workspace, peça uma exceção estreita e revisável. A documentação do Codex diferencia acesso total de workspace-write com aprovação sob demanda (OpenAI Developers, "Sandbox", 2026).

No Claude Code, use permissões e sandbox juntos. A documentação de permissões diz que regras de symlink verificam dois caminhos: o link e o alvo resolvido (Claude Code Docs, "Configure permissions", 2026). Regras de allow só passam quando ambos batem. Regras de deny bloqueiam se qualquer um bater.

Em fluxos longos, eu uso o RemoteCode para economizar contexto em sessões agentic com Codex e Claude Code. Ele ajuda quando a triagem precisa atravessar inventário, logs, permissões e histórico sem repetir tudo no prompt principal. É uma ferramenta minha, então esta menção é editorial e ligada ao custo real de contexto em loops de segurança.

Para MCP, a regra é mais dura: negue por padrão até o repo passar pela triagem. A documentação do Claude Code permite negar todos os MCPs com padrão mcp__* e só liberar servidor específico depois (Claude Code Docs, "Configure permissions", 2026). Isso impede que uma escrita local vire ação lateral em GitHub, navegador, cloud ou ticket.

Cápsula citável: Depois de GhostApproval, sandbox de agente deve validar caminho canônico. Codex documenta rede desligada e escrita limitada ao workspace por padrão; Claude Code documenta checagem de symlink pelo link e pelo alvo. MCP deve começar negado e ser liberado por servidor.

Onde o CI deve entrar nessa defesa?

Em maio de 2026, o GitHub informou que o Copilot code review já processou mais de 60 milhões de revisões (GitHub Blog, "Agent pull requests are everywhere", 2026). A mesma fonte diz que mais de uma em cada cinco revisões no GitHub envolve um agente. Com esse volume, symlink precisa virar checagem automática.

O CI não substitui sandbox local. Ele aparece tarde demais para proteger a máquina do desenvolvedor. Ainda assim, ele protege o repositório compartilhado e cria evidência para revisão de PR. A checagem deve falhar quando um PR adiciona symlink para fora de diretórios permitidos.

Uma regra simples funciona bem: listar todos os symlinks novos ou alterados, resolver os alvos e publicar o resultado como artefato de revisão. Se algum alvo sair do repo, o PR precisa de aprovação de segurança. Se tocar home, segredo, configuração do agente ou arquivo de inicialização, bloqueie.

Esse controle conversa com evals de PR para agentes no CI e com hooks que seguram agentes de código. A diferença é que a checagem de symlink não mede qualidade do código. Ela mede se o diff representa a escrita real.

Cápsula citável: CI deve tratar symlink como mudança de fronteira, não como detalhe de arquivo. GitHub relata dezenas de milhões de revisões com agente; nesse volume, cada PR agentic precisa expor link simbólico, alvo resolvido e decisão de bloqueio antes do merge.

Qual checklist usar no próximo repo?

Em 2025, o Stack Overflow Developer Survey disse que 84% dos respondentes usavam ou planejavam usar ferramentas de IA no desenvolvimento (Stack Overflow, "2025 Developer Survey: AI", 2025). A mesma pesquisa mostrou 51% dos profissionais usando diariamente. Em 2026, o Stack Overflow relatou uso diário de IA no trabalho em 58% (Stack Overflow Blog, "Domain expertise still wanted", 2026). A escala pede checklist repetível.

Use este fluxo antes de aceitar edição de agente em repo desconhecido ou PR gerado por agente:

  • Liste symlinks e registre o alvo resolvido de cada um.
  • Bloqueie escrita automática se o alvo sair do workspace.
  • Negue qualquer alvo em home, .ssh, shell, credenciais, IDE, .git, .claude ou MCP.
  • Mostre no prompt de aprovação o caminho aparente e o caminho canônico.
  • Rode o agente com rede desligada até a triagem terminar.
  • Mantenha MCP negado até saber por que cada servidor é necessário.
  • Faça o CI falhar quando um novo symlink aponta para fora do repo.
  • Exija revisão humana específica para exceções documentadas.
Sinal no PR Decisão prática
Symlink aponta para dentro do repo e tem motivo claro Permita com revisão normal do diff.
Symlink aponta para fora do workspace Bloqueie escrita automática e peça aprovação de segurança.
Symlink toca shell, SSH, credencial, .git, .claude ou IDE Bloqueie o PR até remover ou justificar o alvo.
Agente pede MCP antes da triagem Negue a ferramenta e registre a necessidade real.

Checklist abstrato mostra etapas de validação para agentes de código sem texto visível.

O erro comum é achar que "não usamos Windsurf" ou "não usamos Amazon Q" resolve. GhostApproval é uma classe de design. A pergunta certa é: sua ferramenta mostra o alvo real antes de escrever, e seu ambiente bloqueia quando esse alvo cruza a fronteira?

Cápsula citável: O checklist mínimo para GhostApproval combina inventário de symlink, resolução canônica, bloqueio fora do workspace, MCP negado por padrão e CI com falha explícita. A adoção diária de IA por desenvolvedores torna esse controle operacional, não opcional.

Perguntas frequentes (FAQ)

GhostApproval afeta só Claude Code?

Não. Em 2026, a Wiz relatou variações em 6 assistentes de código: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity e Windsurf (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants"). O ponto prático é auditar sua ferramenta atual, porque a falha é de fronteira entre UI, symlink e runtime.

Atualizar a ferramenta resolve tudo?

Não sozinho. Em 2026, a AWS publicou CVE-2026-12958 e corrigiu a falha em Language Servers for AWS 1.69.0 (AWS Security Bulletin 2026-047-AWS). Atualização reduz risco de produto, mas seu fluxo ainda precisa resolver symlink, limitar workspace, revisar MCP e bloquear exceções no CI.

Qual arquivo é mais perigoso nesse ataque?

Não existe um único arquivo. Em 2026, o NVD descreveu CVE-2026-12958 como escrita arbitrária fora da fronteira do workspace por symlink malicioso (NVD, "CVE-2026-12958"). Na prática, trate como sensíveis arquivos de shell, chaves SSH, credenciais, configurações do agente, hooks de Git e arquivos usados por IDE.

Sim, com política. Em 2026, a documentação do Claude Code afirma que regras de allow para symlink exigem que o link e o alvo combinem (Claude Code Docs, "Configure permissions"). Regras de deny bloqueiam se qualquer um combinar. Monorepo pode usar symlink legítimo, mas precisa mostrar alvo canônico e motivo.

Fontes

  • Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", consultado em 2026-07-11, https://www.wiz.io/blog/ghostapproval-a-trust-boundary-gap-in-ai-coding-assistants
  • AWS, "CVE-2026-12957 and CVE-2026-12958 - Issues in Language Servers for AWS and Amazon Q Developer Plugins", consultado em 2026-07-11, https://aws.amazon.com/security/security-bulletins/2026-047-aws/
  • GitHub Advisory Database, "Arbitrary file write in Language Servers for AWS", consultado em 2026-07-11, https://github.com/aws/language-servers/security/advisories/GHSA-6v3r-4p5c-mrp5
  • NVD, "CVE-2026-12958", consultado em 2026-07-11, https://nvd.nist.gov/vuln/detail/CVE-2026-12958
  • MITRE, "CWE-61: UNIX Symbolic Link (Symlink) Following", consultado em 2026-07-11, https://cwe.mitre.org/data/definitions/61.html
  • MITRE, "CWE-451: User Interface (UI) Misrepresentation of Critical Information", consultado em 2026-07-11, https://cwe.mitre.org/data/definitions/451.html
  • OpenAI Developers, "Agent approvals & security", consultado em 2026-07-11, https://developers.openai.com/codex/agent-approvals-security
  • OpenAI Developers, "Sandbox", consultado em 2026-07-11, https://developers.openai.com/codex/concepts/sandboxing
  • Claude Code Docs, "Configure permissions", consultado em 2026-07-11, https://code.claude.com/docs/en/permissions
  • Anthropic, "How we built Claude Code auto mode", consultado em 2026-07-11, https://www.anthropic.com/engineering/claude-code-auto-mode
  • GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", consultado em 2026-07-11, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
  • Stack Overflow, "2025 Developer Survey: AI", consultado em 2026-07-11, https://survey.stackoverflow.co/2025/ai
  • Stack Overflow Blog, "Domain expertise still wanted: the latest trends in AI-assisted knowledge for developers", consultado em 2026-07-11, https://stackoverflow.blog/2026/03/16/domain-expertise-still-wanted-the-latest-trends-in-ai/