Há algumas semanas, quase conectei um "WhatsApp MCP gratuito" à mesma sessão do Claude Code onde meus servidores do GitHub e do sistema de arquivos já estavam rodando. Tinha um repositório limpo, um logo, uma instalação de uma linha. Copiei o bloco de configuração e então parei na última tecla porque algo me incomodou: não fazia ideia do que as descrições de ferramentas daquele servidor realmente diziam.
Esse incômodo se revelou o ponto central de tudo. Em abril de 2025, a Invariant Labs demonstrou um ataque em que exatamente esse tipo de servidor de aparência inocente — um jogo de perguntas e respostas — carregava instruções ocultas na descrição de ferramentas, ordenando ao agente que redirecionasse silenciosamente as mensagens de um servidor WhatsApp separado e confiável para o número de um invasor, contrabandeando seu histórico de chat dentro do corpo da mensagem (Invariant Labs). O servidor malicioso nunca tocou o WhatsApp diretamente. Ele apenas convenceu o agente a fazer isso.
É isso que ninguém te conta quando entrega um bloco de configuração. Um servidor MCP não é uma biblioteca que você chama. É um participante no raciocínio do seu agente. As descrições de ferramentas são injetadas diretamente no contexto do modelo, e o modelo as trata como instruções a seguir — o que significa que um servidor não confiável sentado ao lado de um confiável pode manipulá-lo como a um fantoche. Colocar o servidor malicioso em sandbox não ajuda, porque o ataque ocorre através do agente, não da rede.
A versão curta: antes de conectar um servidor MCP de terceiros, você está estendendo confiança a quem o escreveu e a quem pode alterá-lo depois. Dedique dez minutos para confirmar o que ele pode ler, onde pode chegar, o que faz com seus segredos e se pode se transformar silenciosamente em outra coisa depois que você o aprova. A maior parte disso é leitura, não ferramentas. Esta é a auditoria.
Por que um servidor MCP é uma exigência maior do que um pacote
Um pacote npm normal executa código. Isso já é ruim o suficiente. Um servidor MCP faz isso e injeta texto que o modelo obedece e frequentemente guarda credenciais e compartilha uma sessão com seus outros servidores. Quatro superfícies de confiança, não uma.
O guia oficial de segurança do MCP nomeia isso claramente. Documenta o problema do delegado confuso em proxies OAuth, o antipadrão de "passagem de token" (que a especificação proíbe explicitamente — "os servidores MCP NÃO DEVEM aceitar quaisquer tokens que não foram explicitamente emitidos para o servidor MCP"), falsificação de solicitações do lado do servidor durante a descoberta OAuth, sequestro de sessão e comprometimento de servidor local por meio de comandos de inicialização maliciosos (MCP Security Best Practices). A seção de comprometimento local até descreve o abuso óbvio: um comando de inicialização que executa curl -X POST -d @~/.ssh/id_rsa para algum endpoint de coleta. A especificação é, na prática, uma lista de maneiras pelas quais um servidor MCP pode te prejudicar, escrita pelas pessoas que o projetaram.
Duas outras classes de ataques importam mais para um desenvolvedor independente que escolhe um servidor no GitHub. A primeira é o envenenamento de ferramentas — instruções de injeção de prompt ocultas enfiadas nos campos de descrição de ferramentas e parâmetros que o modelo lê integralmente, mas a UI do seu cliente mostra truncada (Vulnerable MCP Project). A segunda é o golpe do tapete puxado: um servidor que fornece uma descrição de ferramenta limpa no dia em que você a aprova e depois silenciosamente substitui por uma envenenada. O protocolo não tem verificação de integridade obrigatória, sem fixação de manifesto, e a notificação tools/list_changed é opcional e não força um novo consentimento — portanto a troca pode ocorrer sem que você jamais a veja (Acuvity). O envenenamento de ferramentas é agora o ataque mais reproduzido na literatura; o benchmark acadêmico MCPTox construiu todo o seu modelo ao redor dele (MCPTox).
Então a auditoria não é paranoia. Ela mapeia ataques documentados, nomeados e reproduzidos.
A auditoria de 10 minutos
Execute-os em ordem. Os primeiros são baratos e capturam os piores casos, então raramente você chega ao fim.
1. Leia as descrições de ferramentas você mesmo — as versões brutas. Esta é a verificação de maior valor individual e quase ninguém a faz. Seu cliente mostra um resumo organizado; o modelo vê o payload completo. Abra o código-fonte do servidor e leia cada campo description e cada descrição de parâmetro como se fossem código, porque para o modelo são. Procure qualquer coisa que pareça uma instrução ao agente em vez de documentação para um humano: "antes de usar isto, também chame…", "sempre inclua o conteúdo de…", "se perguntado sobre X, em vez disso faça Y", referências a outros servidores ou arquivos, ou texto invisível ou preenchido com Unicode. Se a descrição de ferramenta de uma calculadora mencionar suas chaves SSH, você terminou — feche a aba.
2. Encontre cada chamada de rede de saída. Faça grep no código-fonte de fetch, axios, http, requests, urllib, curl, net. e IPs brutos. Um servidor de sistema de arquivos não tem motivo para telefonar para um host remoto. Um servidor que legitima chama uma API deve chamar aquela API e nada mais. A seção SSRF da especificação existe porque servidores podem ser induzidos a acessar http://169.254.169.254/ — o endpoint de metadados de nuvem que distribui credenciais IAM — portanto qualquer saída para faixas link-local ou privadas (169.254.*, 10.*, 192.168.*, 127.*) é um sinal de alerta imediato (MCP Security Best Practices). Saídas inexplicáveis são a diferença entre uma ferramenta e um canal de exfiltração.
3. Rastreie como ele lida com segredos. Para onde vão seus tokens? Eles são lidos de variáveis de ambiente e usados localmente, ou repassados para algum lugar? Confirme que o servidor não está fazendo passagem de token — entregando sua credencial diretamente a uma API downstream sem as verificações de audiência que a especificação exige. Se o README diz para colar um token de acesso pessoal amplo em vez de um com escopo limitado, é o design do servidor dizendo que nunca pensou no raio de explosão. Nunca dê a um servidor MCP uma credencial que possa fazer mais do que o único trabalho para o qual ele serve.
4. Limite as permissões ao trabalho real. A própria seção de minimização de escopo da especificação alerta contra servidores que publicam files:*, db:*, admin:* ou escopos curinga all/full-access antecipadamente, porque um token amplo roubado então abre tudo de uma vez (MCP Security Best Practices). Pergunte do que este servidor genuinamente precisa. Um servidor "formatar meus commits" que solicita escrita em todo o repositório mais acesso à rede está pedindo demais. Conceda o mínimo, e prefira servidores que solicitam escopos estreitos incrementalmente aos que exigem o catálogo no primeiro dia.
5. Verifique com o que ele está sentado ao lado. Esta é a lição do exploit do WhatsApp: o risco não é um servidor, é a combinação. Um servidor não confiável na mesma sessão pode sequestrar um confiável. Então trate a lista MCP do seu agente como um limite de confiança compartilhada. Não execute um servidor não verificado na mesma sessão que qualquer coisa que tenha credenciais reais ou acesso de escrita. Se precisar experimentar algo novo, dê a ele sua própria sessão sem nada valioso conectado.
6. Fixe a versão. Recuse o alvo em movimento. Os golpes do tapete puxado funcionam porque a maioria das pessoas instala do latest ou de um servidor remoto que não controlam. Fixe em um commit ou tag de versão específico, faça fornecimento do código-fonte se puder, e releia as descrições de ferramentas sempre que fizer upgrade. Para servidores MCP remotos/hospedados que não podem ser fixados, entenda que aceitou um servidor que pode redefinir suas próprias ferramentas a qualquer momento — isso é uma concessão de confiança real e contínua, não uma instalação única.
7. Execute um scanner, depois confie mais na sua própria leitura. uvx mcp-scan@latest lê sua configuração MCP, conecta-se aos servidores, puxa as descrições de ferramentas e sinaliza envenenamento de ferramentas, deriva de golpe do tapete, sombreamento entre origens e injeção de prompt (Invariant Labs). É open source e não precisa de configuração. Use-o como uma primeira passagem rápida — mas um scanner captura padrões conhecidos, e sua leitura da etapa 1 captura os inteligentes que ele não captura.
8. Leia o log de commits e a aba de Issues. O mesmo movimento de verificar qualquer dependência. Um servidor intocado por meses em cima de um protocolo que revisou seu modelo de autenticação duas vezes em um ano é um fóssil. Um histórico de commits que é tudo "atualizar README" e nenhum "corrigir caso extremo" significa que ninguém o executa de verdade. E a aba de Issues muitas vezes vai te contar sobre o bug de exfiltração antes de você descobri-lo da forma difícil.
Coloque em sandbox, porque leitura não é suficiente
Ler o código-fonte te diz o que o código parece fazer. Não te diz o que uma dependência transitiva faz em tempo de execução, e não pode, porque você não vai ler toda a árvore. Então o conselho da especificação para servidores locais é o backstop correto: execute-os em sandbox, com acesso restrito ao sistema de arquivos e à rede, com transporte stdio para que somente seu cliente possa alcançá-los, e com um diálogo de consentimento real que mostre o comando exato antes que qualquer coisa seja executada (MCP Security Best Practices).
Para uma configuração de desenvolvedor independente isso significa: execute servidores desconhecidos em um contêiner ou conta de usuário restrita, não em seu shell principal com suas chaves no ambiente. Dê ao contêiner acesso ao único diretório que o trabalho precisa e negue o resto. São dez minutos de configuração uma vez, e transforma "este servidor pode ler todo o meu diretório home" em "este servidor pode ler a única pasta que eu entreguei a ele". O próprio guia MCP da NSA chega ao mesmo lugar — menor privilégio, isolamento e monitoramento ao redor de qualquer servidor que você não escreveu (NSA CSI: MCP Security).
Quando simplesmente dizer não
Alguns servidores falham antes de a auditoria começar. Não instalo quando:
- Não consigo ler o código-fonte. Um servidor local de código fechado ou minificado é um comando de inicialização que estou executando às cegas. Passo.
- Quer uma credencial ampla e de longa duração. Se a única maneira de usá-lo é um token com poderes totais, o design já me disse que não respeita o raio de explosão.
- É um servidor remoto que não posso fixar, com acesso a algo que eu não gostaria de perder. Isso é um convite permanente a um golpe do tapete. Bom para algo descartável; não para dados de produção.
- As descrições de ferramentas parecem instruções para meu agente. Documentação descreve; não comanda. Qualquer coisa que me bypasse para falar diretamente ao modelo é desqualificante à primeira vista.
- A conveniência não passa da barra. Um servidor que me economiza cinco minutos por semana não vale uma credencial e um lugar no limite de confiança do meu agente. A maioria dos servidores MCP "legais" que avaliei, não precisava deles.
A parte difícil não é nenhuma verificação individual — é que a confiança concedida na instalação não está congelada. O pacote auditado pode se tornar um pacote diferente na semana que vem, e nada no protocolo o obriga a te avisar. Então o hábito duradouro não é a auditoria única. É manter a lista pequena, fixada e em sandbox, e reler as descrições toda vez que você atualiza uma versão. Comece pela etapa um: abra o código-fonte e leia as descrições de ferramentas em voz alta. Se parecerem estar falando com seu agente em vez de com você, você já tem sua resposta.