Skip to content

Chapter 4.8 — Agent identity and delegated authorization

🎯 Objective

Treat agents as first-class identities in corporate systems, with explicit mechanisms for delegation, minimal scopes, rotation and auditing.

🧠 Principles

  • Each agent has its own identity (it does not use a shared human credential).
  • When it acts on behalf of a user, there is explicit delegation (on-behalf-of).
  • Credentials are short-lived and rotated.
  • Scopes are minimal and per capability.
  • All usage is auditable.

🧠 Patterns and flows

  • Service account / workload identity for the agent's identity in cloud environments (Kubernetes ServiceAccount + projected tokens, AWS IAM Roles for Service Accounts, GCP Workload Identity Federation, Azure Managed Identities).
  • OAuth 2.0 + OIDC for authorization. Agents do not invent identity; they receive tokens issued by an IdP.
  • Authorization Code with PKCE (RFC 7636) for interactive apps where the user consents.
  • OAuth 2.0 Token Exchange (RFC 8693) for token exchange in delegation (on-behalf-of) and controlled impersonation.
  • OAuth 2.0 Device Authorization Grant (RFC 8628) for agents in browserless environments that need user consent.
  • Client credentials with minimal scopes for service-to-service calls.
  • OAuth 2.0 Security Best Current Practice (RFC 9700) — a mandatory reference for recent hardenings (PKCE for all, rotating refresh tokens, avoiding the implicit flow, etc.).

🧩 MCP Authorization

The MCP spec defines authorization based on OAuth 2.0, with an Authorization Server discovered via metadata. Key concepts:

  • The MCP server is a resource server; clients are OAuth clients.
  • Discovery of the Authorization Server via /.well-known/oauth-authorization-server or equivalent metadata.
  • Token exchange and PKCE are expected; client credentials are supported for machine calls.
  • Scopes map to the server's capabilities (tools/resources/prompts).

Maturity. The MCP authorization spec is evolving; check the spec version matching your implementation and SDK.

Scenario Preferred pattern
Service-to-service agent Workload identity + client credentials with minimal scope
Agent acting on behalf of a user Authorization Code + PKCE + Token Exchange (OBO)
Agent in CLI/edge without a browser Device Authorization Grant
Access to an external MCP server Discovery + PKCE + scopes mapped to capabilities
Access to sensitive resources Short-lived token + rotating refresh + mandatory audit

🚨 Failure modes

  • An agent reusing a human credential or a broad (admin) token.
  • Long-lived tokens without rotation.
  • A missing association between a tool call and the originating user (breaks the audit trail).
  • The implicit flow or flows discouraged by RFC 9700.
  • scope=* because it is "easier".
  • An MCP server accepting a token without validating the audience.

📈 Metrics

  • Rate of tokens with minimal vs broad scope.
  • Average age and percentile of tokens in circulation.
  • Effective rotation (rotated/expired ratio).
  • Attempts to use with insufficient scope.
  • Delegation failures by reason.

📌 Checklist

  • [ ] Does each agent have its own identity managed by the IdP?
  • [ ] Does on-behalf-of delegation use Token Exchange (RFC 8693)?
  • [ ] Is PKCE enabled in all interactive flows?
  • [ ] Are tokens short-lived with rotating refresh?
  • [ ] Are scopes mapped to capabilities, not to "general admin"?
  • [ ] Does the audit log link an executed action -> token -> originating user?

📚 References