Segurança MCP: riscos do Model Context Protocol e checklist

O que é segurança do MCP

Segurança do MCP é o conjunto de controles que protege a conexão entre agentes de IA e as ferramentas que eles usam pelo Model Context Protocol: autenticação dos servidores, permissões mínimas por ferramenta, verificação da origem de cada servidor, isolamento da execução e trilha de cada chamada. Sem esses controles, cada servidor MCP vira um atalho para dados e sistemas internos.

O MCP é um padrão aberto, lançado pela Anthropic em novembro de 2024, que define como um agente descobre e chama ferramentas externas: consultar o SIEM, abrir um ticket, ler um repositório, mandar um e-mail. Em um ano virou a forma padrão de ligar agentes ao resto da empresa. Quando a Anthropic doou o protocolo à Agentic AI Foundation, sob a Linux Foundation, em dezembro de 2025, já havia mais de 10 mil servidores MCP públicos ativos e mais de 97 milhões de downloads mensais dos SDKs em Python e TypeScript.

A adoção correu na frente da segurança. Este guia reúne os riscos documentados, os incidentes que já aconteceram, um checklist de hardening e um ponto que costuma ficar de fora: servidores MCP são ativos, e precisam entrar no inventário e no programa de gestão de exposição como qualquer outro serviço.

Leia também: OWASP Top 10 para IA agêntica: os 10 riscos ASI explicados

Resumo em 5 pontos

1. O MCP é um protocolo, não um produto de segurança. A especificação define autorização e boas práticas, mas a proteção depende de como cada servidor e cada cliente são implementados e configurados.
2. O ataque mais característico é o tool poisoning: instruções escondidas na descrição de uma ferramenta, lidas pelo agente e invisíveis para o usuário.
3. Servidores expostos sem autenticação são reais e numerosos: pesquisas de 2025 encontraram centenas a quase dois mil na internet.
4. A cadeia de suprimentos já foi atacada: o primeiro servidor MCP malicioso em uso real copiava e-mails em segredo.
5. Servidor MCP é ativo: precisa de dono, inventário, controle de exposição e correção de vulnerabilidades, como qualquer serviço.

Como o MCP funciona e onde estão as fronteiras de confiança

O MCP tem três peças. O host é a aplicação onde o agente roda, como um assistente de código ou uma plataforma de segurança. O cliente MCP vive dentro do host e mantém a conexão. O servidor MCP expõe capacidades: ferramentas (funções que o agente chama), recursos (dados que ele lê) e prompts (modelos de instrução). A conexão pode ser local, com o servidor rodando como processo na mesma máquina via entrada e saída padrão (stdio), ou remota, por HTTP.

Isso cria quatro fronteiras de confiança que um atacante pode explorar:

• Descrição da ferramenta: o texto que explica ao modelo o que a ferramenta faz entra direto no contexto do agente.
• Resultado da ferramenta: o que a ferramenta devolve também vira contexto, e pode conter instruções.
• Credenciais: o servidor costuma guardar tokens de APIs de terceiros com privilégio amplo.
• Execução local: um servidor stdio é um processo com os mesmos direitos do usuário que o iniciou.

Incidentes e números que já marcaram a segurança do MCP

Em 2026 o volume aumentou. A Cloud Security Alliance analisou em abril a pesquisa da OX Security sobre o comportamento do transporte stdio nos SDKs oficiais, que executa o comando configurado mesmo quando ele não inicia um servidor MCP válido. A pesquisa resultou em mais de 30 divulgações responsáveis e mais de 10 CVEs críticas ou altas em produtos que usam o protocolo, e a Anthropic tratou o comportamento como esperado. A consequência prática é a mesma de todos os casos acima: a configuração de um servidor MCP precisa ser tratada como código executável.

Os principais riscos do Model Context Protocol

Leia também: Governança de agentes de IA: human-in-the-loop na prática

Tool poisoning: instruções escondidas na ferramenta

