Seu Servidor MCP É o Maior Buraco do Seu Setup

Um servidor MCP malicioso pode roubar suas chaves SSH sem nunca escrever uma única instrução maliciosa completa. O grupo de pesquisa ASSET provou isso: quando um pedido de roubo é dado a um modelo num bloco só, os grandes modelos quase sempre recusam. Dividido em fragmentos que parecem inofensivos, o GPT-4o, o Gemini 2.0 Flash e o Llama 3.3 obedecem em 100% dos casos testados.

Enquanto isso, a maioria dos desenvolvedores adiciona um novo servidor MCP ao agente toda semana, copiando uma linha de config encontrada no GitHub. Cada um desses servidores guarda um pedaço do seu acesso: tokens de API, chaves de nuvem, service accounts. O MCP é útil — ninguém discute isso. Mas o servidor MCP virou o elo mais fraco de todo o agent stack.

Este artigo cobre como um servidor MCP vaza seus segredos sem ser notado, o ataque GhostSplice que burla as recusas do modelo dividindo suas instruções, e as defesas concretas, do Cloudflare WriteGuard às regras que você pode aplicar no seu próprio setup hoje mesmo.

Um servidor MCP é a ponte entre seu agente e uma ferramenta externa: seu banco de dados, seu GitHub, seu Slack, sua nuvem. Para fazer esse trabalho de ponte, ele guarda tudo que precisa para logar como você — tokens, chaves de API, credenciais de service account — em texto puro, num arquivo de config no seu disco, geralmente sem nenhuma criptografia.

Um detalhe do protocolo importa para o que vem depois. Quando um agente se conecta a um servidor MCP, o servidor devolve sua lista de ferramentas, cada uma com uma descrição em texto livre dizendo ao modelo quando e como usá-la. Essas descrições vão direto para o contexto do modelo, com o mesmo peso das suas próprias instruções, e os resultados que as ferramentas retornam também entram ali. Um servidor MCP fala com seu agente sem parar, em texto que ninguém relê. É exatamente isso que torna o ataque GhostSplice possível.

O ecossistema também cresceu mais rápido que suas proteções:

Sinal	Número
Servidores no registro oficial do MCP	9.600+
Crescimento de deployments de servidores remotos desde maio de 2025	5×

Qualquer um pode publicar um servidor, não há revisão central, e seu agente confia em cada um exatamente como confiaria num oficial. A NSA publicou um guia de segurança dedicado ao MCP em maio, afirmando que a adoção do protocolo passou à frente da construção de suas proteções. Quando uma agência de inteligência escreve um guia sobre sua ferramenta de desenvolvimento favorita, raramente é para te parabenizar.

Esse é o cenário: milhares de servidores, nenhuma revisão, e suas chaves no meio.

O primeiro furo são credenciais guardadas em texto puro. O The Hacker News publicou um detalhamento da mecânica do vazamento em 17 de agosto, e o ponto de partida é direto: tokens são colados direto em strings de configuração e ficam legíveis no disco. Um commit levemente apressado já basta para empurrar sua config para um repositório Git com as chaves dentro. Piora com o que o artigo chama de sprawl: as mesmas chaves duplicadas em arquivos de config, variáveis de ambiente e cópias em dev, staging e produção. Depois de um tempo ninguém sabe mais onde os segredos vivem, então ninguém os gira — e uma chave estática que nunca gira é uma chave esperando seu atacante.

O segundo furo é o excesso de permissões. Durante o desenvolvimento você dá ao seu servidor direitos amplos para evitar erros de autorização, e esses direitos amplos vão para produção sem mudar. Um único comprometimento então expõe muito mais do que o uso real jamais justificou.

O terceiro furo é a cadeia de suprimentos. O CVE-2025-6514 atingiu o mcp-remote, um proxy OAuth baixado mais de 400.000 vezes, e permitiu que um servidor malicioso disparasse injeção de comando na máquina do usuário — rodando código e saindo com credenciais. Um pacote npm popular, instalado em uma linha, e a porta se abriu.

O quarto furo é o mais traiçoeiro: prompt injection. Um agente lê tudo que suas ferramentas trazem de volta — uma página web, um ticket, um documento interno. Se um deles contém uma instrução escondida, o agente pode segui-la como se viesse de você, e usar suas ferramentas legítimas para expor o que deveria proteger. Esse vazamento não passa por nenhuma falha técnica; passa pela ingenuidade do modelo.

Antes de qualquer ataque sofisticado, a vida comum de um servidor MCP — config em texto puro, direitos exagerados, dependências não checadas, conteúdo sem filtro — já expõe seus segredos.

