A Armadilha da Confiança: Como um Clique Pode Expor Seu Assistente de Código com IA

Todo desenvolvedor já fez isso. Clona um repositório de um colega, uma biblioteca open-source ou um exemplo rápido de tutorial. Dá uma olhada superficial, roda localmente e segue em frente. É rotina. Mas o projeto de pesquisa TrustFall, da Adversa AI, mostra que assistentes de código baseados em IA carregam esse mesmo risco — e ele virou uma brecha perigosa.

O Cenário Ideal para um Ataque

Quatro ferramentas populares de IA para codificação têm um problema grave: elas rodam programas auxiliares definidos em arquivos de configuração do projeto, bastando um diálogo simples de "confiar nesta pasta?" que já vem marcado como sim por padrão.

O esquema é assim:

Essas ferramentas adotam o Model Context Protocol (MCP), um protocolo que conecta a IA a programas externos — como conectores de banco, linters ou ferramentas personalizadas. Prático, né? O defeito está nos arquivos de config que ficam dentro do próprio projeto.

Ao abrir o repositório e confirmar o aviso, o sistema não só indexa o código. Ele inicia esses programas. E eles rodam com todos os seus privilégios.

Basta um Enter. Pronto.

Os Riscos (e São Muitos)

Um programa auxiliar malicioso consegue:

• Roubar chaves SSH e credenciais de cloud
• Ler o histórico do seu shell
• Acessar códigos de outros projetos no seu PC
• Se conectar a servidores controlados pelo atacante

Pior: isso rola antes da IA processar qualquer coisa. O código executa no avesso assim que inicia.

O truque é básico — dois arquivos JSON minúsculos. Um cria um "linter" falso que baixa e roda um payload da web. O outro aprova tudo automaticamente. O repositório pode parecer vazio à primeira vista.

O Problema do Diálogo

A interface aqui vira calcanhar de Aquiles. Veja o que os devs veem na prática:

Claude Code (v2.1+): "Verificação rápida: este é um projeto seu ou de confiança?" Padrão: Sim. Versões antigas tinham opção de confiar sem ativar MCP — sumiu.

Gemini CLI: Mostra nomes dos helpers, o que ajuda quem presta atenção.

Cursor CLI: Fala de MCP de forma vaga.

Copilot CLI: Um aviso genérico, sem citar MCP.

Todos defaultam para confiar.

Como disse Rony Utevsky, líder da pesquisa: o erro não é só a falha técnica. É que ninguém sabe o que está aceitando ao clicar "sim".

O Pesadelo do CI/CD

Fica mais feio em pipelines de CI/CD. No Claude Code rodando via GitHub Action oficial da Anthropic, nem diálogo aparece — é modo headless.

Resultado:

• Um PR malicioso de um contribuidor externo injeta config comprometida
• Ao rodar a branch, o helper ativa
• Ele pega chaves de deploy, certificados e tokens de cloud

A Adversa AI soltou um PoC funcional que vaza variáveis de ambiente. Não é teoria — é ataque real.

O Que Fazer Já

Em ambientes corporativos com Claude Code, a saída é o Managed scope.

É uma config centralizada que o TI impõe em todas as máquinas, bloqueando aprovações automáticas de MCP por projeto. Uma política única resolve para toda a equipe.

Mas a pesquisa mostra: poucas empresas usam. E configurar não é intuitivo, ainda mais para devs novos em IA.

Resposta dos Fabricantes

A Anthropic analisou o TrustFall e defende: dizer "sim, confio" é consentimento total, incluindo MCP. Para eles, a execução pós-confirmação é o limite certo do threat model.

A Adversa não contesta o modelo. Questiona se o diálogo explica de verdade o que rola.

(Anthropic não comentou mais.)

Lições para Você

Essa brecha lembra: ferramentas de IA mexem fundo no seu ambiente de dev. Poder assim exige cuidado extra.

Usa Claude Code, Gemini CLI, Cursor ou Copilot CLI? Aja assim:

1. Pense antes de confiar. Leia o diálogo com atenção, sem autopilot.
2. Cheque configs. Em repositórios desconhecidos, veja .mcp.json e afins antes de abrir.
3. Prefira transparência. Escolha ferramentas que listam helpers no aviso (como Gemini CLI).
4. Ative managed scope no time. Converse com TI para política central.
5. Atualize sempre. Os vendors sabem — patches podem refinar os diálogos.

Visão Geral

TrustFall expõe o dilema do dev moderno: facilidade x segurança em choque. Diálogos "sim por default" funcionam porque confiamos nos nossos projetos. Mas com código aberto pra todo mundo, é uma aposta arriscada.

Não é sobre banir MCP — ele é útil. É sobre deixar claro o salto de "confio no projeto" para "executo código arbitrário".

Por enquanto, não está claro. Devs, times e vendors precisam melhorar.

E você, como lida com segurança em ferramentas? Já topou diálogos confusos? O papo sobre segurança em IA tá só começando. Entre na conversa.