MCP é seguro? Segurança e governança e m servidores MCP

A pergunta mais útil não é se o MCP é seguro, e sim o que é seguro nele. O protocolo em si é bem projetado. O risco está no ecossistema de servidores em volta dele, que ainda é imaturo. Este texto é voltado a quem precisa decidir sobre adoção: os riscos reais, o que a especificação garante e o que não garante, e como governar o uso de MCP em uma empresa.

Ele vai mais fundo do que o básico de segurança que aparece no explicador o que é um servidor MCP, e deixa a parte de privacidade e dados pessoais para o artigo MCP e LGPD. Aqui, o foco é risco e governança.

O MCP é seguro? Protocolo versus ecossistema

Quem pergunta se o MCP é seguro está, em boa medida, fazendo a pergunta errada. Vale separar duas coisas que costumam ser confundidas.

O protocolo é sólido. A arquitetura é bem pensada, a especificação de autorização é adequada e a camada de transporte é limpa. Se o problema fosse só o desenho do protocolo, haveria pouco a discutir.

O ecossistema é que preocupa. Há milhares de servidores MCP disponíveis, de qualidade desigual, a maioria sem qualquer varredura de segurança. Uma comparação recorrente na pesquisa de 2026, feita pela NimbleBrain, é que a segurança de MCP hoje está onde a segurança web estava por volta de 2005: funcional, porém imatura. A TrueFoundry resume de outro jeito: o MCP resolveu o problema de integração, mas não resolveu o problema de governança.

A conclusão prática é direta. O MCP pode fazer parte de uma arquitetura segura, mas não é seguro por padrão. A segurança depende da implementação do servidor e do host, e da governança que você coloca em volta.

Por que a superfície de ataque do MCP é diferente

Há uma razão de fundo para o MCP exigir controles próprios, e o decisor precisa entendê-la. No momento em que um modelo passa a escolher e chamar ferramentas, ele deixa de ser uma caixa de perguntas e respostas e vira software que age. E software que age tem uma fronteira de confiança que agora inclui descrições de ferramentas, schemas, saídas e credenciais.

Diferente de uma API estática, com requisições previsíveis, o MCP envolve decisão autônoma do agente, contexto que muda e cadeias de ferramentas encadeadas. Isso tem uma consequência técnica importante: uma tarefa que dispara vinte chamadas de ferramenta parece, na rede, vinte requisições HTTP autenticadas. Um gateway de API tradicional, que inspeciona HTTP, não consegue ver se uma instrução maliciosa foi injetada no meio do caminho. A segurança de MCP não cabe, portanto, nas ferramentas de segurança que já existem para APIs. Ela precisa de controles que entendam a semântica de ferramenta.

Os principais riscos

Os riscos do MCP não são hipotéticos. Houve incidentes concretos em 2026, e vale conhecê-los. Os nomes e as datas abaixo estão atribuídos às fontes que os documentaram, levantamento feito em 20 de julho de 2026.

