Agent Identity and Delegated Authorization: OAuth Patterns for Agentic Actions

When an AI agent books a calendar event, sends an email, or submits a form, it isn't acting on its own identity — it's acting under delegated authority from a human who said "go do this." That distinction sounds philosophical until an agent leaks sensitive data, takes an irreversible action the user didn't intend, or gets compromised. At that point, the question isn't what happened but who authorized it, when, and can we revoke it.

The blast radius of poorly scoped agent credentials is larger than most teams realize. An agent authenticated with broad API access isn't one point of failure — it's a standing invitation. In 2025, agentic AI CVE counts jumped 255% year-over-year, and most incidents traced back to credentials that were too broad, too long-lived, or impossible to revoke cleanly. Building agents right means designing the authorization layer before you hit production.

What "Acting on Behalf Of" Actually Requires

Traditional OAuth assumes a human user who grants an application access to their resources. When an AI agent enters that chain, you have a more complex principal hierarchy: the user who delegated authority, the agent process executing the task, the token that proves authorization, and potentially a chain of sub-agents that each received narrower delegations from the parent.

RFC 8693 (OAuth 2.0 Token Exchange) formalizes the semantics here. The "On-Behalf-Of" (OBO) flow creates tokens where:

• The sub claim identifies the user who delegated authority
• The act claim identifies the agent performing the action

Both identities are encoded in every token. This dual-identity structure is the foundation of attribution — without it, you cannot answer "who authorized this action" after the fact. Every agent action, logged against a token that only has a service account subject, is attribution debt.

Active IETF standardization is catching up to these requirements. The draft extension for AI agents introduces requested_actor and actor_token parameters to the OAuth 2.0 authorization request, letting the authorization server issue tokens that explicitly encode the agent's identity alongside the delegating user. Combined with the MCP authorization specification (which makes OAuth 2.1 mandatory), this is rapidly converging on a coherent standard — but you need to design for dual identity now, not when the RFCs finalize.

Scope Design: The Problem with Designing in Advance

For human users, least privilege is about limiting what they can do in the system. For agents, the challenge is different: agents reason and adapt at runtime, which means the same agent might read data in one execution and write in another depending on goals and intermediate results. Traditional least privilege assumes access is "designed in advance." Agents break that assumption.

The solution is per-operation scoping rather than per-agent scoping. Instead of granting an agent calendar:all or email:all, define scopes at the action level:

• calendar:create_event — can create but not read existing events
• email:send — can send but not read the inbox
• drive:write:folder/reports — write access scoped to a specific path

When an agent attempts an operation that requires elevated scope, the server returns an HTTP 403 with a WWW-Authenticate header identifying the required scope. This is the step-up authorization pattern: instead of silently failing or broadly authorizing upfront, the system surfaces the constraint at the point of need and triggers explicit user consent if the scope is worth granting.

There's another structural requirement here: delegation contracts narrow, they don't expand. If a parent orchestrator agent has read+write access and spawns a sub-agent to perform a subtask, the sub-agent can only receive a subset of the parent's scopes — never more. This prevents capability laundering, where a minimally-scoped agent delegation somehow accumulates permissions the chain was never supposed to have.

Credential Lifecycle: Event-Driven, Not Calendar-Based

Agent tokens that live forever are the enemy. The longer a credential exists, the more likely it is to be present in a log, rotated through a compromised environment, or still active when the user has long since changed their intent.

The right lifecycle model for agent credentials is:

• Short-lived by default: 5–15 minute token lifetimes for most agentic actions. Agents operate in short task windows; there's no reason for credentials to outlive the task.
• Just-in-time provisioning: The credential for a specific operation is injected only when needed and expires immediately after. An agent writing a calendar event doesn't hold email credentials while doing so.
• Event-driven rotation, not calendar-driven: Rotate on deployment updates, configuration changes, scope modifications, or capability expansion (new tools added to the agent). Calendar-based rotation creates a window where both the old and new credentials coexist unnecessarily.

The failure mode this prevents is subtle: teams often assume that because an agent's token was issued correctly last month, the authorization model is still valid. But capability expansion without privilege review is how agents accumulate standing access over time. Every new tool added to an agent is a potential scope expansion that bypasses the original authorization review.

When you combine short token lifetimes with refresh token rotation (required by OAuth 2.1 for public clients), you get a secondary security property: refresh token reuse by an attacker is immediately detectable, because the authorization server sees a previously-seen refresh token and invalidates the entire grant.

Revocation: You Need It to Work Instantly

Revocation is where authorization systems either hold up or fall apart. There are three principal parties who may need to revoke an agent's access:

• The user who delegated authority (they changed their mind, or the agent misbehaved)
• The security team (incident response, policy violation detected)
• The provider (suspicious activity, security breach)

The architecture requirement is centralized token validation. Every agent action must validate its token against a single authorization server, not against a local cache or distributed credential store. When revocation happens, it propagates immediately because there's one source of truth.

