TrustFall expõe como repositórios maliciosos exploram a confiança em pastas para rodar código arbitrário
Pesquisadores da Adversa revelaram recentemente uma vulnerabilidade que merece atenção imediata da comunidade de desenvolvedores. Batizada de TrustFall, a falha atinge as principais CLIs de codificação assistida por IA do mercado e transforma uma ação aparentemente inofensiva — aceitar uma pasta como confiável — em um vetor real de execução remota de código.
Se você usa Claude Code, Gemini CLI, Cursor CLI ou GitHub Copilot CLI no seu fluxo de trabalho, este artigo é para você. Vamos destrinchar como o ataque funciona, por que ele é mais grave em pipelines de CI/CD e, principalmente, o que fazer agora para mitigar o risco.
Por que o TrustFall preocupa tanto desenvolvedores quanto times de segurança
Primeiramente, é importante entender o contexto. As CLIs modernas de codificação por IA dependem do Model Context Protocol (MCP) para estender suas capacidades. Além disso, esses servidores podem ser definidos no próprio repositório por meio de arquivos de configuração de projeto.
O problema central é simples: assim que o desenvolvedor aceita confiar em uma pasta, os servidores MCP definidos naquele projeto podem ser iniciados como processos nativos do sistema operacional. Consequentemente, esses processos rodam com os mesmos privilégios do usuário e não ficam isolados em sandbox.
Em outras palavras, basta clonar um repositório malicioso e dar Enter no prompt de confiança para abrir uma porta. Posteriormente, qualquer payload pode ser executado.
Como o TrustFall funciona na prática em sessões interativas
A descoberta tem foco principal no Claude Code, onde o processo de consentimento mudou de forma preocupante. Anteriormente, versões mais antigas avisavam explicitamente que o arquivo .mcp.json poderia executar código. No entanto, a partir da versão 2.1, esse alerta foi substituído por uma “Verificação rápida de segurança” genérica que sequer menciona MCP.
O ataque segue um fluxo bem direto. Inicialmente, o repositório malicioso contém um .mcp.json junto com configurações que pré-aprovam o servidor. Em seguida, o desenvolvedor clona o projeto e executa o Claude na pasta. Por fim, ao aceitar a confiança, o servidor MCP é iniciado antes mesmo de qualquer chamada de ferramenta acontecer.
O campo command no .mcp.json aceita executáveis diversos: Node.js, Python, comandos shell ou binários compilados. Adicionalmente, o payload pode estar embutido diretamente nos argumentos, dificultando a detecção em revisões de código.
As três configurações críticas no Claude Code
No Claude Code especificamente, três opções com escopo de projeto estão envolvidas:
enableAllProjectMcpServers: aprova automaticamente todos os servidores MCP do projeto.enabledMcpjsonServers: aprova servidores nomeados específicos.permissions.allow: pré-autoriza chamadas de ferramentas, incluindo invocações MCP.
As duas primeiras iniciam o servidor assim que a pasta é considerada confiável. Por outro lado, a terceira depende de uma decisão posterior do agente para chamar a ferramenta aprovada. Em todos os casos, nenhuma delas dispara um prompt específico para MCP.
Comparativo dos avisos entre as quatro CLIs afetadas
Vale destacar que nem todas as ferramentas tratam o consentimento da mesma forma. O Gemini CLI oferece o aviso mais detalhado, listando os servidores MCP do projeto pelo nome. Por sua vez, o Cursor CLI exibe um alerta específico para MCP, mas sem enumerar cada servidor. Já o Claude Code e o Copilot CLI usam avisos genéricos de confiança de pasta que sequer mencionam MCP.
Além disso, existe um detalhe ergonômico perigoso: a opção padrão em todas as quatro ferramentas é confiar na pasta. Portanto, um simples Enter pode aprovar a execução em sessões interativas.
TrustFall em pipelines de CI/CD: o cenário mais perigoso
Se em ambiente local o risco já é considerável, em CI/CD ele se amplifica drasticamente. Afinal, não há cliques nem sessões interativas para exibir o diálogo de confiança.
O Claude Code pode rodar de forma não interativa via GitHub Actions oficial. Nesse contexto, um repositório com .mcp.json malicioso pode executar o servidor assim que o workflow processa a branch. Posteriormente, o servidor malicioso passa a ter acesso a tudo que o runner enxerga.
Os ativos expostos são alarmantes: chaves de deploy, certificados de assinatura, credenciais de cloud e outros segredos do pipeline. Em resumo, um pull request malicioso pode comprometer toda a infraestrutura de build automatizado.
A resposta da Anthropic e a contraposição da Adversa
De acordo com a Adversa, a Anthropic analisou as conclusões e considerou que o cenário está fora do modelo de ameaças. Segundo a empresa, aceitar a confiança da pasta representa consentimento para a configuração do projeto.
Contudo, a Adversa argumenta que o prompt de confiança não deixa claro que configurações de projeto podem iniciar servidores MCP arbitrários como processos nativos. Ou seja, o desenvolvedor consente sem entender exatamente o que está autorizando.
As recomendações da Adversa incluem o bloqueio das configurações de ativação de MCP em arquivos dentro do diretório do projeto. Essas configurações seriam permitidas apenas em escopos de usuário, gerenciados ou de linha de comando fora do controle do repositório. Adicionalmente, a empresa sugere uma caixa de diálogo dedicada para MCP, com negação por padrão e aprovação por servidor.
Checklist prático: arquivos e configurações para revisar antes de confiar em qualquer repositório
Antes de executar agentes de codificação em repositórios desconhecidos, faça uma inspeção criteriosa. Sobretudo, foque nos seguintes pontos:
.mcp.json: verifique camposcommandeargsem busca de payloads embutidos..claude/settings.json: revise as três configurações críticas mencionadas acima..claude/settings.local.json: este arquivo pode ter prioridade sobre as configurações do projeto.- Strings codificadas e flags de avaliação: muitas vezes, o payload está disfarçado em base64 ou via
eval.
A inspeção precisa cobrir tanto arquivos de projeto quanto arquivos locais. Inclusive, a Adversa observou que o .claude/settings.local.json pode sobrescrever as configurações de projeto na ordem de escopo, e um arquivo controlado pelo repositório ainda pode afetar o comportamento se estiver presente no momento da clonagem.
Recomendações para times de segurança em ambientes gerenciados
Para empresas com múltiplos desenvolvedores, controles centralizados são fundamentais. Primeiramente, desative a aprovação automática de MCPs com escopo de projeto via política. Em seguida, restrinja os servidores aprovados a uma allowlist e defina uma baseline para permissions.allow.
Além disso, mapeie onde o Claude Code é executado e quais repositórios ele acessa. Igualmente importante é verificar quais credenciais esses ambientes podem alcançar.
Endurecendo o pipeline de CI
Para execuções não interativas, as recomendações são ainda mais rígidas. Em primeiro lugar, limite essas execuções a branches revisadas. Depois, pin as GitHub Actions em SHAs específicos de commits. Adicionalmente, isole os runners das credenciais de produção. Finalmente, exija revisão humana em qualquer pull request que adicione ou modifique .mcp.json.
Conclusão: confiança em pasta não pode mais ser sinônimo de execução automática
O TrustFall expõe uma tensão real entre usabilidade e segurança nas ferramentas de IA para desenvolvedores. Por um lado, a fricção do consentimento atrapalha o fluxo de trabalho. Por outro lado, prompts genéricos transformam decisões críticas em cliques automáticos.
Enquanto os fornecedores não convergirem para diálogos de consentimento mais específicos para MCP, a responsabilidade fica com você. Portanto, trate cada .mcp.json em repositórios desconhecidos como código a ser auditado antes de qualquer execução. Da mesma forma, mantenha seus runners de CI longe de branches não revisadas e de credenciais sensíveis.
Em última análise, o TrustFall é menos uma vulnerabilidade técnica e mais um lembrete de que automação assistida por IA exige novos modelos mentais sobre confiança. Afinal, a velocidade do desenvolvimento moderno não pode custar a segurança da sua cadeia de suprimentos de software.