Pular para conteúdo

Capítulo 4.8 — Agent identity e delegated authorization

🎯 Objetivo

Tratar agentes como identidades de primeira classe em sistemas corporativos, com mecanismos explícitos para delegação, escopos mínimos, rotação e auditoria.

🧠 Princípios

  • Cada agente tem identidade própria (não usa credencial humana compartilhada).
  • Quando atua em nome de usuário, há delegação explícita (on-behalf-of).
  • Credenciais são curtas e rotacionadas.
  • Escopos são mínimos e por capability.
  • Todo uso é auditável.

🧠 Padrões e flows

  • Service account / workload identity para identidade do agente em ambientes cloud (Kubernetes ServiceAccount + projected tokens, AWS IAM Roles for Service Accounts, GCP Workload Identity Federation, Azure Managed Identities).
  • OAuth 2.0 + OIDC para autorização. Os agentes não inventam identidade; recebem tokens emitidos por IdP.
  • Authorization Code with PKCE (RFC 7636) para apps interativos onde o usuário consente.
  • OAuth 2.0 Token Exchange (RFC 8693) para troca de tokens em delegação (on-behalf-of) e impersonation controlada.
  • OAuth 2.0 Device Authorization Grant (RFC 8628) para agentes em ambientes sem browser que precisam de consent do usuário.
  • Client credentials com escopos mínimos para chamadas service-to-service.
  • OAuth 2.0 Security Best Current Practice (RFC 9700) - referência obrigatória para hardenings recentes (PKCE para todos, refresh tokens rotativos, evitar implicit flow etc.).

🧩 MCP Authorization

A spec do MCP define autorização baseada em OAuth 2.0, com Authorization Server descoberto via metadata. Conceitos principais:

  • O MCP server é um resource server; clients são OAuth clients.
  • Discovery do Authorization Server via /.well-known/oauth-authorization-server ou metadata equivalente.
  • Token exchange e PKCE são esperados; client credentials são suportadas para chamadas de máquina.
  • Scopes mapeiam capabilities (tools/resources/prompts) do server.

Maturidade. A spec de autorização do MCP está em evolução; verifique a versão da spec correspondente à sua implementação e ao seu SDK.

🛡️ Padrões recomendados em produção

Cenário Padrão preferencial
Agente service-to-service Workload identity + client credentials com escopo mínimo
Agente atuando em nome de usuário Authorization Code + PKCE + Token Exchange (OBO)
Agente em CLI/edge sem browser Device Authorization Grant
Acesso a MCP server externo Discovery + PKCE + scopes mapeados a capabilities
Acesso a recursos sensíveis Token de curta duração + refresh rotativo + audit obrigatório

🚨 Modos de falha

  • Agente reusando credencial humana ou token amplo (admin).
  • Tokens de longa duração sem rotação.
  • Falta de associação entre tool call e usuário origem (rompe audit trail).
  • Implicit flow ou flows desencorajados pela RFC 9700.
  • Escopo "scope=*" porque é "mais fácil".
  • MCP server aceitando token sem validar audience.

📈 Métricas

  • Taxa de tokens com escopo mínimo vs amplo.
  • Idade média e percentil dos tokens em circulação.
  • Rotação efetiva (rotated/expired ratio).
  • Tentativas de uso com escopo insuficiente.
  • Falhas de delegação por motivo.

📌 Checklist

  • [ ] Cada agente tem identidade própria gerenciada pelo IdP?
  • [ ] Delegação on-behalf-of usa Token Exchange (RFC 8693)?
  • [ ] PKCE habilitado em todos os flows interativos?
  • [ ] Tokens são curtos com refresh rotativo?
  • [ ] Escopos mapeados a capabilities, não a "admin geral"?
  • [ ] Audit log liga ação executada -> token -> usuário origem?

📚 Referências