A descrição da ferramenta pode conter instruções que o usuário não vê na interface, mas o modelo lê inteira. Foi o que a Invariant Labs demonstrou em abril de 2025: uma ferramenta de "soma" mandava o agente ler arquivos sensíveis e enviá-los num parâmetro da própria chamada. A variante por resultado é parecida: o retorno da ferramenta traz a instrução. É a prompt injection indireta aplicada ao MCP, e corresponde ao ASI01 e ao ASI04 do OWASP Top 10 para IA agêntica.

Rug pull: a ferramenta muda depois de aprovada

O servidor é aprovado com uma descrição inofensiva e, numa atualização posterior, troca a descrição ou o comportamento. Se o cliente não detecta a mudança e não pede nova aprovação, a confiança dada na primeira versão vale para a versão maliciosa.

Sombreamento de ferramentas entre servidores

Com vários servidores conectados ao mesmo agente, um servidor malicioso pode descrever uma ferramenta que altera o uso de outra, legítima, ou registrar uma ferramenta com nome parecido. O agente mistura o contexto de todos os servidores, então um único servidor ruim contamina os demais.

Confused deputy e repasse de token

O servidor MCP age com a credencial dele, não com a do usuário que pediu. Se essa credencial é ampla, um usuário com pouco acesso consegue, por meio do agente, fazer o que não poderia fazer diretamente. A especificação descreve o ataque de "delegado confuso" em servidores que fazem proxy para APIs de terceiros e proíbe explicitamente o repasse de token (token passthrough): o servidor deve aceitar apenas tokens emitidos para ele.

Servidores expostos sem autenticação

Um servidor criado para uso local, publicado numa interface de rede pública, responde a qualquer um. Os levantamentos de Knostic e Trend Micro mostram que esse é o erro mais frequente. A especificação recomenda autorização baseada em OAuth 2.1 para servidores remotos, mas não a torna obrigatória para todo cenário.

Execução de comandos e falhas clássicas

Muitos servidores montam comandos de sistema, caminhos de arquivo e URLs a partir dos parâmetros que o modelo envia. Sem validação, isso vira injeção de comando, leitura arbitrária de arquivo e SSRF, as mesmas classes de falha que a Equixly encontrou na maioria dos servidores testados.

Segredos no lugar errado

Tokens embutidos em arquivos de configuração, variáveis de ambiente ou logs de prompt são o primeiro item do OWASP MCP Top 10 (MCP01, gestão inadequada de tokens e exposição de segredos). Como agentes mantêm contexto e memória, um segredo que entra na conversa pode reaparecer depois.

Checklist de hardening para servidores MCP

Leia também: Como avaliar agentes de IA de segurança

O checklist abaixo combina as boas práticas da especificação do MCP, o guia do OWASP para desenvolvimento seguro de servidores MCP e as lições dos incidentes.

Inventário e origem

1. Mantenha um registro de todos os servidores MCP em uso: quem instalou, em que máquina ou serviço, qual versão, quais ferramentas expõe e quem é o dono.
2. Só use servidores de origem verificada, de preferência do próprio fabricante da ferramenta, com versão fixada e integridade conferida.
3. Aprove servidores novos por um fluxo formal, com um responsável que não seja quem pediu a instalação.

Autenticação e exposição

4. Nenhum servidor remoto sem autenticação. Use OAuth 2.1 conforme a especificação, com tokens vinculados ao servidor de destino.
5. Não exponha servidores locais na rede. Vincule à interface local e coloque proxy autenticado quando o acesso remoto for necessário.
6. Proíba o repasse de token: o servidor aceita só tokens emitidos para ele e usa credenciais próprias para APIs de terceiros.

Privilégio e ferramentas

7. Habilite só as ferramentas necessárias de cada servidor, não o servidor inteiro.
8. Use credenciais de escopo mínimo e curta duração, guardadas em cofre, nunca em arquivo de configuração.
9. Exija aprovação humana para ferramentas que mudam estado: escrever, apagar, enviar, bloquear, executar.

Execução e conteúdo

