GhostApproval: o Symlink Que Engana 6 Agentes de Código

Toda vez que eu aprovo uma edição de agente de código, eu olho o nome do arquivo, dou uma espiada rápida no diff e clico em aceitar. É assim que praticamente todo mundo usa esses agentes no dia a dia. A promessa da aprovação é simples: você vê o que vai acontecer antes de autorizar.

A Wiz acabou de mostrar que essa promessa pode ser falsa em pelo menos seis dos principais agentes de código do mercado. Batizaram a técnica de GhostApproval. Ela usa um truque de symlink tão velho quanto o próprio Unix para fazer o agente escrever num arquivo sensível enquanto a caixa de aprovação mostra outro nome, completamente inofensivo.

O motivo de eu estar escrevendo sobre isso não é só o bug em si. É o que ele revela sobre a arquitetura de consentimento desses agentes, e sobre uma resposta de fornecedor que divide opinião: a Anthropic decidiu que isso não é vulnerabilidade nenhuma.

---

O Golpe do Link Que Não É o Que Parece

A mecânica do GhostApproval é enganosamente simples. Dentro de um repositório, alguém coloca um symlink com nome inofensivo, algo como project_settings.json. Visualmente, parece só mais um arquivo de configuração do projeto.

Só que esse link não aponta para um arquivo de configuração de verdade. Ele aponta para um alvo sensível na máquina do desenvolvedor, por exemplo o diretório .ssh onde ficam as chaves de acesso remoto. É um link simbólico, então o sistema operacional trata as duas coisas como se fossem uma só.

O gatilho é banal. O desenvolvedor clona o repositório e pede ao agente para "configurar o workspace" ou simplesmente seguir as instruções do README. O agente, fazendo exatamente o que foi pedido, escreve conteúdo controlado pelo atacante no arquivo indicado, project_settings.json. Como esse arquivo é na verdade um link, quem recebe a escrita é o alvo real por trás dele.

Quando o alvo é a chave pública SSH autorizada, o resultado é acesso remoto sem senha para quem preparou o repositório. Nenhuma exploração sofisticada, nenhum zero-day de verdade. Só um link mal colocado e um agente obediente demais.

---

A Caixa de Diálogo Que Mente Sobre o Alvo

Esse ataque só funciona porque existe uma quebra específica no fluxo de aprovação. É aqui que mora o problema de fundo, e é por isso que ele merece atenção mesmo depois que os patches saírem.

Em vários dos agentes analisados, o agente resolve o caminho do symlink internamente, sabe exatamente que a escrita vai parar no diretório .ssh. Mas a caixa de diálogo que pede sua aprovação mostra o nome do link, não o destino real. Você aprova achando que está editando um JSON de configuração.

Isso é, na prática, uma quebra de consentimento informado. Você não recusou o risco, você nunca teve chance de vê-lo. A interface criou a ilusão de controle sem entregar a informação que tornaria esse controle real.

Vale fazer o paralelo com a história da segurança em sistemas Unix. Ataques de symlink e as chamadas condições de corrida TOCTOU, "time of check to time of use", são conhecidos desde os anos 80 e 90, quando scripts com privilégio elevado escreviam em arquivos temporários sem verificar se o caminho tinha sido trocado por um link entre a checagem e a escrita. A lição de décadas atrás era clara: nunca confie no nome, valide o destino resolvido. Os agentes de código, construídos décadas depois, reintroduziram exatamente essa falha, só que agora com um humano no lugar do script como a parte enganada.

---

Seis Agentes, Duas Posturas Diferentes

A Wiz reportou o GhostApproval aos seis fornecedores afetados no início de 2026: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity e Windsurf. A resposta de cada um diz bastante sobre a cultura de segurança por trás do produto.

Amazon, Google e Cursor trataram o achado como vulnerabilidade de verdade e lançaram correções. A Cursor foi além e formalizou o problema com um identificador público, o CVE-2026-50549, o que facilita rastrear o patch e cobrar aplicação em ambientes corporativos.

Augment e Windsurf ficaram no meio do caminho. Reconheceram o relatório da Wiz, mas até a publicação da pesquisa não haviam lançado correção nenhuma. Isso deixa usuários desses agentes numa posição desconfortável: sabem que o risco existe, mas não têm um patch para aplicar, só a opção de mudar comportamento manualmente.

A Anthropic tomou o caminho mais radical, discordou publicamente de que o comportamento do Claude Code fosse uma vulnerabilidade. O argumento é que o usuário que confia num diretório e aprova uma edição é dono dessa decisão, e que esse cenário está fora do threat model deles. Em outras palavras, para a Anthropic isso é comportamento esperado do sistema, não uma falha a ser corrigida.

---

"Confiar no Diretório" Não É Resposta Suficiente

