MCP Tornou Ferramentas Descobertas, Mas Não Seguras

Seu agente se conecta a três servidores MCP, chama tools/list, e de repente pode pesquisar problemas, consultar um banco de dados, enviar e-mails, reembolsar pagamentos e excluir ambientes de teste.

O problema de integração está resolvido. As ferramentas são descobertas.

O problema de segurança não está.

MCP — o Protocolo de Contexto do Modelo — fez algo genuinamente útil: deu aos clientes de IA e servidores de ferramentas externas uma linguagem comum. Em vez de cada aplicativo de IA inventar seu próprio sistema de plugins, um cliente agora pode perguntar a um servidor quais ferramentas existem, inspecionar seus esquemas e chamá-las de uma maneira padronizada. Isso é um verdadeiro avanço para a interoperabilidade.

Mas a descobribilidade não é autorização. Uma lista de ferramentas não é uma fronteira de permissão. Um esquema JSON não é um sandbox. E uma descrição de ferramenta educada não é prova de que a ferramenta é segura.

MCP tornou as ferramentas fáceis de encontrar. Ele ainda deixa as partes difíceis para você: confiança, política, isolamento, consentimento, auditabilidade e defesa contra conteúdo hostil.

TL;DR

• MCP padroniza descoberta de ferramentas, descrição de esquemas e invocação de ferramentas.
• Ele não impõe inherentemente:
  • autorização por usuário
  • menor privilégio
  • sandboxing
  • fluxos de aprovação
  • sanitização de resultados de ferramentas
  • proteção contra injeção de prompt
  • confiança na cadeia de suprimentos
• Trate cada servidor MCP como um plugin com influência em tempo de execução, não como uma fonte de metadados inofensiva.
• As arquiteturas mais seguras colocam um gateway de política entre o agente e os servidores MCP.
• As descrições de ferramentas, esquemas e resultados de ferramentas são todos parte do contexto do modelo. Isso os torna superfície de ataque.

📋 Índice

• A vitória da descoberta
• 1. O Catálogo de Ferramentas Não é uma Fronteira de Permissão
• 2. Descrições de Ferramentas São Código de Prompt
• 3. “Servidor Confiável” É uma Suposição em Tempo de Execução, Não um Fato Estático
• 4. OAuth Dá Identidade, Não Intenção
• 5. Anotações de Ferramentas São Dicas, Não Guardas
• 6. Aprovação Humana Não Escala por Si Só
• 7. Resultados de Ferramentas São uma Superfície de Injeção
• 8. Servidores MCP Locais Ainda Executam Com Seus Privilégios
• 9. Registro Dinâmico de Ferramentas Quebra Revisões Estáticas
• 10. A Camada Faltante: Um Gateway de Política MCP
• Uma Lista de Verificação Prática de Segurança MCP

A vitória da descoberta

Antes dos protocolos no estilo MCP, conectar um assistente de IA a ferramentas muitas vezes significava código de cola sob medida: esquemas de função personalizados, manifests de plugins proprietários, fluxos de autenticação únicos e trabalho de integração específico do cliente.

MCP mudou isso ao dar aos clientes e servidores um protocolo compartilhado. Um cliente pode perguntar a um servidor o que ele oferece. O servidor pode descrever ferramentas com nomes, descrições e esquemas de entrada. O cliente pode então chamar essas ferramentas de uma maneira estruturada.

Isso é um grande negócio.

Mas também muda o modelo de ameaça.

Uma vez que as ferramentas são descobertas, elas se tornam parte do mundo do modelo. Seus nomes, descrições, esquemas e resultados entram no contexto. O modelo pode raciocinar sobre eles, ser influenciado por eles e escolher chamá-los.

Isso significa que o MCP não expõe apenas capacidades. Ele expõe influência.

Uma maneira útil de enquadrar o problema:

MCP lhe dá um catálogo. A segurança requer uma camada de governança.

O restante deste artigo passa pelos modos de falha que eu me preocuparia antes de conectar um servidor MCP a qualquer coisa que importe.

1. O Catálogo de Ferramentas Não é uma Fronteira de Permissão

Cenário:

Seu agente de suporte está conectado a um servidor CRM MCP. O servidor expõe list_customers, update_customer e delete_customer. Um engenheiro de suporte pede ao agente para “limpar contas de teste duplicadas.” O modelo vê delete_customer na lista de ferramentas, pensa que é relevante e a chama.

Por que isso importa:

O modelo não sabe o que um usuário deve estar autorizado a fazer. Ele só sabe quais ferramentas são visíveis e como usá-las. Se uma ferramenta aparece no catálogo, o modelo pode tratá-la como disponível.

Este é o erro de modelo mental mais comum com a descoberta de ferramentas MCP:

Se o servidor anunciou, deve ser seguro usar.

Não. Anunciar não é autorização.

Solução:

Filtre o catálogo de ferramentas com base no principal autenticado, no nível de risco da sessão e no contexto da tarefa. Não deixe que cada servidor MCP conectado despeje sua lista completa de ferramentas em cada sessão de agente.

Um filtro de política mínima pode parecer assim:

interface McpTool {
  name: string;
  description?: string;
  inputSchema: unknown;
}

interface Principal {
  id: string;
  roles: string[];
  can(action: string, resource: string): boolean;
}

function visibleToolsFor(
  principal: Principal,
  serverId: string,
  tools: McpTool[]
): McpTool[] {
  return tools.filter((tool) =>
    principal.can(
      "mcp:tools/list",
      `mcp-server:${serverId}:tool:${tool}