• Injeção de prompt indireta: instruções maliciosas escondidas em conteúdo que o modelo lê, como o resultado de uma ferramenta. O pesquisador Simon Willison descreveu a combinação perigosa que ele chama de trinca letal: dado privado, conteúdo não confiável e capacidade de comunicação externa, juntos, habilitam a exfiltração de dados. Em um incidente com o Supabase e o Cursor, em junho de 2025, um agente com privilégio que processava tickets de suporte foi induzido, por injeção de prompt, a vazar tokens de integração.
• Envenenamento de ferramentas: instruções maliciosas escondidas na descrição de uma ferramenta, texto que o modelo lê por inteiro mas que a interface esconde do usuário. A Invariant Labs demonstrou um servidor MCP malicioso capaz de exfiltrar um histórico inteiro de mensagens por essa via.
• Troca após aprovação, o rug pull: o servidor mostra uma ferramenta limpa, espera a aprovação e troca a definição depois. Como o servidor pode mudar a definição sem avisar, a aprovação inicial deixa de valer. A Microsoft recomenda fixar as definições de ferramenta e alertar sobre qualquer desvio, como gatilho de rug pull.
• Cadeia de suprimentos: servidores maliciosos, nomes quase idênticos aos legítimos (typosquatting), dependências comprometidas e troca de dono por trás da mesma URL. Um caso concreto: segundo a Snyk, em setembro de 2025, uma versão maliciosa do pacote postmark-mcp no npm passou a copiar de forma oculta todos os e-mails processados para um domínio externo, no que foi apontado como o primeiro incidente rastreado de servidor MCP malicioso na cadeia de suprimentos. Outro: o pacote mcp-remote, com centenas de milhares de downloads, teve uma falha de execução remota de código catalogada como CVE-2025-6514, por passar parâmetros de conexão ao shell sem sanitização.
• Servidores expostos sem autenticação: o equivalente ao shadow IT no mundo dos agentes. Alguém sobe um servidor para destravar um teste e ninguém registra. A Trend Micro encontrou centenas de servidores MCP expostos na internet sem autenticação, e no início de 2026 apareceram instâncias de um agente popular expostas, parte com endpoints MCP sem autenticação vazando chaves e credenciais.
• Excesso de permissão e raio de impacto: um servidor costuma guardar credenciais de vários sistemas e pedir um escopo maior do que precisa. Um servidor comprometido, ou um token vazado, vira uma brecha em tudo que ele toca.
• Falhas de implementação do servidor: injeção de comando, path traversal e SSRF quando a entrada não é validada. Um levantamento da Endor Labs sobre milhares de implementações apontou parcelas altas com operações de arquivo sujeitas a path traversal e a injeção de comando.

A tabela resume os vetores e o controle principal de cada um:

Vale a ressalva de método: segurança aqui é defesa em profundidade. Nenhum controle isolado elimina um vetor. O que reduz o risco é a combinação de camadas.

O que a especificação faz e o que ela não faz

A especificação define requisitos de segurança, mas não os impõe no nível do protocolo. Ela delega a aplicação a quem implementa.

O que a especificação traz: exige o consentimento explícito do usuário antes de invocar uma ferramenta e afirma que deve haver um humano no circuito com poder de negar. Em transporte HTTP, define OAuth 2.1 com PKCE, indicadores de recurso e metadados de identidade do cliente. A atualização de 2026 acrescentou o consentimento de escopo incremental, que pede só o acesso mínimo por operação, em vez de tudo de uma vez.

O que ela não garante: que os servidores sigam essas recomendações. Levantamentos de 2026 mostram que apenas uma pequena parcela dos servidores usa OAuth, e que a maioria depende de chave estática ou de nenhuma autenticação. Ou seja, a especificação oferece as ferramentas certas, mas o ecossistema ainda não as adotou de forma ampla.

Uma revisão prevista do protocolo deve elevar a linha de base de segurança, ao fazer cada requisição carregar o que precisa, o que permite a um ponto de controle inspecionar e aplicar política a cada chamada. É um avanço a acompanhar, mas não muda a realidade de hoje: a segurança depende de quem implementa e de quem governa.

Governança para ambiente corporativo

Esta é a parte que fala direto ao decisor. O consenso de 2026 é que os controles de segurança de MCP precisam viver na camada de infraestrutura, e não ser improvisados sobre o que já existe. Um programa de governança minimamente sério cobre os seguintes controles:

• Identidade em cada chamada: toda requisição do agente atrelada a uma identidade verificada, de preferência com um fluxo em que o agente age com as permissões exatas do usuário, herdadas do provedor de identidade da empresa.
• Controle de acesso por ferramenta: o agente invoca apenas as operações que o seu papel autoriza, e não tudo o que o servidor expõe.
• Cofre de credenciais: o modelo nunca vê a chave crua. As credenciais ficam em um cofre, e o acesso é mediado.
• Aprovação humana para ações destrutivas ou irreversíveis: exclusões, transferências externas, transações financeiras, modificações em massa e comunicações de saída. A prática recomendada é classificar cada ferramenta por risco e exigir aprovação nas de alto risco.
• Auditoria estruturada, mantida no seu ambiente: registrar quem chamou qual ferramenta, com quais parâmetros e em qual sessão.
• Inventário mais gateway: um registro dos servidores conhecidos, como linha de base, e um gateway em tempo de execução por onde tudo passa, revalidando identidade e política a cada chamada. A lógica é simples: não se governa, corrige ou revoga o que não se vê.
• Isolamento: rodar o servidor em sandbox, com controle da saída de rede, e verificar que o sandbox de fato contém.
• Vetar antes de rodar: auditar todo servidor antes do deploy. Se não dá para ler o código, não rode. Levantamentos de 2026 apontam que parcela relevante dos servidores do registro oficial sequer tem o código disponível.

Frameworks e padrões emergentes

Há um sinal de amadurecimento que ajuda o decisor a saber que não está sozinho. Surgiram, em 2025 e 2026, referências dedicadas à segurança de agentes e de MCP: o MCP Security Framework da Coalition for Secure AI, com modelo de ameaças e controles; o OWASP Top 10 para Aplicações Agênticas de 2026, que cobre sequestro de objetivo do agente, mau uso de ferramenta, abuso de identidade e privilégio, e a cadeia de suprimentos agêntica; frameworks comunitários como o SAFE-MCP; e sistemas de pontuação de confiança de servidores.

A mensagem para quem decide é a de que os mecanismos existem. O gargalo não é a falta de referências, é a adoção. Uma organização que leve a governança a sério tem, hoje, de onde tirar modelo de ameaças e controles.

A postura de um servidor de domínio confiável

Se o maior risco do ecossistema é ligar um agente a servidores de terceiros não verificados, vindos de registros públicos, a contramedida mais direta é preferir servidores de domínio, de origem conhecida e escopo restrito. É aqui que um servidor especializado se diferencia, e vale usar o da Partnr como exemplo honesto dessa postura.

Um servidor de dados financeiros bem desenhado reduz vários dos vetores que assustam o comprador institucional, pela própria natureza:

• Origem conhecida e fonte oficial: dados de mercado, fundamentalistas e macroeconômicos, com procedência clara, em vez de um servidor anônimo baixado de um registro público.
• Autenticado: o acesso é por token, não um endpoint aberto na internet.
• Permissão mínima por natureza: é um servidor de leitura de dados, sem ações destrutivas. Isso remove, de saída, toda a classe de risco ligada a operações irreversíveis, simplesmente porque essas operações não existem ali para serem exploradas.
• Rastreabilidade: cada dado tem uma fonte identificável.

Nada disso substitui um programa de governança completo, mas ilustra o princípio central deste artigo: um servidor vetado, autenticado e de leitura tem uma superfície de ataque muito menor do que a de plugar qualquer servidor de terceiro no seu ambiente. A escolha do servidor é, ela mesma, uma decisão de segurança.

Conclusão

A pergunta certa sobre segurança em MCP não é sim ou não, é onde está o risco. O protocolo é sólido. O ecossistema de servidores é imaturo, e é ali que os incidentes acontecem. Isso muda o que o decisor precisa fazer: em vez de confiar que o MCP é seguro por padrão, tratar cada servidor como um componente a ser vetado e cada uso como algo a ser governado na camada de infraestrutura.

O caminho prático é conhecido: visibilidade primeiro, com inventário e gateway, depois identidade por chamada, permissão mínima, cofre de credenciais, aprovação humana para o que é destrutivo, e auditoria no seu próprio ambiente. E, na escolha de servidores, dar preferência aos de origem conhecida, autenticados e de leitura, que carregam uma superfície de ataque menor. Segurança de MCP, hoje, é menos sobre o protocolo e mais sobre a disciplina com que você o coloca em produção.