The "user revokes agent access" flow should look like standard OAuth "Connected Apps" management — the user sees what the agent can do, clicks disconnect, and the token is immediately invalid. No delay, no manual cleanup, no waiting for the next rotation cycle.

For policy-triggered revocation (the agent exceeded its authority, anomalous behavior detected), you need the same instant path. A real-time anomaly detection layer should monitor for:

• Unusual data volume (the agent is exporting far more records than the task warrants)
• Off-hours activity (automation running when the delegating user isn't active)
• Scope escalation requests (the agent is asking for permissions it hasn't needed before)

When any of these tripwires fire, revoke immediately. The cost of an incorrect revocation is a user has to re-authorize. The cost of a missed revocation is the data exfiltration you didn't catch.

Audit Trails: Logging for Attribution, Not Just Compliance

Audit trails for agent actions are more complex than for human user actions because a single agent action involves multiple principals. Consider an agent that sends an email on a user's behalf:

• Who triggered the action? (the user who said "send this")
• Who executed the code? (the agent process)
• Whose credentials performed the API call? (the OAuth token subject)
• Who deployed and manages the agent? (the organization)

A log that only records the OAuth token subject misses the triggering user. A log that only records the agent process misses the credential used. A complete audit trail captures all four.

The practical pattern is a connection ID as the join key:

• The authorization server tracks OAuth connections, token issuance, scope grants, and revocation timestamps
• The application logs agent-side events (what action was requested, what data was accessed, what the result was) with the connection ID as a foreign key
• Compliance audits join these two logs to reconstruct the full authorization chain

This matters for the four compliance frameworks that appear most often in enterprise deployments:

• SOC 2 CC6.1 requires attribution to authorized principals — dual-identity logging satisfies this
• SOC 2 CC6.2 requires access removal with revocation timestamps — the authorization server log provides this
• GDPR Article 7(3) requires revocation capability with evidence — the connection lifecycle log is this evidence
• HIPAA requires 6-year ePHI log retention for any agent touching health data

Beyond compliance, audit trails are how you understand agent behavior after something goes wrong. The "reconciliation agent exfiltration" failure mode — where an agent is tricked into exporting all records matching a pattern — is only diagnosable after the fact if you have complete action logs. Without them, you know data left the system but not how it was authorized.

Connecting to MCP: The Emerging Standard

The Model Context Protocol authorization specification is rapidly becoming the canonical reference for how agents connect to external services. Its authorization model is worth understanding directly:

• OAuth 2.1 is mandatory (not optional) for MCP implementations
• Tokens must be bound to a specific MCP server via resource indicators (RFC 8707) — an MCP server rejects tokens not explicitly issued for it
• Token passthrough is explicitly forbidden — an MCP server acting as a proxy to an upstream API must obtain fresh credentials for that API, not forward the client's token
• Servers advertise their authorization requirements via well-known URIs (RFC 9728), enabling dynamic client registration without pre-established relationships

That last point is architecturally significant. Traditional OAuth assumes clients are registered with the authorization server ahead of time. MCP's use of URL-based client identifiers (the client's metadata is fetched from a URL rather than pre-registered) enables the zero-trust pattern: any MCP client can connect to any MCP server, and trust is established dynamically through the authorization server, not through out-of-band coordination.

The practical implication: if you're building an agent that connects to MCP servers, you need an OAuth 2.1 client that supports dynamic server metadata discovery, resource indicators in token requests, and per-server token binding. Generic OAuth libraries work, but require careful configuration to hit all of these requirements.

A Minimum Viable Authorization Architecture

For teams getting this right for the first time, the components are:

Identity layer: Each agent gets its own service account with a unique identifier. No shared credentials across agents. This is non-negotiable for attribution.

Authorization server: A centralized server (Auth0, Okta, WorkOS, or self-hosted) that issues short-lived tokens, validates them on every request, and maintains the revocation list. Distributed token validation defeats instant revocation.

Scope registry: A machine-readable catalog of available scopes, which agents can request which scopes, and what step-up authorization is required for elevated operations.

Delegation chain enforcement: Parent agents cannot grant child agents scopes they don't hold themselves. The authorization server enforces this at token exchange time, not via application logic.

Dual-identity logging: Every token carries both sub (delegating user) and act (executing agent) claims. Every log entry captures both.

Revocation UI: Users can see what agents are authorized to act on their behalf and revoke that authorization in one click. This is a product requirement, not just a compliance checkbox.

This is more infrastructure than most teams build for their first agent. The temptation is to start with API keys and long-lived service tokens because they're easier to implement. That's fine as a prototype, but it's technical debt that's expensive to unwind once agents are in production — because the audit trail you didn't build is gone, and the credentials you didn't scope properly have already touched real data.

Authorization isn't the interesting part of building agents. But it's the part that determines whether you can operate them safely at scale — and right now, with agentic AI moving from prototype to production, getting the authorization model right from the start is the highest-leverage thing you can do.