A Anthropic apresentou o Model Context Protocol (MCP) em 25 de novembro de 2024 como "um padrão aberto que permite que desenvolvedores construam conexões seguras e bidirecionais entre suas fontes de dados e ferramentas com IA". Na prática, o MCP permite que um assistente de IA chame programas locais, chamados servidores MCP, que leem arquivos, consultam bancos de dados ou acessam a web em seu nome. Isso é genuinamente útil, e também é um novo tipo de superfície de ataque: o modelo decide qual ferramenta chamar com base em um texto que leu, e nem sempre consegue distinguir suas instruções das de outra pessoa.
Como um servidor MCP de fato roda
A especificação do MCP define dois transportes. Sobre stdio, "o cliente inicia o servidor MCP como um subprocesso" e os dois conversam pela entrada e saída padrão. Sobre Streamable HTTP (que substituiu o transporte original HTTP+SSE da especificação de novembro de 2024), o servidor roda como seu próprio processo local e o cliente envia requisições HTTP a ele, opcionalmente recebendo de volta um fluxo de Server-Sent Events (especificação do MCP, transportes). De qualquer forma, um servidor MCP local geralmente roda com as mesmas permissões de arquivo e rede da pessoa que o iniciou, porque nada no protocolo exige o contrário.
A própria especificação sinaliza diretamente o risco da variante HTTP: ela exige que os servidores validem o cabeçalho Origin, recomenda vincular-se a 127.0.0.1 em vez de 0.0.0.0 ao rodar localmente, e pede autenticação em toda conexão, alertando que, sem isso, "atacantes poderiam usar DNS rebinding para interagir com servidores MCP locais a partir de sites remotos."
O mecanismo: um confused deputy
O nome clássico para esse modo de falha é o confused deputy problem: "um programa de computador que é enganado por outro programa (com menos privilégios ou menos direitos) para usar mal sua autoridade." Um agente de IA com acesso a ferramentas MCP é um representante com autoridade real — para ler seus arquivos, para fazer requisições de rede — agindo sobre instruções que podem chegar de conteúdo que foi apenas solicitado a resumir ou analisar. Quando esse conteúdo carrega suas próprias instruções, o agente pode segui-las em vez de, ou além de, as suas. É isso que a classe de riscos do Top 10 da OWASP para Aplicações LLM chama de injeção de prompt e agência excessiva: OWASP: Top 10 para Aplicações LLM; OWASP LLM01:2025, Injeção de Prompt.
Um caso demonstrado: o servidor MCP do GitHub
Isso não é teórico. Em 26 de maio de 2025, a Invariant Labs relatou uma prova de conceito contra o servidor MCP oficial do GitHub, que tinha cerca de 14 mil estrelas no GitHub na época. A configuração deles: um agente com acesso a um repositório público e a um privado foi solicitado a revisar issues abertas no público. Uma issue elaborada no repositório público carregava instruções ocultas; o agente, ao lê-la como parte da sua tarefa normal, as seguiu, e na demonstração passou a expor detalhes do repositório privado, incluindo informações que os pesquisadores descrevem como pessoais, para a thread da issue controlada pelo atacante. A Invariant Labs foi explícita ao afirmar que isso foi uma prova de conceito demonstrada em repositórios de teste, não um ataque observado em produção, e que "isso não é uma falha no código do servidor MCP do GitHub em si, mas sim uma questão arquitetural fundamental que precisa ser resolvida no nível do sistema do agente." O modelo usado na demonstração foi o Claude 4 Opus.
A trifecta letal
Em 16 de junho de 2025, Simon Willison nomeou o padrão por trás de casos como esse de "trifecta letal": um agente que tem (1) acesso a dados privados, (2) exposição a conteúdo não confiável, e (3) uma forma de se comunicar externamente. "Se o seu agente combina esses três recursos, um atacante consegue facilmente enganá-lo para acessar seus dados privados e enviá-los a esse atacante." Ele nomeia o MCP especificamente como um fator contribuinte: "o problema com o Model Context Protocol — MCP — é que ele incentiva os usuários a misturar e combinar ferramentas de fontes diferentes que fazem coisas diferentes", o que torna fácil acabar com as três propriedades ativas em uma única sessão sem ter decidido isso.
Por que isso é difícil de ver para ferramentas de endpoint
Do ponto de vista do sistema operacional, nada de incomum aconteceu no caso do MCP do GitHub: um aplicativo assinado e confiável leu um texto e fez uma requisição de rede por meio de um processo auxiliar local que estava configurado para usar. Não há binário malicioso para sinalizar e nenhuma exploração de um bug de segurança de memória. A requisição que importa — a que carrega os dados para fora — tem o mesmo formato de qualquer outra chamada de ferramenta que o agente faz corretamente uma centena de vezes por dia.
O que de fato reduz o risco
- Dê a cada servidor MCP as ferramentas e o escopo de arquivos mais estreitos que precisa, não acesso amplo a sistema de arquivos ou shell, para que uma chamada de ferramenta sequestrada tenha menos com o que trabalhar.
- Trate qualquer conteúdo que um agente leia fora do seu controle (issues, páginas web, arquivos baixados) como entrada não confiável, a mesma disciplina que você aplicaria à entrada de usuário em qualquer outro sistema.
- Siga a orientação em nível de transporte que a própria especificação do MCP fornece: vincule servidores locais a localhost, exija autenticação, valide o cabeçalho Origin.
- Observe, ou controle, a única etapa que toda versão desse ataque compartilha: a conexão de saída que carregaria os dados até o atacante. Essa etapa acontece depois que o modelo já foi enganado, o que é exatamente o motivo pelo qual é o lugar mais confiável para detectá-la.
Onde FireAI e HisnLabs entram nessa história
The step an injected agent cannot skip is the outbound connection that carries your data out, which is exactly what a per-app firewall like FireAI is built to see and stop, whether the process asking to connect is a familiar app or an MCP server it has never seen before.
O FireAI é o produto da HisnLabs: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso Autopilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.
Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em FireAI, da HisnLabs.