Este brief técnico da Workstation cobre a segurança e autenticação de IA agêntica: proteger agentes empresariais que chamam ferramentas via MCP (Model Context Protocol) com OAuth 2.1, colocar endpoints MCP de alto risco atrás de VPN / rede privada, e gerir credenciais de ferramentas com HashiCorp Vault — segredos dinâmicos, leases, rotação automática e revogação imediata. Recomenda configurações alinhadas com a indústria para Claude, OpenAI e Cursor.
- Problema: Agentes com chaves de ferramentas estáticas de longa duração + MCP público = dispersão de credenciais e movimento lateral.
- Auth: MCP remoto = servidor de recursos OAuth 2.1 + RFC 9728 PRM + audiência RFC 8707; PKCE obrigatório.
- Empresa: Preferir MCP Enterprise-Managed Authorization (EMA / ID-JAG) via IdP corporativo.
- Rede: MCP interno e Vault em VPN/ligação privada; allowlists de egress por ferramenta.
- Segredos: Segredos dinâmicos do Vault + TTL de lease; rotação automática de roles estáticos; revogar no fim da sessão.
- Separação: Chaves API do fornecedor LLM != tokens de acesso MCP != segredos de ferramentas backend.
Fontes: MCP Authorization, Vault leases, Vault AI agent validated pattern, Claude connector auth. Verifique a documentação atual do fornecedor antes do rollout em produção.
1. Modelo de ameaças para agentes empresariais
Um agente é um principal de automatização privilegiado. Modos de falha típicos:
- Dispersão de segredos — chaves API no JSON do MCP,
.envcommitados no git, ou colados em prompts. - Substituição de token — token de acesso emitido para o servidor A aceite pelo servidor B (falta de ligação de audiência).
- Ferramentas com excesso de âmbito — um MCP pode escrever em BD de prod e abrir firewalls com a mesma sessão.
- OBO não auditado — o agente age sem ligar ações a uma identidade humana.
- MCP público — ferramentas internas alcançáveis a partir da Internet sem VPN nem ligação privada.
Os controlos devem cobrir identidade (quem), autorização (que ferramentas), segredos (com que credenciais) e rede (de onde).
2. Autenticação MCP: padrão da indústria
Para MCP remoto baseado em HTTP, a especificação alinha-se com OAuth 2.1:
- Servidor MCP = servidor de recursos OAuth; os clientes enviam
Authorization: Bearer. - PKCE é obrigatório; o grant implícito é proibido.
- Os servidores MUST publicar Protected Resource Metadata (RFC 9728) para que os clientes descubram o servidor de autorização.
- Use Resource Indicators (RFC 8707) para que os tokens fiquem ligados à audiência desse servidor MCP.
- Authorization Server Metadata (RFC 8414) e/ou discovery OIDC para capacidades do AS.
- Dynamic Client Registration (RFC 7591) é recomendado quando os clientes devem registar-se sem IDs de cliente manuais.
# Protected Resource Metadata (conceptual)
{
"resource": "https://mcp.internal.example/mcp",
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["mcp:tools", "mcp:resources"]
}
STDIO / MCP local é diferente: prefira credenciais de ambiente injetadas pelo Vault Agent — não force OAuth de browser em cada ferramenta de desktop. O MCP remoto/público deve implementar OAuth 2.1.
2.1 Enterprise-Managed Authorization (zero-touch)
A extensão MCP Enterprise-Managed Authorization permite ao IdP corporativo (Okta, Entra ID, etc.) conceder acesso a servidores MCP aprovados no SSO usando um ID-JAG (Identity Assertion JWT Authorization Grant), evitando a fadiga de consentimento por servidor. Adote EMA para frotas Claude / IDE / agentes à escala da organização.
3. Integração VPN e MCP privado
OAuth autentica o cliente; não substitui o isolamento de rede.
- Hospede servidores MCP internos e Vault em CIDR privado (VPN, PrivateLink, mesh Tailscale/WireGuard ou mTLS de service mesh).
- Ligue listeners MCP a interfaces privadas; bloqueie o 443 público salvo se o produto for intencionalmente exposto à Internet.
- Aplique allowlists de egress a partir do runtime do agente: apenas APIs/hosts MCP aprovados.
- Separe planos: laptops de developers em VPN corporativa para Cursor; agentes no servidor em VPC sem MCP de Internet exceto SaaS aprovado.
Padrão: VPN para alcance + OAuth para autorização + Vault para segredos.
4. HashiCorp Vault para segredos de agentes
Chaves de ferramentas estáticas de longa duração são incompatíveis com o raio de explosão dos agentes. O Vault fornece:
4.1 Segredos dinâmicos + leases
Cada segredo dinâmico devolve um lease_id e um TTL. O consumidor deve renovar (se permitido) ou pedir uma substituição antes do vencimento. Quando o lease termina, o Vault pode revogar a credencial no fornecedor. Isto força o check-in, melhora os logs de auditoria e reduz as janelas de exposição.
4.2 Rotação automática
Para roles estáticos (p.ex. password de base de dados com rotation_period), o Vault rota segundo um calendário. Templates do Vault Agent voltam a obter perto do fim de vida (limiar por defeito lease_renewal_threshold ~0,9 do TTL) e podem reiniciar um processo filho quando as credenciais mudam.
4.3 TTLs recomendados para agentes
| Classe de risco | Exemplo | Orientação de TTL |
|---|---|---|
| Escrita crítica | Mutação BD prod, admin IAM | 5-15 minutos; revogar no fim da ferramenta |
| Leitura / staging | Réplicas de leitura, APIs de tickets | 30-60 minutos |
| Chave de fornecedor LLM | Chave org OpenAI / Anthropic | Gerida pelo Vault; rotação agendada; nunca no JSON do MCP |
4.4 Vault + atribuição de utilizador (validated pattern)
Validated pattern da HashiCorp: o utilizador autentica-se; o agente recebe um token on-behalf-of (OBO); as ferramentas autenticam-se no Vault com JWT; o Vault mapeia claims para policies e emite segredos dinâmicos com âmbito limitado. As pistas de auditoria ligam a emissão do segredo ao humano, não a uma conta robot partilhada.
O Vault Enterprise adiciona Agent Registry e perfis de OAuth resource server para que agentes inscritos apresentem JWTs OAuth sem um passo de login Vault separado — com restrições específicas do agente para delegação / OBO.
# Conceptual agent tool hook (do not ship secrets to the model)
vault_token = login_jwt(obo_token) # Vault auth
secret = vault.read("database/creds/agent-ro")
lease_id, ttl = secret["lease_id"], secret["lease_duration"]
try:
run_tool(db_url=secret["data"]) # use within TTL
finally:
vault.lease.revoke(lease_id) # or let TTL expire
5. Configurações recomendadas por fornecedor
5.1 Claude (Anthropic)
- Prefira OAuth para conectores MCP remotos; devolva 401 com
WWW-Authenticatea apontar para PRM para que os clientes descubram a auth. - Nunca coloque tokens/chaves API em query strings de URL do conector (registadas, em cache, proibidas pelas regras de tokens MCP).
- Claude Code: OAuth local com armazenamento seguro de tokens e refresh; plugins não devem ler tokens.
- Claude alojado: credenciais de cliente geridas pela Anthropic para utilizadores que consentem; mesmo assim mantenha os segredos de ferramentas no Vault atrás do seu MCP.
- Empresa: alinhe o IdP com MCP EMA para acesso a servidores zero-touch.
5.2 OpenAI (Agents / tools)
- Separe as chaves API do modelo das credenciais de ferramentas; rotação e raio de explosão diferentes.
- Execute runtimes de agentes em VPC; chame MCP privado sobre rede privada.
- Passe tokens atribuídos ao utilizador às ferramentas; autentique-se no Vault com JWT; emita segredos dinâmicos por invocação.
- Registe cada chamada de ferramenta com user + agent + lease_id para compliance.
5.3 Cursor
- Config do servidor MCP: referencie apenas variáveis de ambiente — nunca hardcode segredos em
mcp.json. - Servidores STDIO: execute sob Vault Agent (template ou env) para que os leases rotem sem developers copiarem passwords.
- MCP remoto: OAuth quando o servidor o suporte; caso contrário VPN corporativa + bearer de curta duração a partir do Vault.
- Política de equipa: allowlist de servidores MCP aprovados; bloqueie MCPs comunitários não confiáveis em codebases de prod.
- Mantenha
.env/ ficheiros de segredos fora do contexto via regras de ignore; regras do projeto: proibir colar segredos no chat.
6. Matriz de controlos de referência
| Camada | Controlo | Anti-padrão |
|---|---|---|
| Identidade | SSO IdP + EMA / OAuth PKCE | Password robot partilhada |
| MCP | PRM + tokens ligados à audiência | Tokens na URL; sem expiração |
| Rede | VPN / PrivateLink + ACL de egress | MCP público para ferramentas de prod |
| Segredos | Lease Vault + rotação + revogação | Chaves de um ano em mcp.json |
| Ops | Auditoria IdP+MCP+Vault; gates humanos | Deploys / pagamentos de prod sem gate |
7. Checklist de implementação
- Inventarie cada servidor MCP e classifique público vs privado.
- Implemente OAuth 2.1 + PRM em todos os MCP remotos; ative EMA com o IdP corporativo.
- Mova MCP + Vault para trás de VPN/rede privada; documente como Cursor/Claude entram na rede.
- Substitua chaves de ferramentas estáticas por segredos dinâmicos do Vault; defina TTLs por classe de risco.
- Integre Vault Agent (ou renew/revoke do SDK) nos runtimes de agentes; revogue leases no fim da sessão.
- Separe as chaves de fornecedores LLM; armazene-as e rode-as no Vault — nunca em prompts ou na config MCP.
- Adicione gates de aprovação humana para dinheiro, alterações de identidade e deploys em produção.
- Teste: lease expirado falha em fail-closed; token de audiência errada rejeitado; caminho público bloqueado.
Publicado por Workstation — automatização empresarial, plataformas multiagente e entrega segura em Kubernetes.