A Segurança do MCP Está em Alta: Todos os Soluções Falham em um Ponto
A Red Hat publicou um guia sobre autenticação MCP. A Aembit escreveu sobre padrões de autenticação obrigatórios para sistemas agentes. A Nudge Security analisou os riscos de exposição de servidores MCP. A Supabase lançou a integração do OAuth MCP. Tudo isso na última semana.
O ecossistema de IA agente está despertando para uma verdade que é óbvia há meses: o MCP não tem camada de identidade.
Todo chamado de ferramenta, todo acesso a dados, toda interação de sistema através do MCP acontece sem que o agente chamador prove quem ele é. A especificação não foi lançada com autenticação. A comunidade agora está se apressando para adicionar isso.
O Que Todos Estão Propondo
As soluções convergem para a mesma pilha:
- OAuth 2.1 para autorização baseada em token
- Keycloak / Auth0 / Supabase como provedores de identidade
- SPIFFE / mTLS para identidade de carga de trabalho
- RBAC / ABAC para controle de acesso granular
Isso é uma boa higiene empresarial. Se você está executando servidores MCP dentro de uma rede corporativa com gerenciamento de identidade centralizado, esses padrões funcionam.
O Que Todos Eles Perdem
Cada uma dessas soluções assume infraestrutura centralizada:
- Um servidor OAuth que alguém opera
- Uma autoridade certificadora que alguém controla
- Um provedor de identidade que alguém paga
- Um mecanismo de políticas que alguém configura
Mas o caso de uso de MCP que mais cresce não é o empresarial. É agentes de código aberto chamando servidores MCP de código aberto. Agentes pessoais. Ferramentas construídas pela comunidade. Agentes que não pertencem a nenhuma organização.
Quem executa o servidor OAuth para um agente autônomo rodando no laptop de alguém? Quem emite a identidade SPIFFE para um servidor MCP de código aberto no GitHub?
Ninguém. E essa é a lacuna.
O Problema da Identidade Ponto a Ponto
O que os agentes realmente precisam é da capacidade de:
- Provar quem eles são sem uma autoridade central
- Verificar quem está chamando sem um servidor OAuth
- Construir confiança através da reputação, não apenas de credenciais
- Assinar seus chamados de ferramenta para que o servidor saiba que a solicitação é autêntica
Este é um problema de identidade criptográfica, não um problema de IAM.
O Que AIP Faz de Diferente
AIP (Protocolo de Identidade de Agente) adota a abordagem oposta ao OAuth/SPIFFE. Em vez de identidade empresarial de cima para baixo, fornece identidade de pares de baixo para cima:
pip install aip-identity
aip init --name meu-agente --platform github/meurepo
Isso dá ao seu agente:
- Um par de chaves Ed25519 — sem CA necessária
- Um DID (identificador descentralizado) — sem operador de registro necessário
- A capacidade de assinar solicitações — qualquer servidor pode verificar
- Vouching entre pares — confiança através do comportamento, não de credenciais
Assinando um Chamado de Ferramenta MCP
from aip_identity import sign_message, get_identity
identity = get_identity()
# Assinar a carga útil do chamado da ferramenta
payload = {"tool": "read_file", "args": {"path": "/data/report.csv"}}
signature = sign_message(json.dumps(payload), identity.private_key)
# O servidor MCP pode verificar: quem chamou isso, e se foi adulterado?
Verificando no Lado do Servidor
from aip_identity import verify_signature
# O servidor recebe: carga útil + assinatura + DID do chamador
is_valid = verify_signature(payload, signature, caller_public_key)
trust_score = get_trust_score(my_did, caller_did) # confiança transitiva
if is_valid and trust_score > 0.5:
# Executar o chamado da ferramenta
Sem servidor OAuth. Sem CA. Sem instância Keycloak. Dois agentes, dois pares de chaves, prova criptográfica.
Ambas as Abordagens São Necessárias
Isso não é um ou outro. Agentes empresariais precisam de OAuth + SPIFFE + política centralizada. Agentes autônomos precisam de identidade entre pares + assinaturas criptográficas + confiança baseada em reputação.
A questão interessante é onde elas se encontram. Um agente empresarial poderia ter tanto uma identidade SPIFFE (para sistemas internos) quanto um DID AIP (para interações de agentes entre organizações). O rascunho do IETF klrc-aiagent-auth-00 trata do caso empresarial. AIP trata do caso entre pares.
A conversa sobre segurança do MCP está acontecendo agora. Se você está construindo agentes que se comunicam com servidores MCP fora de sua organização, os padrões OAuth que todos estão propondo não ajudarão você. Você precisa de identidade entre pares.
AIP é código aberto: github.com/The-Nexus-Guard/aip
19 agentes registrados. 26 vouches ativos. 607 testes. pip install aip-identity.
A rede de confiança ao vivo: Observatório de Confiança
Empresas brasileiras que utilizam MCP devem estar cientes da falta de uma camada de identidade, o que pode comprometer a segurança. A adoção de protocolos como o AIP pode ser crucial para garantir a autenticidade em interações entre agentes. A implementação de soluções de identidade descentralizada pode melhorar a confiança e a segurança em ambientes de trabalho.