10. Rode servidores locais em sandbox ou contêiner, sem acesso ao diretório pessoal do usuário nem a chaves SSH.
11. Valide todo parâmetro vindo do modelo antes de montar comando, caminho ou URL.
12. Detecte mudança de descrição de ferramenta e peça nova aprovação quando ela ocorrer.

Monitoramento e resposta

13. Registre cada chamada de ferramenta com usuário, agente, parâmetros e resultado, mascarando segredos.
14. Inclua servidores MCP na gestão de vulnerabilidades e no plano de resposta: saiba como revogar credenciais e desligar um servidor em minutos.

Servidores MCP como ativos no programa de CTEM

Leia também: Shadow IT: como descobrir ativos invisíveis

Muitos servidores MCP nascem como shadow IT: um desenvolvedor instala um conector para o assistente de código, um analista liga o agente ao sistema de tickets, alguém sobe um servidor de teste numa máquina em nuvem. Os 74% de servidores expostos hospedados em grandes provedores de nuvem, segundo a Trend Micro, mostram que o problema não é só de estações de trabalho.

O ciclo de CTEM (Continuous Threat Exposure Management) acomoda esses ativos sem criar um processo paralelo:

• Escopo: incluir agentes de IA e seus conectores como classe de ativo do programa.
• Descoberta: inventariar servidores MCP em estações, servidores e nuvem, e verificar quais respondem a partir da internet.
• Priorização: pesar o que cada servidor alcança. Um servidor com credencial de administrador de nuvem vale mais atenção que um de leitura de documentação.
• Validação: testar se autenticação, escopo de ferramentas e sandbox funcionam como declarado.
• Mobilização: corrigir versões vulneráveis, revogar credenciais amplas e retirar servidores sem dono.

As ferramentas de descoberta e gestão de exposição já tratam serviços desconhecidos, portas expostas e software vulnerável. O que muda é reconhecer que um servidor MCP concentra credenciais e capacidade de ação, e por isso merece prioridade maior do que um serviço comum com o mesmo nível de exposição. O guia de agentes de IA para cibersegurança mostra onde esse tema se encaixa no mapa geral, e o artigo sobre risco da cadeia de suprimentos aprofunda a parte de dependências de terceiros.

Como o EcoTrust OS usa MCP com governança

O EcoTrust OS, runtime onde rodam os agentes do Agentic CTEM e do EcoTrust Agentic SOC, usa MCP em duas direções, conforme a especificação técnica pública do produto.

• MCP interno: expõe dados e capacidades da própria plataforma como ferramentas do agente, como inventário de frota e ativos por ambiente.
• MCP externo: conecta ferramentas que o cliente já tem, como SIEM, EDR, XDR e ITSM, sem desenvolver conector.

Os controles aplicados aos servidores externos seguem a lógica do checklist acima. O usuário conecta o servidor, um gestor aprova, e só então as ferramentas ficam disponíveis ao agente. A montagem é feita por ferramenta, e não pelo servidor inteiro, com posse por usuário e credenciais cifradas cuja decriptação fica restrita ao proprietário. As ações de conexão MCP ficam registradas na auditoria, destinos de conexões externas são validados, e as ferramentas montadas respeitam os mesmos gates de aprovação humana das demais operações: nada que toque o ambiente do cliente roda antes do "Aprovar". A execução no ambiente do cliente passa pelo EcoTrust Connect, que conecta de dentro para fora, sem portas de entrada.

Esses controles tratam do uso de MCP pela própria plataforma. Descoberta de servidores MCP no ambiente do cliente como categoria específica de ativo não faz parte do que a EcoTrust anuncia hoje.

Perguntas Frequentes

O MCP é seguro?

O protocolo define mecanismos de segurança, como autorização baseada em OAuth 2.1 para servidores remotos e regras contra repasse de token, mas a segurança real depende da implementação e da configuração de cada servidor e cliente. Os incidentes de 2025 vieram de servidores sem autenticação, pacotes maliciosos e falhas clássicas de código, não de uma falha única do protocolo.

O que é tool poisoning no MCP?

