Riscos de segurança do MCP: o servidor que você instalou

Em setembro de 2025, um pacote chamado postmark-mcp foi publicado no npm. Era uma cópia quase exata da biblioteca oficial da Postmark para envio de e-mail, e funcionava perfeitamente. Durante quinze versões, ele fez exatamente o que prometia.

Na décima sexta, ganhou uma linha a mais: uma cópia oculta de todo e-mail enviado para um domínio controlado pelo autor. Redefinição de senha, fatura, comunicado interno — tudo com cópia carbono invisível. O pacote foi baixado 1.643 vezes antes de ser removido, e entrou para a história como o primeiro servidor MCP malicioso encontrado em produção, descoberto pela Koi Security.

Nenhuma vulnerabilidade foi explorada. Ninguém invadiu nada. O servidor simplesmente fez o que ele tinha permissão de fazer.

A tese em uma frase: o MCP resolveu o problema de integração e criou um de confiança. Um servidor MCP é uma dependência de software como qualquer outra — com a diferença de que quem decide quando executá-la é o modelo, não você.

Por que a segurança do MCP não é a segurança de uma API

Uma API é chamada por um programa que já sabe o que quer. O código decide, o desenvolvedor revisou, e o comportamento é determinístico: mesma entrada, mesma chamada.

Um servidor MCP é diferente em um ponto que muda tudo. Como está explicado em o que é MCP, o servidor se apresenta ao modelo: anuncia quais ferramentas oferece, que parâmetros aceitam e o que cada uma faz. O modelo lê essa apresentação e decide, em tempo de execução, o que chamar.

Isso significa que a autorização acontece em dois momentos separados:

• Você autoriza uma vez, quando conecta o servidor e concede a credencial.
• O modelo decide muitas vezes, a cada tarefa, com base em texto que chegou depois.

Entre um momento e outro cabe todo o problema. A pergunta central da segurança do MCP deixa de ser "esse código está correto?" e passa a ser "o que pode entrar no contexto do modelo e convencê-lo a usar o que eu já autorizei?".

É um deslocamento parecido com o que a área de segurança já viveu quando o perímetro deixou de ser a rede. A resposta de então também serve aqui: parar de confiar por localização e passar a verificar por operação, que é a lógica de zero trust.

Tool poisoning: a instrução que você nunca lê

Este é o vetor mais específico da segurança do MCP, e o menos intuitivo.

A descrição de uma ferramenta é texto livre. Ela existe para o modelo entender quando usar aquela função — e vai direto para o contexto. Na maioria das interfaces, o usuário nunca vê esse texto. Você vê o nome da ferramenta na lista de conectores; o modelo vê o parágrafo inteiro.

Se esse parágrafo contiver instrução maliciosa, ela chega ao modelo com o mesmo status de qualquer outra instrução. A Invariant Labs demonstrou o primeiro caso público em abril de 2025: um servidor malicioso, presente no mesmo contexto que um servidor legítimo de mensagens, com uma descrição envenenada capaz de fazer o agente ler o histórico de conversas e enviá-lo para fora — sem nenhuma ação do usuário.

Repare no detalhe que torna isso pior que phishing tradicional: em engenharia social, o alvo é uma pessoa, que pode desconfiar. Aqui o alvo é o modelo, que foi construído para seguir instruções bem escritas.

Rug pull: aprovado numa versão, malicioso na seguinte

O caso do postmark-mcp é a versão de manual disso, e por isso ele abre o texto.

A técnica tem nome: rug pull. O servidor entrega uma versão limpa exatamente quando ela é revisada — na instalação, na avaliação, no momento em que alguém olha com atenção. Depois que a confiança está estabelecida e a base instalada cresceu, o comportamento muda.

Quinze versões idênticas à biblioteca legítima não é acidente. É construção de confiança como parte do ataque.

A implicação prática para a segurança do MCP é desconfortável: avaliar um servidor uma vez não é suficiente. O que você aprovou foi um artefato, e o artefato tem versão seguinte. É a mesma lição que a cadeia de suprimentos de software vem ensinando desde os incidentes de pacote comprometido em repositório público — e que quase ninguém em português conectou ainda ao MCP.

Um servidor MCP é dependência de terceiro. Vale para ele tudo que já vale para biblioteca: fixar versão, revisar atualização, preferir origem com código aberto e histórico público, desconfiar de pacote novo com nome parecido com o do fornecedor real.

O trio letal

A melhor formulação do problema de fundo não veio de fornecedor de segurança. Veio de Simon Willison, em junho de 2025, e é útil porque transforma um risco difuso em três itens verificáveis.

Um agente fica exposto quando reúne, ao mesmo tempo:

1. acesso a dado privado — seu e-mail, seu repositório, seu banco;
2. exposição a conteúdo não confiável — qualquer texto que ele leia e que alguém de fora possa escrever;
3. capacidade de comunicação externa — enviar e-mail, abrir chamado, fazer requisição, escrever num lugar público.

Cada um isolado é inofensivo. Os três juntos permitem que texto escrito por um atacante faça seus dados saírem.

