O Model Context Protocol mudou tudo. Pela primeira vez, agentes de IA podem ler seus bancos de dados, chamar suas APIs, executar código, modificar arquivos e gerenciar infraestrutura em nuvem — tudo por meio de uma interface única e padronizada. A Anthropic abriu o código do MCP no final de 2024. Em poucos meses, já estava em todo lugar. Microsoft, Google, Amazon, centenas de ferramentas. A curva de adoção foi vertical.
E esse é exatamente o problema.
MCP servers estão se tornando a nova camada de API — os guardiões entre agentes de IA e tudo que importa na sua organização. Seus dados. Sua infraestrutura. Sua lógica de negócio. Se você está construindo, implantando ou dependendo de um, precisa entender como MCP servers realmente funcionam — e quão expostos a maioria deles está. Porque a resposta é desconfortável.
Os números contam uma história preocupante
Em 2025, a Astrix Security realizou uma análise de mais de 5.200 implementações open-source de MCP servers. Os resultados foram alarmantes: 53% dependem de segredos estáticos de longa duração, como chaves de API e tokens de acesso pessoal. Apenas 8,5% utilizam métodos modernos de autenticação como OAuth. A pesquisa da HiveTrail pintou um cenário ainda mais grave — 43% dos MCP servers open-source analisados possuem falhas de injeção de comandos, 33% permitem buscas de URL sem restrição, e 22% vazam arquivos fora dos diretórios pretendidos.
Quase 2.000 MCP servers estão expostos publicamente na internet hoje sem autenticação e sem controle de acesso. Não mal configurados — simplesmente desprotegidos por design. A própria especificação do MCP oferece orientação mínima sobre autenticação, o que levou a uma postura de segurança fragmentada e perigosamente inconsistente em todo o ecossistema.
Isso não é um problema teórico. Somente em 2025, vulnerabilidades críticas de execução remota de código foram divulgadas em MCP servers em produção: CVE-2025-6514, CVE-2025-53967 no Framelink Figma MCP Server, e CVE-2025-49596 no MCP Inspector da própria Anthropic. A Asana corrigiu um bug em seu MCP server que poderia ter exposto dados de clientes. Uma vulnerabilidade de injeção de prompt foi reportada no MCP server oficial do GitHub.
Os cinco vetores de ataque que toda equipe precisa conhecer
O emergente framework OWASP MCP Top 10 identifica diversas categorias críticas de ameaças. Compreendê-las é o primeiro passo para construir uma infraestrutura resiliente.
1. Injeção de prompt
A OWASP classifica a injeção de prompt como o risco número um para aplicações LLM (LLM01:2025). No contexto MCP, este ataque usa entradas manipuladas para induzir agentes de IA a executar ações não previstas através de suas ferramentas conectadas — exfiltração de dados, escalação de privilégios, modificações não autorizadas. A injeção indireta de prompt é particularmente perigosa: instruções maliciosas são embutidas em conteúdo externo que o agente de IA ingere, invisíveis para operadores humanos mas fielmente executadas pelo modelo.
2. Envenenamento de ferramentas
O envenenamento de ferramentas é uma forma de injeção indireta de prompt exclusiva do ecossistema MCP. Atacantes modificam os metadados de uma ferramenta — sua descrição, esquema de parâmetros ou documentação do tipo de retorno — para embutir instruções ocultas que o modelo de IA segue. A ferramenta envenenada nem precisa ser invocada diretamente; sua simples presença na janela de contexto do modelo pode alterar como o agente interage com outras ferramentas legítimas.
3. Ataques à cadeia de suprimentos
MCP servers seguem um modelo de distribuição similar ao npm: desenvolvedores instalam pacotes de registros, configuram via JSON e os executam com amplo acesso ao sistema. Um único pacote comprometido pode se propagar por milhares de implantações. Diferente dos ecossistemas tradicionais de pacotes, MCP servers frequentemente rodam com privilégios elevados — acesso direto a bancos de dados, sistemas de arquivos e infraestrutura de rede — tornando o raio de explosão de um ataque à cadeia de suprimentos significativamente maior.
4. Shadow MCP
Shadow MCP é o equivalente MCP da shadow IT. Engenheiros iniciam MCP servers não autorizados para prototipar rapidamente ou integrar com um cliente de IA pessoal. Esses servidores operam fora do perímetro de segurança da organização — sem governança, sem supervisão, sem monitoramento. Acessam bancos de dados de produção com credenciais de desenvolvedor e fazem chamadas de API com tokens pessoais.
5. Lacunas de autenticação e autorização
A especificação MCP exige identificadores de sessão em URLs — uma prática que viola princípios fundamentais de segurança e expõe material de credencial em logs de servidor, históricos de navegador e cabeçalhos HTTP referrer. A maioria dos servidores não implementa integração SSO, controle de acesso baseado em função, nem rotação de tokens. O resultado: uma URL vazada concede acesso completo e persistente a todo o servidor.
Já vimos esse padrão antes
A dívida de segurança acumulada no ecossistema MCP não é sem precedentes. Vimos isso com APIs REST lançadas sem limitação de taxa no início dos anos 2010. Vimos com bancos de dados NoSQL distribuídos com credenciais padrão expostas na internet. Vimos com containers Docker rodando como root com mounts do filesystem do host por meia década. Toda vez, o padrão é o mesmo: uma nova tecnologia entrega capacidades incríveis sem nenhuma proteção, a adoção supera a conscientização sobre segurança, e a indústria gasta anos corrigindo retroativamente o que deveria ter sido seguro desde o primeiro dia.
O MCP está exatamente nesse ponto de inflexão agora. O ecossistema é jovem o suficiente para acertar. Mas a janela está se fechando.
Se um MCP server pode executar código, acessar dados e fazer chamadas de rede — então ele deve ser isolado, autenticado e monitorado desde o momento em que roda pela primeira vez. Não depois da primeira violação. Não depois da primeira auditoria de conformidade. Desde o nascimento.
O que segurança integrada ao runtime realmente significa
Vinkius é uma plataforma cloud construída especificamente para implantar MCP servers com segurança como arquitetura fundamental — não como um toggle de configuração. Cada server implantado na Vinkius roda dentro de seu próprio V8 isolate, a mesma tecnologia de sandboxing que alimenta o Cloudflare Workers e o isolamento de abas do Chrome. O isolate aplica 34 regras de engenharia que governam cada aspecto da execução: limites de memória, limites de timers, acesso à rede, operações criptográficas e limpeza de recursos.
Sandboxing V8 isolate
Cada MCP server recebe seu próprio espaço de memória isolado com um limite de heap configurável (padrão: 32 MB). Não há acesso ao sistema de arquivos. Não há contaminação de memória entre servidores. O isolate executa código do desenvolvedor em um ambiente completamente selado: globalThis.console é um proxy buraco negro, process.env é um objeto vazio, e setInterval é intencionalmente desativado. Chamadas fetch são proxiadas pelo host com um limite de resposta de 10 MB aplicado via contador de bytes em streaming.
Proteção SSRF proxy
Todas as requisições de rede saindo de MCP servers na Vinkius passam por um SSRF guard com IP fixado. Antes de qualquer requisição HTTP deixar a plataforma, o DNS é resolvido para um endereço IPv4 e validado contra uma lista de bloqueio abrangente: faixas privadas RFC 1918, loopback, endereços link-local (incluindo o famoso endpoint de metadados da AWS em 169.254.169.254), loopback IPv6 e faixas unique-local.
Prevenção de perda de dados (DLP)
Controles DLP configuráveis inspecionam todos os dados de saída em busca de padrões sensíveis antes de deixar a plataforma: chaves de API, tokens de autenticação, informações pessoais identificáveis, números de cartão de crédito e padrões customizados definidos pelo operador. Quando detectado, o dado é redactado em trânsito antes de alcançar o destino. O DLP é habilitado por padrão em toda implantação.
Autenticação HMAC
Toda requisição a um MCP server hospedado na Vinkius é assinada criptograficamente via HMAC-SHA256. Não há chaves de API estáticas para vazar e nem URLs para adivinhar. A ponte Web Crypto da plataforma delega assinatura e verificação ao módulo crypto nativo do Node.js no lado do host, garantindo que material de chave jamais entre no sandbox V8.
O caminho adiante para o ecossistema MCP
Acreditamos que MCP servers se tornarão tão onipresentes quanto APIs REST nos próximos dois anos. Toda empresa vai operá-los. Todo framework de agente de IA — de LangChain a CrewAI a AutoGen — vai depender deles. A questão não é se o ecossistema vai escalar, mas se vai escalar com segurança. Por isso construímos Vinkius sobre um framework MCP open-source pensado para produção desde o primeiro dia.
Vinkius existe para tornar o caminho seguro o caminho fácil. Quando você implanta um MCP server na Vinkius, o isolamento V8 não é opcional. A proteção SSRF não é algo que você configura. O DLP não é um tier premium. A autenticação HMAC não é uma flag que você lembra de ativar. Esta é a arquitetura. É assim que todo MCP server seguro deveria funcionar.
Este é o dia um
O ecossistema MCP ainda é jovem. Os padrões ainda estão sendo escritos. A infraestrutura ainda está sendo construída. Há uma janela estreita — agora — para incorporar segurança nos fundamentos da infraestrutura de agentes de IA, em vez de gastar a próxima década remendando-a.
Se você está construindo MCP servers, se está implantando agentes de IA em produção, se se importa com a integridade da infraestrutura da qual seus modelos dependem — nunca houve um momento mais crítico para acertar isso.