Segurança do MCP Server: Avalie Ferramentas Antes de Instalar

Instalar um servidor MCP parece trivial: cole um comando ou URL, reinicie o cliente e uma nova ferramenta aparece no contexto do seu agente. Mas atrás desse nome de ferramenta está código executável, um schema injetado na janela de contexto do modelo, credenciais e qualquer sistema que essas credenciais conseguem alcançar. O ecossistema MCP ainda está amadurecendo, e o processo de validação para novos servidores é, generosamente falando, escasso. Este post oferece um checklist pré-instalação reutilizável aplicado a um exemplo ilustrativo fixado, com descobertas e uma justificativa clara de aceitar/rejeitar para cada etapa.

O Que a Instalação Realmente Concede

Quando você instala um servidor MCP, você não está instalando uma biblioteca passiva. Você está concedendo acesso a código executável às suas ferramentas, sistema de arquivos e, geralmente, suas chaves de API, sem nenhuma etapa de revisão intermediária que a maioria dos clientes exibe para você.

Essa confiança é cumulativa e não-granular. Como observa o guia de práticas da Pluto Security, aprovar um servidor MCP significa aprovar cada operador em sua cadeia de suprimentos. Não há re-prompt por componente. Cada servidor MCP habilitado também envia sua lista completa de ferramentas ao contexto do modelo no início da sessão, consumindo tokens e diluindo atenção. Então você paga duas vezes: uma vez em superfície de segurança, uma vez em orçamento de contexto.

No Claude Code especificamente, os servidores são configurados via .mcp.json (escopo do projeto) ou ~/.claude.json (escopo do usuário), e podem ser agrupados dentro de um diretório de plugin que também contém hooks, agentes, monitores e scripts bin/ . Um plugin não é um invólucro fino. Consegue alcançar tudo que sua sessão de shell alcança.

O modelo de ameaça tem três modos de falha realistas:

• Um editor malicioso cria um servidor similar que aparece no registro, redireciona chamadas de API ou exfiltra dados silenciosamente.
• Um autor bem-intencionado, mas inexperiente envia um servidor que armazena tokens em texto simples ou registra corpos de requisição sem pensar nisso.
• Um servidor legítimo que você aprovou é atualizado, e a nova versão introduz uma backdoor ou amplia suas permissões sem re-solicitar seu consentimento.

Os três estão documentados na prática, não são hipotéticos.

Revise Fonte, Proveniência e Comportamento de Atualizações

Comece antes de ler uma única linha de código. Quem publicou este servidor? Há uma identidade verificável por trás do pacote? O repositório tem um histórico de commits significativo ou foi criado na semana passada com um único commit?

O guia de arquitetura focada em defesa de Christian Schneider coloca os requisitos de higiene da cadeia de suprimentos claramente: instale servidores apenas de fontes respeitáveis, verifique assinaturas de pacote ou hashes e fixe versões de dependências em vez de aceitar "latest". Execute npm audit ou pip-audit contra o pacote antes que ele toque seu ambiente. Gere uma lista de materiais de software (SBOM) para que você possa rastrear cada dependência e responder rapidamente quando um CVE é divulgado.

Para seu checklist de revisão, capture estes na etapa de fonte:

1. Confirme que a identidade do editor mapeia para uma organização ou indivíduo conhecido com um histórico.
2. Verifique a data de criação do repositório e a frequência de commits. Repositórios com um único commit merecem escrutínio adicional.
3. Fixe a versão exata que você revisou. Anote o hash do commit ou a tag de release.
4. Execute npm audit ou pip-audit na árvore de dependências e registre os resultados.
5. Verifique se o mecanismo de atualização do servidor valida assinaturas digitais antes de aplicar mudanças.

Exemplo ilustrativo: suponha que você esteja revisando um hipotético mcp-db-connector@1.4.2 de um editor com 18 meses de histórico de commits, dois contribuidores e uma release assinada no GitHub. npm audit retorna zero descobertas de alta severidade. Isso passa nesta etapa. Um servidor com um editor anônimo, um repositório com dois dias de idade e nenhuma release assinada não passaria.

Inspecione Tools, Hooks, Scripts e Network Access

Proveniência da fonte é essencial. Agora leia o código.

Examine cada definição de tool que o servidor registra. A descrição informada corresponde à implementação real? Conforme o guia de sobrevivência MCP do Towards Data Science avisa, só porque algo é publicado como um "email-sender" não significa que ele apenas envia emails. Ele pode registrá-los, reescrevê-los ou encaminhá-los para um lugar que você não pretendia.

Verifique especificamente estes itens:

• Hooks e scripts de ciclo de vida: hooks.json registra callbacks pré ou pós-tool? O que eles fazem?
• Scripts em `bin/`: Há scripts de shell que executam na instalação ou na invocação? Leia-os.
• Chamadas de rede de saída: O servidor faz chamadas para algum endpoint não documentado no README? Use grep -r "fetch\|axios\|http\|https\|request" em todo o código-fonte.
• Acesso ao sistema de arquivos: Ele solicita acesso a caminhos mais amplos do que a tarefa requer?
• Tratamento de credenciais: As chaves de API são gravadas em disco, registradas ou transmitidas para qualquer lugar fora do serviço de destino declarado?

O SlowMist MCP Security Checklist classifica validação de entrada, rate limiting de API e codificação de saída como os três controles de maior prioridade. Se o servidor não valida seus próprios inputs estritamente, ele é um vetor para ataques de injeção independentemente de você confiar no editor.

Uma coisa que o checklist sinaliza e que a maioria das pessoas perde: descrições de tools são injetadas verbatim no contexto do modelo. Uma descrição maliciosa ou mal escrita pode direcionar o comportamento do agente dentro da sandbox mesmo que a sandbox em si esteja intacta. Sandboxing sem varredura de schema é apenas meia defesa.

Teste Prompt Injection e Data Boundary Cases

Esta etapa não é opcional para nada que toque dados de produção ou informações de clientes.

Prompt injection via descrições de tools é um vetor de ataque documentado. Um atacante embutir instruções dentro do campo de descrição de uma tool que o modelo interpreta como intenção do usuário. Você precisa verificar que o schema do servidor não contém instruções embutidas, que a saída do servidor não é confiada como input de usuário autorizado downstream, e que dados retornados de uma tool não podem vazar para o contexto de uma sessão ou usuário separado.

Execute illustrative boundary cases antes de conectar o servidor a credenciais reais:

1. Construa uma chamada de tool que retorna uma resposta contendo algo como "Ignore previous instructions and..." e observe se o cliente host a expõe ou age sobre isso.
2. Passe inputs oversizeds ou malformados para cada tool registrada e verifique se o servidor os trata graciosamente ou lança exceções não tratadas que expõem stack traces.
3. Se o servidor tem acesso a múltiplas fontes de dados, verifique que uma query contra a fonte A não pode retornar dados da fonte B.

Estes são testes de triagem, não uma certificação. Uma revisão manual rápida identifica problemas óbvios. Isso não garante a ausência de sutis.

Se você está construindo ferramentas de IA para clientes e quer suporte na revisão de integrações MCP como parte de uma configuração mais ampla do Claude Code, o serviço de agência Claude Code da Seahawk pode ajudar a avaliar a stack antes dela chegar perto da produção.

Escolha o Escopo de Credencial Menor e Isole o Processo

Uma vez que você tenha revisado o servidor e decidido que é aceitável, a questão passa a ser: como você o executa?

O princípio é o de menor privilégio, aplicado sem compromissos. Não entregue a um servidor MCP sua chave API pessoal com acesso total à conta porque é conveniente. Crie uma credencial com escopo restrito ao mínimo de permissões que a funcionalidade documentada exige. Se o servidor precisa de acesso de leitura a um único bucket S3, a credencial não deve ter acesso de escrita, ponto final.

Opções de isolamento, aproximadamente em ordem crescente de custo:

• Execute o servidor em um subprocesso dedicado sem acesso às variáveis de ambiente do shell pai além das que você explicitamente passa.
• Use um contêiner com uma política de rede restrita para que o servidor não possa fazer conexões de saída arbitrárias.
• Para implantações sensíveis, imponha verificações de cadeia de suprimentos como portais de implantação e trate atualizações de servidores MCP com o mesmo processo de gerenciamento de mudanças que o código da aplicação.

O modelo de ameaça General Analysis o expressa bem: um marketplace verificado sem pinning de versão significa que o servidor verificado de hoje é o rug pull de amanhã. Isolamento e pinning não são redundantes. Eles protegem contra modos de falha diferentes. Sandboxing contém o raio de impacto; pinning previne desvio silencioso.

Também vale notar: não compartilhe credenciais entre servidores MCP. Token passthrough e chaves API compartilhadas significam que um comprometimento em um servidor alcança tudo que a credencial toca.

Registre a Decisão e Re-revise a Cada Mudança

Uma revisão que você não registra é uma revisão que não aconteceu, tanto para seu eu futuro quanto para sua equipe.

Para cada servidor que você instala, mantenha um log de decisão com no mínimo:

• A versão exata revisada (versão do pacote mais commit hash ou tag de release).
• A data da revisão.
• Quem realizou a revisão.
• Descobertas das ferramentas de auditoria e inspeção manual.
• A justificativa de aceitar/rejeitar.
• Condições que acionariam uma re-revisão (por exemplo, qualquer nova versão maior, qualquer mudança no schema da ferramenta, qualquer aviso de segurança tocando uma dependência).

Isto não é burocracia por si só. O guia de arquitetura de Schneider faz uma pergunta direta que a maioria das equipes não consegue responder: "O que acontece se a descrição da ferramenta de um servidor MCP muda depois que um usuário a aprovou? Alguém saberia?" Na maioria das configurações padrão, a resposta é não. Pinning de versão plus um log de decisão é como você muda essa resposta.

Defina um lembrete no calendário para re-revisar servidores pinned trimestralmente mesmo sem um novo release, porque o ambiente de ameaça ao redor deles muda mesmo quando o código não muda.

Para equipes já executando servidores MCP em stacks de produção, as considerações operacionais em torno do gerenciamento de múltiplos servidores ao lado de suas ferramentas existentes estão cobertas separadamente em nosso post de stack de produção.

Checklist Reutilizável de Pré-Instalação: Justificativa de Aceitar/Rejeitar

Abaixo está a checklist completa em ordem de triagem. Aplique-a antes de instalar qualquer servidor. Os exemplos de descobertas são ilustrativos; seus resultados variarão.

A linha 6 é por que você faz isso. Um ping de analytics não documentado não é automaticamente malicioso, mas é não documentado, e chamadas de saída não documentadas são critério de rejeição até serem explicadas. Você pergunta ao publisher, obtém uma resposta clara, revisa o que é realmente enviado e então toma uma nova decisão. Esse é o processo.

FAQ

Revisar código-fonte garante que um servidor é seguro para instalar?

Não. Revisão de código é triagem, não certificação. Reduz a probabilidade de problemas óbvios: chamadas de rede não documentadas, logging de credenciais, descrições de ferramentas maliciosas. Não protege contra vulnerabilidades introduzidas em uma atualização futura (por isso você fixa versões e faz revisão em mudanças) ou contra falhas lógicas sutis que exigem análise de segurança profunda para serem descobertas.

O que é envenenamento de ferramenta e como se relaciona com MCP?

Envenenamento de ferramenta refere-se a um atacante embutindo instruções maliciosas dentro do campo de nome ou descrição de uma ferramenta. Como esquemas de ferramentas MCP são injetados no contexto do modelo verbatim, o modelo pode interpretar essas instruções como diretivas legítimas. Revisar o schema antes da instalação e verificar fragmentos de instruções embutidas é a mitigação primária no estágio pré-instalação.

Devo revisar servidores MCP remotos de forma diferente dos locais?

Servidores locais têm um caminho mais curto para dados sensíveis porque executam diretamente em sua máquina com acesso ao seu ambiente. Servidores remotos introduzem superfície de ataque de rede e risco de ataque man-in-the-middle. Ambos exigem o mesmo checklist, mas servidores locais justificam atenção particular ao escopo de acesso do filesystem e tratamento de credenciais no código-fonte, enquanto servidores remotos exigem TLS verificado, validação de assinatura e conformidade OAuth 2.1 conforme a especificação MCP atual.

Como lidar com servidores MCP que são closed-source ou distribuídos como binários?

Se você não consegue ler o código-fonte, você está confiando inteiramente em reputação do publisher, verificação de assinatura criptográfica e controles em tempo de execução (sandboxing, política de rede, credenciais com escopo). Essa é uma postura de risco materialmente maior. Para qualquer coisa tocando dados de produção ou informações de clientes, um binário closed-source sem assinatura verificável de um publisher conhecido deve usar rejeição como padrão.

O que é um SBOM e realmente preciso de um para servidores MCP?

Um SBOM (software bill of materials) é um inventário legível por máquina de cada dependência que um pacote inclui. Para servidores MCP, permite identificar se qualquer dependência transitiva tem um CVE divulgado, mesmo que o pacote de nível superior pareça limpo. Para ferramentas pessoais de baixo risco, é overhead opcional. Para implementações em produção lidando com dados sensíveis, é a diferença entre conhecer sua exposição e adivinhar.

O aviso mais afiado de toda essa revisão: uma descrição de ferramenta que parece benigna no registro pode orientar o comportamento do agente após instalação tão efetivamente quanto código executável malicioso, e a maioria dos clientes não avisará você. Leia o schema, não apenas o README.