Esse é o ponto onde eu discordo da Anthropic, e vale explicar por quê, porque a superfície do argumento até parece razoável. Você abriu o diretório, você aprovou, você é dono da decisão.

O problema é o que "confiar no diretório" realmente significa na prática de quem usa agente de código todo dia. Ninguém audita byte a byte um repositório open source antes de clonar. A confiança que você deposita é herdada, você confia porque o projeto tem estrelas, porque um colega recomendou, porque está numa lista de dependências aprovadas. Isso não é o mesmo tipo de confiança que justificaria aprovar uma escrita nas suas chaves SSH sem saber.

Um README malicioso, ou até um README legítimo comprometido numa atualização, é tudo que é preciso para acionar o GhostApproval. O desenvolvedor não está aprovando "confiar neste diretório inteiro para sempre". Está aprovando uma ação pontual, específica, que a interface descreveu de forma incompleta. Tratar as duas coisas como equivalentes é embutir uma expectativa de vigilância que nenhum humano sustenta na prática.

Isso conecta direto com algo que já escrevi por aqui sobre o problema do agente com fome de permissão e a lethal trifecta. Um agente de código que lê conteúdo de repositórios externos, tem acesso a dados sensíveis da máquina do desenvolvedor e pode agir sem revisão detalhada carrega, por design, os três ingredientes da trifecta. O GhostApproval é só mais uma forma concreta de acionar essa combinação, dessa vez explorando a própria caixa de diálogo de aprovação em vez de um prompt injection clássico.

Terceirizar esse risco inteiro para "o usuário devia ter revisado melhor" ignora que a interface foi desenhada, ativamente, para não mostrar a informação necessária para essa revisão acontecer. Postura defensiva de fornecedor é legítima quando o usuário de fato tinha os dados para decidir. Aqui, ele não tinha.

---

Mitigações Práticas Para Quem Roda Agente em Produção

Correção do fornecedor é o ideal, mas Augment, Windsurf e, no caso da Anthropic, uma discordância declarada de que exista bug, significam que você não pode esperar sentado. Dá para reduzir a exposição hoje, sem abrir mão do agente.

O primeiro passo é isolamento físico entre onde o agente trabalha e onde ficam seus segredos reais. Rode o agente num container ou máquina virtual efêmera, sem a chave SSH pessoal montada, sem acesso direto ao seu .ssh de produção. Se o alvo do symlink não existe no sistema de arquivos que o agente enxerga, o ataque não tem para onde escrever.

O segundo é desconfiar sistematicamente de repositório de terceiros. Clonar um projeto open source novo e pedir ao agente para "seguir o README" é exatamente o cenário que o GhostApproval explora. Trate onboarding automático de repositório desconhecido como zona de risco, revise manualmente antes de deixar o agente executar instruções vindas de dentro do repo.

Terceiro, e mais trabalhoso, mas necessário: quando a caixa de aprovação pedir para confirmar uma escrita, não confie só no nome exibido. Onde o agente ou o terminal permitir, verifique o caminho resolvido de fato antes de aceitar, principalmente em repositórios que você não escreveu.

Alguns ajustes práticos que valem a pena revisar agora:

• Desative aprovação automática (auto-approve) em qualquer repositório fora do seu controle direto.
• Rode agentes de código dentro de sandbox com sistema de arquivos restrito, sem montar diretórios de credenciais.
• Audite periodicamente authorized_keys e diretórios sensíveis por entradas que você não reconhece.
• Trate atualização de agente como patch de segurança, não só de feature, e aplique assim que disponível nos fornecedores que corrigiram.

Essas medidas se somam à disciplina de identidade que já detalhei no post sobre IAM para identidades não-humanas: credencial de longa duração e escopo amplo na máquina onde o agente roda é o que transforma um symlink perdido num incidente de acesso remoto completo. Escopo mínimo e credencial efêmera limitam o estrago mesmo quando a interface falha em mostrar a verdade.

---

Conclusão

O GhostApproval não é sofisticado, e é exatamente por isso que ele importa. Ele reaproveita um truque de décadas atrás, symlink disfarçado, para explorar uma lacuna nova, a caixa de aprovação que descreve a ação errada. Três fornecedores corrigiram, dois ficaram quietos, e um decidiu que o problema é seu, não deles.

Concordar ou não com a Anthropic é secundário diante da conclusão prática: você não pode depender inteiramente da boa vontade ou da postura de segurança de cada fornecedor. Isole o ambiente onde o agente roda, desconfie de repositório de terceiros por padrão e trate a caixa de aprovação como o que ela é hoje, uma ferramenta útil mas falível, não uma garantia de que você viu tudo antes de dizer sim.

---

Fontes:

• GhostApproval: AI Coding Assistant Trust Boundary Flaw — Wiz
• Bug in top AI coding agents shows that Unix-era security headaches never really die — The Register