GhostSplice é o nome que o grupo de pesquisa ASSET deu a uma técnica que faz seu próprio agente rodar a exfiltração, com sua total cooperação. O princípio cabe numa frase: em vez de escrever o pedido de roubo por inteiro, o servidor malicioso o divide, coloca um fragmento na descrição de uma ferramenta e outro no resultado que essa ferramenta retorna. Cada pedaço, lido sozinho, parece inofensivo. Mas o agente combina tudo que entra em seu contexto de trabalho: ele reconstrói a instrução completa e a executa de total boa-fé — do ponto de vista dele, é só preencher o formulário que a ferramenta pediu.

Os números dos testes são a parte que realmente importa:

Modelo	Instrução em bloco único	Instrução fragmentada
GPT-4o	Recusa 100%	Obedece 100%
Gemini 2.0 Flash	Recusa 100%	Obedece 100%
Llama 3.3	Recusa 100%	Obedece 100%
Claude Haiku 4.5	Recusa via API	Obedece 100% no teste de três partes dentro do Cursor

O detalhe do Claude mata qualquer conclusão fácil: o mesmo modelo pode recusar num cliente e exfiltrar em outro, dependendo das proteções que esse cliente adiciona ou não.

O que o GhostSplice rouba nos testes: chaves SSH, segredos de ambiente, código-fonte, dados de clientes. Os pesquisadores trabalharam em projetos isolados com chaves falsas, não em vítimas reais, mas o método é publicado e reproduzível.

GhostSplice não é a primeira tentativa. O mesmo laboratório publicou o Ghostcommit em junho, um ataque que escondia suas instruções em arquivos PNG referenciados por convenções do projeto, e depois codificava os segredos roubados no código-fonte como inteiros. Dividir instruções é uma família de ataques se firmando, não uma curiosidade isolada.

Duas coisas mantêm isso em perspectiva. O ataque tem dois pré-requisitos: o servidor malicioso já está plugado no seu agente, e o agente tem acesso de leitura aos arquivos alvo. É exatamente por isso que a procedência importa tanto — de onde vêm seus servidores é sua primeira linha de defesa. E lembre-se da mecânica: o alinhamento do modelo não te protege, porque o ataque nunca pede nada proibido de uma vez só.

GhostSplice assumia um servidor malicioso já plugado. Mas quem decide o que é plugado? Num time, a resposta honesta é ninguém. Esse é o problema que a Cloudflare chama de shadow MCP: todos os servidores que desenvolvedores conectam a seus agentes sem nenhuma revisão de segurança. Até pouco tempo esse tráfego era invisível — um request MCP parece qualquer outra chamada HTTPS.

A Cloudflare mudou isso com detecção no nível do protocolo. Desde a atualização da especificação, todo cliente MCP conforme envia um header MCP-Protocol-Version em seus requests, e o Gateway inspeciona esse header em todo o tráfego TLS que decripta. Um time de segurança agora pode ver todo servidor MCP usado na empresa, com um dashboard dedicado: servidores únicos, usuários, volumes de request. Essa abordagem por header supera a filtragem por nome de domínio, porque um servidor MCP não tem motivo para se chamar mcp-alguma-coisa — o protocolo é identificado pelo que diz, não pelo que afirma ser.

O time também pode agir: um seletor is_mcp permite bloquear qualquer tráfego MCP que não veio por um portal aprovado. O portal é a outra metade do setup — um único ponto de acesso que agrupa os servidores validados atrás de autenticação de identidade.

A versão mais recente da especificação leva a visibilidade ainda mais longe. Os novos headers Mcp-Method e Mcp-Name expõem a operação pedida e a ferramenta chamada, sem o firewall precisar abrir o corpo do request. Um time consegue distinguir um agente lendo um ticket de um agente apagando cinquenta deles, direto no nível de rede.

A Cloudflare separa isso em dois casos: shadow MCP puro, um servidor que nunca foi aprovado, e portal bypass, um servidor aprovado acessado direto, driblando o checkpoint. Ambos são bloqueados pela mesma regra base. A lógica é simples: tudo que passa pelo portal é conhecido e registrado, o resto é bloqueado. Para uma empresa, é o fim do servidor MCP fantasma instalado numa sexta-feira à noite.

Até um servidor aprovado pode causar dano, porque um agente herda todos os direitos do usuário de uma vez. É aí que entra o WriteGuard, que a Cloudflare acabou de abrir em beta privado. A ideia: classificar cada ferramenta de cada servidor MCP num nível de risco, e aplicar uma política diferente por nível.

