MCP é seguro? Os riscos de conectar agentes de IA a bancos de dados e ferramentas externas

O MCP (Model Context Protocol) se tornou, em pouco mais de um ano, o jeito mais comum de conectar assistentes e agentes de IA a bancos de dados, planilhas, repositórios de código e outras ferramentas do dia a dia. Mas a mesma característica que tornou o protocolo tão popular — dar ao modelo de IA liberdade para decidir, em tempo real, qual ferramenta acionar e com quais dados — também abriu um tipo de brecha de segurança que a indústria só começou a mapear de verdade ao longo de 2026. A pergunta que pesquisadores de segurança vêm fazendo é direta: o MCP, do jeito que foi projetado, é seguro o suficiente para lidar com dados sensíveis e sistemas de produção?

Uma falha "por padrão", não um bug isolado

O caso mais grave descoberto até agora não é uma falha de implementação de um produto específico, mas algo embutido no próprio kit de desenvolvimento oficial do protocolo. Em abril de 2026, a empresa de segurança OX Security revelou que o mecanismo de transporte padrão do MCP, chamado STDIO — usado para conectar agentes a ferramentas instaladas localmente —, repassa comandos para o sistema operacional sem qualquer tipo de validação ou filtro. Na prática, isso permite que um invasor capaz de manipular um arquivo de configuração do MCP consiga executar comandos arbitrários na máquina onde o agente está rodando.

Segundo a pesquisa, a falha está presente nos kits oficiais em Python, TypeScript, Java e Rust, o que significa que ela se espalhou para qualquer projeto que confiou na implementação de referência do protocolo. A estimativa divulgada é de cerca de 200 mil instâncias vulneráveis, dentro de um ecossistema que já soma mais de 150 milhões de downloads de pacotes relacionados ao MCP. Entre os projetos afetados estão nomes conhecidos do desenvolvimento com IA, como Cursor, LiteLLM, LibreChat e Windsurf — alguns já corrigidos, outros ainda com correções pendentes meses depois do alerta.

O ponto mais controverso do caso foi a resposta da Anthropic, criadora do protocolo: a empresa confirmou que o comportamento é intencional e não fez mudanças na arquitetura do MCP, apenas atualizou a documentação de segurança alertando que esse tipo de conexão "deve ser usado com cuidado". Isso deixa a responsabilidade de higienizar essas conexões nas mãos de cada desenvolvedor que constrói em cima do protocolo — uma decisão que pesquisadores de segurança consideram arriscada justamente porque a maioria dos times que adota o MCP não tem, hoje, uma base de segurança pronta para lidar com esse tipo de exposição.

Além da falha técnica: engano, troca de máscara e servidores abertos

A vulnerabilidade do STDIO chamou atenção por sua gravidade técnica, mas ela é só uma fatia de um conjunto maior de riscos que já têm nome dentro da comunidade de segurança em IA:

Envenenamento de ferramentas ("tool poisoning"): a descrição de uma ferramenta MCP é lida pelo modelo de IA, mas normalmente não aparece na tela para quem está usando o agente. Isso permite esconder instruções maliciosas dentro dessa descrição, fazendo o agente executar ações não autorizadas ou vazar dados sem que a pessoa perceba. Um caso documentado mostrou um servidor MCP disfarçado de jogo de perguntas conseguindo instruir um agente a extrair o histórico de mensagens de um serviço de conversas conectado à mesma sessão.

Ataques de "troca de tapete" ("rug pull"): como o protocolo não exige nova aprovação quando as instruções de uma ferramenta mudam, um servidor pode se apresentar como confiável no primeiro uso e, silenciosamente, alterar seu comportamento depois — um problema que já teve consequência real em uma vulnerabilidade encontrada no editor de código Cursor, corrigida depois que pesquisadores mostraram como um arquivo de configuração aparentemente inofensivo podia ser trocado por um malicioso após a aprovação inicial.

"Sombreamento" entre servidores: como um agente pode se conectar a vários servidores MCP ao mesmo tempo — sistema de arquivos, GitHub, um banco de dados, uma ferramenta de pagamentos —, um servidor malicioso pode injetar instruções que fazem o agente tratar um servidor legítimo de forma diferente do esperado, transformando uma integração confiável em um canal de vazamento sem que ela própria tenha sido comprometida.

Servidores sem autenticação: a especificação do MCP trata a autenticação como opcional, não obrigatória. Um mapeamento feito em meados de 2025 encontrou quase dois mil servidores MCP expostos publicamente na internet, respondendo a pedidos sem qualquer verificação de credencial.

Casos reais, não só teoria

Esses riscos já geraram incidentes fora do ambiente de laboratório. Em um episódio amplamente citado por pesquisadores, um agente de IA operando com acesso privilegiado a um banco de dados processava tíquetes de suporte ao cliente que continham texto enviado pelos próprios usuários. Um invasor incluiu instruções escondidas dentro do texto de um desses tíquetes, levando o agente a ler tokens de integração sensíveis do sistema e publicá-los, sem querer, em uma conversa pública de suporte.

Outro caso envolveu um pacote de integração com um serviço de envio de e-mails disponibilizado publicamente: as primeiras versões do pacote funcionavam normalmente, criando confiança entre quem o instalava, até que uma atualização passou a copiar secretamente todos os e-mails enviados por quem usava a ferramenta para um endereço controlado pelo atacante — um padrão clássico de ataque à cadeia de suprimentos de software, agora aplicado ao ecossistema de agentes de IA.

O que isso muda para quem está construindo com MCP

Especialistas em segurança que analisaram esse cenário não recomendam abandonar o protocolo — hoje praticamente inevitável para quem constrói agentes de IA com acesso a ferramentas reais —, mas sim tratá-lo com o mesmo nível de desconfiança aplicado a qualquer peça de infraestrutura crítica. As recomendações mais repetidas incluem:

Tratar todo servidor MCP como um terceiro não confiável até que sua procedência seja verificada, especialmente quando vem de um repositório externo ou registro de pacotes.

Rodar conexões do tipo STDIO em ambientes isolados (containers ou sandboxes), sem acesso direto a credenciais ou caminhos sensíveis do sistema.

Fixar versões dos servidores MCP usados e configurar alertas para qualquer mudança na definição de uma ferramenta, em vez de aprovar automaticamente atualizações silenciosas.

Dar a cada servidor MCP apenas as credenciais mínimas necessárias para a tarefa específica que ele executa, em vez de reaproveitar credenciais amplas entre múltiplas integrações.

Monitorar o comportamento dos processos de servidores MCP em produção, de forma parecida com o que já se faz com qualquer outro componente de infraestrutura sensível.

O consenso entre os pesquisadores é que o MCP resolveu um problema real — conectar agentes de IA a ferramentas diferentes sem reinventar a integração a cada vez — mas cresceu mais rápido do que sua própria maturidade de segurança. Para quem está avaliando conectar um agente a bancos de dados de produção ou sistemas financeiros, a recomendação é simples: tratar cada nova conexão MCP como uma decisão de segurança, não apenas uma decisão de produto.