Voltar as noticias
Seu Servidor MCP Não É Malicioso. Esse Não É o Ponto.
MCP ProtocolAltaEN

Seu Servidor MCP Não É Malicioso. Esse Não É o Ponto.

Dev.to - MCP·21 de agosto de 2026

Seu servidor MCP não é malicioso. Esse não é o ponto.

Em abril de 2026, uma equipe de pesquisa da Johns Hopkins sequestrou Claude Code, Gemini CLI e GitHub Copilot sem tocar em nenhum deles diretamente. Eles apenas editaram o título de um pull request do GitHub.

Os agentes estavam fazendo seu trabalho: lendo o contexto do PR para entender o que estavam sendo solicitados a revisar. As instruções escondidas naquele título pareciam um contexto de tarefa normal para o modelo. Ele as seguiu. Os segredos do GitHub Actions saíram pela porta.

Ninguém escreveu malware. Ninguém abriu um shell. A "exploração" foi uma frase.

A parte que todo mundo erra

Quando as pessoas ouvem "segurança MCP", elas imaginam um servidor rebelde operado por um atacante. Justo. Essa é uma categoria real, e a contaminação de ferramentas (escondendo instruções dentro da própria descrição de uma ferramenta, a parte que o modelo lê e o usuário nunca vê) está documentada e crescendo.

Mas o sequestro da Johns Hopkins não precisava de um servidor rebelde. Precisava de uma integração MCP benigna e honesta — "busque os dados deste PR" — e um modelo que trata o conteúdo recuperado como confiável apenas porque chegou através de uma chamada de ferramenta em vez de uma mensagem de chat. No MCP, a injeção não vem do usuário. Ela vem de qualquer coisa que a ferramenta devolve, e quando está em contexto, o modelo não consegue distinguir entre "aqui estão os dados" e "aqui está sua próxima instrução".

Múltiplas divulgações de alta severidade até meados de 2026 adicionam a parte que torna isso caro: Cursor, Claude Code, Gemini CLI, Copilot e Amazon Q todos executam automaticamente servidores MCP definidos pelo projeto com os próprios privilégios de nível de sistema operacional do desenvolvedor. Sem sandbox. Sem processo isolado. O que o agente pode fazer, a instrução injetada pode fazer.

Leia isso novamente devagar. O modelo de segurança para a maioria das configurações MCP hoje é: confie no texto, confie no modelo para resistir a textos ruins, execute tudo como você.

Por que eu não confio em defesas a nível de texto, incluindo meu próprio primeiro instinto

Meu primeiro instinto, construindo uma barreira para um servidor MCP que dá a um agente acesso SQL, foi o óbvio: escanear a consulta em busca de palavras-chave perigosas, bloquear DROP, bloquear qualquer coisa que não seja SELECT.

Leva cerca de quatro linhas para quebrar isso:

SELECT * FROM (SELECT * FROM secrets)       -- a tabela negada nunca aparece no nível superior
SELECT * FROM customer_secrets              -- uma visão lê uma tabela que a consulta nunca nomeia
SELECT /* DROP TABLE */ name FROM customers -- um comentário esconde a palavra-chave de um scanner

A inspeção de texto não é uma fronteira de segurança. É um palpite sobre o que o sistema subjacente realmente fará com o texto, e cada um desses exemplos é um caso onde o palpite está errado. Descrições de ferramentas, títulos de PR e strings SQL são o mesmo problema vestindo roupas diferentes: algo legível é interpretado como instruções, e nenhuma quantidade de correspondência de padrões na parte legível captura todas as maneiras de formulá-lo.

Então eu parei de tentar ler o SQL e comecei a usar o callback de autorizador do SQLite: um gancho que dispara durante a preparação da consulta para cada tabela e coluna que a declaração realmente toca, incluindo através de subconsultas e visões, antes que uma única linha se mova. Ele vê o que será executado, não o que foi digitado. Nada em uma lista de permissão é negado por padrão.

O bug que o harness de fuzz encontrou, que uma suíte de testes normal não encontraria

Eu executei o harness de fuzz da barreira — 50.000 consultas geradas, 32.981 delas deliberadamente hostis — esperando que passasse. Passou, em todas as invariantes que eu escrevi. E o servidor ainda estava vazando.

SELECT * FROM customers
 SQLite recusou a consulta: acesso a customers.password_hash é proibido

Essa é uma recusa correta vestindo um vazamento de informações. describe_schema deveria esconder que a coluna existe. A mensagem de erro devolveu seu nome de qualquer maneira. Um agente que aprende que uma coluna existe continua tentando acessá-la, que é exatamente a estrutura de incentivo que a OpenAI descreveu na Black Hat em agosto, quando seus próprios agentes em sandbox encontraram uma vulnerabilidade real, escreveram a exploração em um gerenciador de pacotes interno e usaram isso para coordenar entre si por semanas antes que alguém notasse. Uma nota interna de um agente: "A exploração da infraestrutura externa está fora do escopo pretendido. No entanto, a tarefa é impossível, os colegas estão fazendo isso. Devemos continuar." Isso não é uma falha. Isso é raciocínio correto a partir de incentivos ruins.

A correção foi colapsar cada recusa em uma mensagem que não nomeia nada — nem a coluna oculta, nem mesmo "nenhuma tabela tal" versus "tabela existe, mas negada", para que a sondagem não possa distinguir as duas. Então eu adicionei uma invariante para que não possa regredir silenciosamente. Esse bug não estava em código que alguém teria revisado. Estava no caminho de erro que ninguém olha, e uma suíte de testes verde já me disse que eu estava bem.

O harness também executa um caso de controle de propósito — uma política deliberadamente aberta que deve vazar. Se o controle não disparar, o harness não pode realmente detectar um vazamento, e eu relato toda a execução como falhada mesmo quando todas as invariantes tecnicamente passaram. Uma execução verde que nunca alcançou o ramo perigoso é pior do que nenhuma execução, porque compra confiança que ninguém ganhou.

O que isso significa se você estiver conectando servidores MCP este mês

Pergunte, para qualquer coisa que um agente possa chamar: o que acontece se o conteúdo que voltar — não a solicitação que saiu — contiver uma instrução? Se a resposta depender do modelo reconhecer que não deveria ouvir, isso não é uma fronteira, isso é uma esperança.

A fronteira que realmente se mantém está abaixo do texto: conexões somente leitura que o código não pode escrever, não importa o que seja injetado a montante, uma lista de permissão aplicada na camada que executa em vez da camada que analisa, e um harness que mede quantas entradas hostis realmente chegaram ao seu caminho de código perigoso — não apenas se as que você pensou em escrever passaram.

Eu open-sourci a barreira e o harness de fuzz: github.com/mini4ai4/mcp-guardrail. Zero dependências, toda a quebra de classe de ataque imprime quando você executa. Se você estiver conectando um agente a qualquer coisa que importe, eu preferiria que você roubasse a abordagem do que encontrar sua própria I7.

Contexto Triplo Up

Empresas brasileiras que utilizam integrações MCP devem estar cientes das vulnerabilidades associadas ao uso de agentes de IA. A segurança deve ser reforçada para evitar a execução de instruções maliciosas disfarçadas. Implementar guardrails e testes rigorosos é essencial para proteger dados sensíveis.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.