O valor prático dessa formulação para a segurança do MCP é que ela indica a defesa. Não dá para blindar o modelo contra instrução maliciosa — filtro e instrução defensiva reduzem a taxa e não zeram, porque instrução e dado chegam pelo mesmo canal de texto. Mas dá para quebrar uma das três pernas, e isso é decisão de arquitetura, não de prompt:

• o agente que lê conteúdo externo não recebe credencial de dado privado;
• o agente que toca dado privado não tem ferramenta de envio para fora;
• ou a ação de saída passa por aprovação humana explícita, caso a caso.

O caso extremo do que acontece quando as três se juntam já está documentado em ataques agênticos.

Os números que existem hoje

Não existe muito número público sobre segurança do MCP ainda, e o ecossistema é novo — então vale citar com a fonte colada e o método à vista:

Duas ressalvas honestas sobre essa tabela.

A primeira: o levantamento da Equixly é avaliação ofensiva comercial, não estudo revisado por pares. A amostra foi de servidores populares, não aleatória. O número serve para indicar ordem de grandeza — "isso é comum" —, não como estatística populacional.

A segunda, e mais interessante: as duas CVEs críticas não estão em servidor obscuro. O mcp-remote é o proxy que clientes locais usam para falar com servidores remotos, com mais de 437 mil downloads; bastava conectar a um servidor malicioso para o servidor devolver uma URL de autorização forjada e executar comando na máquina. O MCP Inspector é a ferramenta de depuração oficial do próprio protocolo, e a falha permitia execução de código só por visitar uma página com o Inspector aberto.

Não cito isso para desqualificar o MCP. Cito porque é o padrão de todo protocolo em adoção acelerada: a especificação amadurece antes das implementações. O jeito de ler a tabela é "a superfície nova ainda está sendo varrida", e o comportamento correto diante disso é o de sempre — gestão de vulnerabilidades com inventário e atualização, não abstinência.

O que a especificação já resolveu — e o que ela não resolve

Vale dar o crédito devido: a revisão de 18 de junho de 2025 do protocolo endureceu bastante a parte de autorização, e ganhou uma página própria de boas práticas — a especificação assumiu a segurança do MCP como assunto dela. Três mudanças importam:

• Indicadores de recurso (RFC 8707) — o cliente passa a dizer para qual servidor aquele token vale. Token emitido para um servidor deixa de ser aceito por outro.
• Proibição de repasse de token — um servidor não pode aceitar nem encaminhar token que não foi emitido para ele.
• Tratamento explícito do confused deputy — o cenário clássico de obter credencial para um recurso de baixo privilégio e apresentá-la a um de alto privilégio.

Isso é auth resolvido no papel, e é muito. Mas repare no que não está nessa lista: nada disso impede prompt injection, nada disso impede tool poisoning e nada disso impede rug pull.

E não é omissão da especificação. É que esses três não são problemas de protocolo. São consequência de dar a um sistema que interpreta linguagem o direito de acionar ferramentas — e a única camada onde eles se tratam é a de permissão e de arquitetura.

O checklist que eu usaria antes de ligar qualquer servidor

Curto de propósito, porque lista longa não é seguida:

1. Origem. Quem publica é a conta oficial do fornecedor? O código é aberto e tem histórico público? Nome parecido com o do fornecedor real é sinal de alerta, não de conveniência.
2. Permissão mínima. O servidor pede escrita para uma função que só lê? Credencial separada, escopo mínimo, nunca a chave de administrador que já estava à mão.
3. Versão fixada. Fixe e revise atualização. Quinze versões limpas não garantem a décima sexta.
4. O trio letal. Nesse contexto, coexistem dado privado, conteúdo não confiável e capacidade de enviar para fora? Se sim, quebre uma das pernas antes de subir.
5. Registro. Toda chamada de ferramenta gravada, com quem pediu e o que voltou. Sem isso não existe investigação depois — e o plano de resposta a incidentes vira adivinhação.
6. Dado pessoal. Se o servidor alcança dado de cliente, isso é tratamento de dado com operador novo na cadeia — vale a régua de LGPD para PMEs.

Nenhum item é sofisticado, e é isso que torna a segurança do MCP tratável hoje: são seis perguntas de dependência de software, deslocadas para um lugar onde ainda quase ninguém as faz.

O ponto que fica

O incidente do postmark-mcp não teve exploração de falha, não teve invasão e não teve alerta disparado. Teve um pacote com permissão de enviar e-mail fazendo exatamente isso, mais uma cópia.

É por aí que a segurança do MCP vai continuar sendo testada: não por vulnerabilidade espetacular, mas por permissão concedida uma vez e nunca revisada. O protocolo entregou uma porta padronizada para dentro dos seus sistemas — e padronizar a porta não diz nada sobre quem tem a chave.

A pergunta que vale levar daqui não é "o MCP é seguro?". É "o que esse servidor pode fazer se o modelo receber a instrução errada — e eu ficaria sabendo?". Enquanto a segunda metade da pergunta não tiver resposta, a primeira não importa muito.