Playbook de segurança para MCP e tool use

Uma coisa é saber que existem vulnerabilidades em MCP; outra é ter um playbook organizacional que atribui dono, processo e resposta para cada categoria de risco. A pesquisa MCPSHIELD mapeou "7 threat categories and 23 distinct attack vectors organized across four attack surfaces" analisando mais de 177 mil ferramentas MCP registradas - o que dá a qualquer time de segurança um ponto de partida concreto para organizar controles, não apenas identificá-los.

Por que nenhum controle isolado é suficiente

O achado mais importante do MCPSHIELD não é a lista de vulnerabilidades - é que nenhum mecanismo de defesa isolado cobre mais de 34% da superfície de ameaça mapeada. Isso muda a lógica de um playbook de segurança: em vez de escolher "o melhor controle", o objetivo é combinar controles complementares. A arquitetura que o próprio MCPSHIELD propõe junta controle de acesso baseado em capacidades, atestação criptográfica de ferramentas, rastreamento de fluxo de informação e execução de políticas em tempo real - e mesmo essa combinação alcança 91% de cobertura teórica, não 100%.

Tool registry como artefato de governança, não só técnico

Um tool registry central - listando toda ferramenta MCP aprovada, seu escopo, seu dono, e sua última revisão de segurança - é o que transforma "autenticação" e "autorização" de conceitos técnicos em processo auditável. O GitHub recomenda validar JWT contra JWKS e verificar audiência do token; esse controle só funciona em escala organizacional se houver um registro central definindo quais ferramentas existem e quem pode chamá-las.

Escopo mínimo e validação de inputs como política, não como boa prática opcional

Cada tool exposta via MCP deve ter o menor escopo possível - nunca acesso total a um sistema. Nenhum input vindo do agente deve ser confiado sem sanitização, porque o agente está, por definição, exposto a conteúdo que ele não controla totalmente (resultado de busca, documento externo, resposta de outra ferramenta).

Logging, runtime policy e threat modeling como ciclo contínuo

O GitHub recomenda logging estruturado com IDs de correlação e distributed tracing via OpenTelemetry, capturando especificamente eventos de segurança - tentativas de autenticação, falhas de autorização, padrões incomuns. Isso só vira playbook quando existe um processo definido de revisão desses logs, não apenas coleta. Runtime policy (rate limiting, circuit breakers no gateway) e threat modeling periódico - revisitando a lista de 23 vetores de ataque do MCPSHIELD à medida que novas ferramentas são adicionadas - fecham o ciclo.

Aprovação humana: onde ela realmente precisa entrar

Nem toda chamada de ferramenta precisa de aprovação humana - isso tornaria o agente inútil. O playbook precisa distinguir: ferramentas de leitura, de baixo risco, podem rodar autônomas; ferramentas que escrevem, deletam, ou movimentam dinheiro exigem checkpoint humano antes de executar, especialmente quando chamadas a partir de triggers automáticos.

Os dez controles do playbook

1. Autenticação - OAuth 2.1, validação de token contra JWKS
2. Autorização - escopo por identidade extraída do token, não assumida
3. Escopo mínimo - nunca acesso total a um sistema por uma tool
4. Validação de inputs - nunca confiar em parâmetro vindo do agente
5. Tool registry - inventário central com dono e escopo por ferramenta
6. Tool governance - processo de aprovação para cada nova ferramenta
7. Logging - eventos de segurança capturados à parte de logs gerais
8. Runtime policy - rate limit e circuit breaker no gateway
9. Human approval - checkpoint obrigatório para ações de escrita/exclusão
10. Threat modeling - revisão periódica contra a taxonomia de vetores conhecidos

Fontes

• GitHub - How to build secure and scalable remote MCP servers - https://github.blog/ai-and-ml/generative-ai/how-to-build-secure-and-scalable-remote-mcp-servers/
• Arxiv - MCPSHIELD - https://arxiv.org/abs/2604.05969