A Lacuna de Segurança nos Servidores de Ferramentas MCP (E o que Eu Construi para Corrigi-la)

MCP (Modelo de Protocolo de Contexto) é como agentes de IA se conectam a ferramentas. Claude Desktop o utiliza, Cursor o utiliza, e milhares de desenvolvedores estão construindo servidores MCP para dar acesso da IA às suas APIs, bancos de dados e infraestrutura.

Há um problema: o MCP não possui um modelo de segurança.

O protocolo define como um cliente se comunica com um servidor, mas não diz nada sobre o que esse servidor pode fazer. Não há autenticação entre cliente e servidor. Não há autorização sobre quais ferramentas podem ser chamadas. Não há um registro do que aconteceu. A especificação assume que você lidará com tudo isso por conta própria.

A maioria das pessoas não faz isso.

O Que Realmente Dá Errado

Eu executo um servidor auto-hospedado com Prometheus, Grafana, Ollama, Gitea e uma série de outros serviços. Eu queria que o Claude Desktop consultasse todos eles através do MCP. A abordagem padrão é escrever um servidor Python FastMCP para cada um — algumas dezenas de linhas por serviço, codificar a chave da API, registrar as ferramentas, pronto.

Isso funciona até você pensar sobre o que realmente construiu:

Cada servidor MCP tem acesso total ao que seu processo pode alcançar. Sua ferramenta Prometheus também pode acessar sua API Grafana, sua API Gitea e qualquer outra coisa no localhost. Não há escopo.

As chaves da API vivem em variáveis de ambiente ou arquivos de configuração. Se você tem 9 servidores MCP, você tem 9 lugares onde credenciais estão em texto simples sem política de acesso.

Nada é registrado. Se Claude chama uma ferramenta que reinicia um serviço ou exclui dados, não há registro de qual ferramenta foi chamada, com quais parâmetros, por qual agente, a que horas.

Não há conceito de leitura versus escrita. Uma ferramenta existe ou não existe. O MCP não sabe que query_prometheus é seguro para chamar livremente, mas restart_service deve exigir aprovação.

A composição de ferramentas cria riscos emergentes. Quando Claude tem acesso a vários servidores MCP, ele pode encadear chamadas entre eles. O Servidor A lê dados sensíveis, o Servidor B publica em uma API externa — Claude poderia combiná-los de maneiras que nenhum dos servidores foi projetado para.

Esses não são riscos teóricos. Durante o desenvolvimento, declarei um agente como somente leitura (Nível de Confiança 1), mas dei a ele uma ferramenta que usava HTTP POST. O sistema que construí o bloqueou — bloqueou a chamada, registrou uma violação de confiança e me forçou a corrigir a configuração ou a atualizar explicitamente o nível de confiança. Sem essa aplicação, a ferramenta teria funcionado silenciosamente e eu nunca teria sabido que meu modelo de segurança estava errado.

O Que Eu Construi

Heddle é um runtime que fica entre sua configuração YAML e o protocolo MCP. Você define suas ferramentas em um arquivo de configuração, e o Heddle valida, protege e as serve — com aplicação de políticas em cada chamada.

Aqui está um servidor de ferramentas completo para Prometheus:

agent:
  name: prometheus-bridge
  version: "1.0.0"
  exposes:
    - name: query_prometheus
      access: read
      description: "Executar uma consulta PromQL "
      parameters:
        query: { type: string, required: true }
    - name: get_alerts
      access: read
      description: "Listar alertas ativas do Prometheus "
  http_bridge:
    - tool_name: query_prometheus
      method: GET
      url: "http://localhost:9090/api/v1/query"
      query_params: { query: query }
    - tool_name: get_alerts
      method: GET
      url: "http://localhost:9090/api/v1/alerts"
  runtime:
    trust_tier: 1

Execute heddle run agents/prometheus-bridge.yaml e Claude pode consultar o Prometheus em linguagem natural. Mas cada chamada passa por um pipeline de despacho de seis camadas antes de chegar à API:

Limitação de taxa → Verificação do modo de acesso → Regras de escalonamento → Aplicação do nível de confiança → Validação de entrada → Execução do bridge HTTP

Cada camada pode bloquear a chamada de forma independente e registrar o motivo.

Os Controles de Segurança

O pipeline de despacho aplica esses controles em cada chamada de ferramenta:

Níveis de Confiança (T1—T4). Cada configuração declara um nível de confiança. T1 (observador) pode apenas usar GET — qualquer POST/PUT/DELETE é bloqueado em tempo de execução, não apenas avisado. T2 (trabalhador) permite gravações com escopo. T3 (operador) permite invocação entre agentes. T4 (privilegiado) requer aprovação humana. Eu peguei uma real má configuração com isso — um agente T1 tentou fazer um POST e o aplicador bloqueou antes que a solicitação deixasse o processo.

Anotações do Modo de Acesso. Cada ferramenta é declarada como access: read ou access: write. Configurações T1 com ferramentas de escrita são rejeitadas no tempo de carregamento — antes mesmo do servidor começar. Esta é a versão em nível de esquema do menor privilégio.

Corretor de Credenciais. As chaves da API são armazenadas em ~/.heddle/secrets.json com políticas de acesso por configuração. As configurações as referenciam como {{secret:prometheus-token}} — resolvidas em tempo de execução, nunca escritas no arquivo YAML. Uma configuração só pode acessar segredos que lhe foram explicitamente concedidos. O acesso não autorizado é negado, registrado e a chamada é abortada antes que qualquer solicitação HTTP seja construída — falha fechada. (Não começou assim: a versão de lançamento devolvia uma string de espaço reservado e deixava a solicitação prosseguir. Uma revisão de segurança externa pegou isso. Mais sobre isso abaixo.)

Regras de Escalonamento. Condições declarativas que seguram uma chamada de ferramenta para revisão em vez de executá-la. Por exemplo, meu orquestrador de VRAM tem uma regra que...