• Uma leitura passa sem atrito.
• Uma escrita contida, como postar um comentário, passa mas enriquecida: a ação é assinada como vinda de um agente, em nome de uma pessoa específica, e um evento de auditoria vai para um log central.
• Uma ação crítica — fazer merge de código, deploy para produção, apagar em massa — é bloqueada antes mesmo do servidor tratá-la.

O exemplo do GitLab no post da Cloudflare mostra bem essa gradação: ler um merge request passa, comentar nele passa com atribuição, e fazer o merge é recusado até uma pessoa fazer isso ela mesma.

A parte mais interessante é o modelo de identidade. O agente mantém as permissões do funcionário que ele serve, mas toda escrita agora carrega duas assinaturas: a pessoa, e a sessão do agente agindo em nome dela. Sistemas downstream finalmente conseguem distinguir uma mudança feita à mão de uma gerada por máquina, e a auditoria é enviada de forma assíncrona a um log central, sem dados sensíveis. Até agora um agente era indistinguível de seu humano nos logs; para uma auditoria de incidente isso muda tudo — uma única consulta diz se o merge duvidoso de terça-feira veio de um colega apressado ou de uma sessão de agente que se soltou.

A Cloudflare não está vendendo teoria; eles descrevem o próprio uso interno: o portal deles conecta 27 servidores MCP, contra 13 em abril. Esse número conta a história real — mesmo na Cloudflare, o número de servidores dobra em poucos meses, e é exatamente por isso que o controle ferramenta por ferramenta se torna necessário. A direção que a indústria está tomando é clara: parar de confiar no servidor inteiro, e decidir ação por ação o que um agente pode fazer.

Os limites precisam ser ditos com clareza. O WriteGuard é um beta privado atrás de um formulário de inscrição, e a detecção do Gateway precisa de um deployment de Cloudflare Zero Trust com inspeção de TLS ligada: para um desenvolvedor solo ou um time pequeno, isso simplesmente não é sua infraestrutura. Mesmo numa empresa, a detecção só enxerga o tráfego de rede que decripta — um servidor MCP local rodando por stdio, lançado como um processo comum na sua máquina, fica invisível para o Gateway. E é exatamente assim que a maioria dos servidores que desenvolvedores instalam realmente roda.

Acima de tudo, nenhuma dessas ferramentas conserta o mecanismo central que o GhostSplice expôs: enquanto um agente combina livremente tudo que entra em seu contexto, fragmentos inofensivos vão continuar se recompondo em instruções hostis. Os pesquisadores do ASSET dizem isso mesmos: a solução exige tratar a saída da ferramenta como dado, nunca como instrução, e essa separação ainda não existe nativamente nos agentes.

Enquanto isso, as recomendações deles se resumem a três movimentos: parar de deixar valores que saem de uma ferramenta alimentarem os argumentos de outra sem checagem, manter a capacidade de negar cada chamada de ferramenta manualmente, e tratar qualquer anotação vinda de um servidor não checado como hostil por padrão. Nenhuma das três é automática hoje: ou você aplica, ou ninguém aplica. Trate tudo que a Cloudflare lança aqui como cinto de segurança, não como freio — limita o dano, não evita a colisão.

O que fazer, a partir de hoje:

1. Inventário. Liste os servidores MCP realmente plugados nos seus agentes, e remova os que você não usa mais.
2. Classifique por procedência. Um servidor oficial de um fornecedor conhecido, sim. Um repositório do GitHub com 40 estrelas achado num fórum, não — não até você ter lido o que ele faz com seus dados.
3. Delimite os direitos. Dê a cada servidor um token dedicado com o escopo mínimo, nunca sua chave mestra, e gire esses tokens como faria em qualquer sistema de produção.
4. Mantenha a mão nas ações sensíveis. Um agente que escreve, faz merge ou apaga precisa voltar por você — a versão manual do que o WriteGuard industrializa.
5. Aplique a regra do GhostSplice no dia a dia. Quando seu agente encadear ações de ferramenta que você não pediu, pare e leia o que o servidor andou dizendo a ele.

Todo cliente de agente consegue listar seus servidores conectados e suas ferramentas, e essa lista leva trinta segundos para ler. Esses trinta segundos são a melhor relação tempo-segurança de todo o seu setup.

Se você está numa empresa, adicione a camada de rede: a detecção MCP do Gateway e os portais valem o esforço de implantação, porque o shadow MCP já existe na sua organização, você o veja ou não.

MCP não é o problema — a velocidade com que entregamos nossas chaves é.