É esconder instruções maliciosas na descrição ou no resultado de uma ferramenta MCP. O usuário vê um resumo inofensivo, mas o modelo lê o texto completo e pode seguir as instruções, por exemplo lendo arquivos sensíveis e enviando o conteúdo a um servidor externo.

Qual a diferença entre tool poisoning e rug pull?

No tool poisoning, a ferramenta já chega envenenada. No rug pull, ela é aprovada limpa e muda depois, numa atualização. A defesa contra o segundo é detectar alterações na descrição e no comportamento e exigir nova aprovação.

Como descobrir servidores MCP na minha empresa?

Comece pelos arquivos de configuração dos assistentes de IA nas estações de desenvolvedores, pelos pacotes instalados e pelos serviços em nuvem que respondem nos caminhos usuais do protocolo. Depois inclua essa classe de ativo no inventário e no ciclo de gestão de exposição, com dono e versão registrados.

O OWASP tem um guia específico para MCP?

Sim. O OWASP mantém o projeto MCP Top 10, com riscos como gestão inadequada de tokens, e publicou um guia prático para desenvolvimento seguro de servidores MCP. O OWASP Top 10 para IA agêntica também cobre o tema, principalmente em uso indevido de ferramentas e cadeia de suprimentos.

Devo bloquear o uso de MCP na empresa?

Bloquear tende a empurrar o uso para a sombra. O caminho mais seguro costuma ser permitir servidores de uma lista aprovada, com autenticação, escopo mínimo e registro, e tratar o restante como exceção a remediar.

Conclusão: tratar cada servidor MCP como um ativo privilegiado

O MCP resolveu um problema real: ligar agentes às ferramentas da empresa sem escrever um conector para cada uma. O custo é que cada servidor passa a concentrar credenciais, dados e capacidade de ação, muitas vezes instalado sem passar por segurança. Os casos de 2025 e 2026 mostram que os ataques já existem e que a maioria explora o básico: falta de autenticação, privilégio excessivo e origem não verificada.

A resposta não exige uma disciplina nova. Exige aplicar ao MCP o que já funciona: inventário, dono, menor privilégio, aprovação para o que tem impacto, trilha de auditoria e correção contínua. Comece pelo checklist deste guia, inclua os servidores MCP no seu programa de exposição e use o OWASP Top 10 para IA agêntica para avaliar os agentes que vão consumir essas ferramentas.

---

Referências

• Model Context Protocol, "Security Best Practices" e "Authorization", especificação oficial. modelcontextprotocol.io
• Anthropic, "Donating the Model Context Protocol and establishing the Agentic AI Foundation", dezembro de 2025. anthropic.com
• Invariant Labs, "MCP Security Notification: Tool Poisoning Attacks", abril de 2025. invariantlabs.ai
• Equixly, "MCP Servers: The New Security Nightmare", março de 2025. equixly.com
• Oligo Security, "Critical RCE Vulnerability in Anthropic MCP Inspector (CVE-2025-49596)", 2025. oligo.security
• JFrog, "Critical RCE Vulnerability in mcp-remote: CVE-2025-6514", julho de 2025. jfrog.com
• The Hacker News, "Critical mcp-remote Vulnerability Enables Remote Code Execution", julho de 2025. thehackernews.com
• Knostic, "Mapping MCP Servers Study", 2025. knostic.ai
• Trend Micro, "MCP Security: Network-Exposed Servers Are Backdoors to Your Private Data", 2025. trendmicro.com
• The Hacker News, "First Malicious MCP Server Found Stealing Emails", setembro de 2025. thehackernews.com
• Cloud Security Alliance, "MCP by Design: RCE Across the AI Agent Ecosystem", abril de 2026. labs.cloudsecurityalliance.org
• OWASP, "MCP Top 10" e "A Practical Guide for Secure MCP Server Development". owasp.org e genai.owasp.org
• OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications for 2026", dezembro de 2025. genai.owasp.org
• EcoTrust, "EcoTrust OS: especificação técnica", 2026. ecotrust.io/materiais