O blog de segurança da FireAI

Por FireAI Security & Research Team · Publicado

O Ponto Cego do MCP: Quando um Documento Consegue Fazer o Seu Agente de IA Agir

O Ponto Cego do MCP: Quando um Documento Consegue Fazer o Seu Agente de IA Agir

A Anthropic apresentou o Model Context Protocol (MCP) a 25 de novembro de 2024 como "um padrão aberto que permite aos programadores construir ligações seguras, bidirecionais, entre as suas fontes de dados e as ferramentas alimentadas por IA". Na prática, o MCP deixa um assistente de IA chamar programas locais, chamados servidores MCP, que leem ficheiros, consultam bases de dados, ou alcançam a web em seu nome. Isso é genuinamente útil, e é também um novo tipo de superfície de ataque: o modelo decide qual a ferramenta a chamar com base em texto que leu, e nem sempre consegue distinguir as suas instruções das de outra pessoa.

Como corre de facto um servidor MCP

A especificação do MCP define dois transportes. Sobre stdio, "o cliente lança o servidor MCP como um subprocesso" e os dois falam através da entrada e saída padrão. Sobre HTTP com fluxo contínuo (Streamable HTTP, que substituiu o transporte original HTTP+SSE da especificação de novembro de 2024), o servidor corre como o seu próprio processo local e o cliente envia-lhe pedidos HTTP, recebendo opcionalmente de volta um fluxo de Eventos Enviados pelo Servidor (especificação do MCP, transportes). Seja como for, um servidor MCP local corre normalmente com as mesmas permissões de ficheiros e de rede da pessoa que o iniciou, porque nada no protocolo exige o contrário.

A própria especificação assinala diretamente o risco da variante HTTP: exige que os servidores validem o cabeçalho Origin, recomenda ligar-se a 127.0.0.1 em vez de 0.0.0.0 quando corre localmente, e pede autenticação em cada ligação, avisando que sem isto, "atacantes poderiam usar DNS rebinding para interagir com servidores MCP locais a partir de sítios web remotos."

O mecanismo: um delegado confuso

O nome clássico para este modo de falha é o problema do delegado confuso: "um programa de computador que é enganado por outro programa (com menos privilégios ou menos direitos) para fazer mau uso da sua autoridade." Um agente de IA com acesso a ferramentas MCP é um delegado com autoridade real — para ler os seus ficheiros, para fazer pedidos de rede — a agir sobre instruções que podem chegar a partir de conteúdo que só lhe pediram para resumir ou analisar. Quando esse conteúdo contém as suas próprias instruções, o agente pode segui-las em vez de, ou além de, seguir as suas. É a isto que a classe de riscos do Top 10 da OWASP para Aplicações LLM chama injeção de comandos e agência excessiva: OWASP: Top 10 para Aplicações LLM; OWASP LLM01:2025, Injeção de Comandos.

Um caso demonstrado: o servidor MCP do GitHub

Isto não é teórico. A 26 de maio de 2025, a Invariant Labs reportou uma prova de conceito contra o servidor MCP oficial do GitHub, que na altura tinha cerca de 14 mil estrelas no GitHub. A sua configuração: um agente com acesso a um repositório público e a um repositório privado foi instruído a rever problemas (issues) abertos no público. Um problema construído propositadamente no repositório público transportava instruções ocultas; o agente, ao lê-lo como parte da sua tarefa normal, seguiu-as, e na demonstração acabou por expor detalhes do repositório privado, incluindo informação que os investigadores descrevem como pessoal, para o fio de discussão do problema controlado pelo atacante. A Invariant Labs foi explícita ao dizer que isto foi uma prova de conceito demonstrada em repositórios de teste, e não um ataque observado no mundo real, e que "isto não é uma falha no código do servidor MCP do GitHub em si, mas antes uma questão arquitetural fundamental que tem de ser resolvida ao nível do sistema do agente." O modelo usado na demonstração foi o Claude 4 Opus.

A trifecta letal

A 16 de junho de 2025, Simon Willison nomeou o padrão por trás de casos como este de "trifecta letal": um agente que tem (1) acesso a dados privados, (2) exposição a conteúdo não fiável, e (3) uma forma de comunicar para o exterior. "Se o seu agente combina estas três características, um atacante pode facilmente enganá-lo para aceder aos seus dados privados e enviá-los para esse atacante." Nomeia o MCP especificamente como um contribuidor: "O problema com o Model Context Protocol — MCP — é que encoraja os utilizadores a misturar e combinar ferramentas de fontes diferentes que podem fazer coisas diferentes," o que torna fácil acabar com as três propriedades ativas numa única sessão sem se decidir por isso.

Por que isto é difícil de ver para as ferramentas de endpoint

Do ponto de vista do sistema operativo, nada de invulgar aconteceu no caso do MCP do GitHub: uma aplicação assinada e de confiança leu algum texto e fez um pedido de rede através de um processo auxiliar local que estava configurada para usar. Não há nenhum binário malicioso para sinalizar e nenhuma exploração de uma falha de segurança de memória. O pedido que importa — o que transporta dados para fora — tem a mesma forma de qualquer outra chamada de ferramenta que o agente faz corretamente uma centena de vezes por dia.

O que realmente reduz o risco

  • Dê a cada servidor MCP as ferramentas e o âmbito de ficheiros mais estreitos de que precisa, e não acesso amplo ao sistema de ficheiros ou à shell, para que uma chamada de ferramenta sequestrada tenha menos por onde atuar.
  • Trate qualquer conteúdo que um agente leia a partir de algo fora do seu controlo (problemas, páginas web, ficheiros transferidos) como entrada não fiável, com a mesma disciplina que aplicaria à entrada de utilizador em qualquer outro sistema.
  • Siga as orientações ao nível do transporte que a própria especificação do MCP dá: ligue os servidores locais apenas a localhost, exija autenticação, valide o cabeçalho Origin.
  • Vigie, ou controle, o único passo que todas as versões deste ataque partilham: a ligação de saída que transportaria os dados até ao atacante. Esse passo acontece depois de o modelo já ter sido enganado, o que é precisamente por que é o sítio mais fiável para o apanhar.

O papel do FireAI e da HisnLabs

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: uma firewall com IA que corre diretamente no seu Mac. Mostra, em linguagem clara, cada ligação que as suas aplicações fazem e deixa-o decidir o que sai do seu Mac — a IA funciona localmente, pelo que o seu tráfego nunca é enviado para nós nem para mais ninguém. A equipa de investigação em segurança da HisnLabs é quem mantém essas decisões fiáveis: cataloga que domínios são simples telemetria e quais são um serviço real, acompanha o país e a rede por detrás de uma ligação e treina o modelo local (a funcionalidade Autopilot) com padrões de tráfego reais, sem que nada disso saia do seu Mac.

Pode ler as decisões técnicas por detrás dele, ou experimentar o FireAI durante 17 dias, em FireAI, da HisnLabs.

Fontes