Delegated access for agents: OAuth 2.1, PKCE and scoped tokens

The question that ends most agent pilots in security review is short: on whose behalf is this agent acting, and with what rights? In the demo, the answer is usually "an admin API key in an environment variable". In production, that answer gets the project stopped, and it should.

The good news is that the standards have settled. The Model Context Protocol now has a detailed authorization specification built on OAuth, and the pieces it relies on are mature. This post explains the model I use with clients, what the specification requires today, and where credentials actually leak.

The short answer: the agent should act as a delegate of a signed-in user, never as a shared super-user. The user signs in with OAuth 2.1 and PKCE and approves narrow scopes; the agent gets a short-lived token that is bound to one MCP server and can never do more than the user could; the MCP server gets its own token for anything upstream; and every call is logged with both the user and the agent.

Delegation, not impersonation

OAuth's token exchange standard draws the distinction precisely (RFC 8693). With impersonation, A is B within the rights of the token: nobody downstream can tell them apart. With delegation, A keeps its own identity separate from B, and acts as B's agent. The standard even has a claim for it: act names the party acting on someone's behalf, and nested act claims record a chain of delegation.

For agents this is not academic. If the agent impersonates the user, your audit log says the user deleted the invoice. If it acts as a delegate, the log says the agent deleted it on the user's behalf, which is what you need when something goes wrong. It also lets you give the agent less than the user has: read access to invoices, say, while the user can also approve them.

Who holds which token

The current MCP specification separates the roles cleanly. Each arrow below is a token or a consent, and no token crosses more than one boundary:

What the MCP specification requires today

Authorization is optional in MCP, and local servers that run over standard input take credentials from the environment. But a remote server over HTTP that implements authorization has to follow the specification, which has tightened with every revision (the latest changes are tracked in MCP specification changes, explained):

Three requirements do most of the security work:

• Resource indicators and audience checks. The client names the exact MCP server when it asks for a token, and the server rejects tokens issued for anyone else. A token stolen from one tool server is useless against the next.
• No token passthrough. The specification states that the MCP server must not pass the client's token through to upstream APIs; it needs its own token from the upstream authorization server. Its security best practices explain why: passthrough bypasses the upstream system's controls and breaks the audit trail.
• Scope challenges and step-up. The server says which scopes an operation needs, and when a call fails for lack of scope the client can ask the user for more. Agents start with the minimum and earn the rest.

OAuth 2.1 in one paragraph

OAuth 2.1 is still an IETF draft, now at revision 16 from September 2026 (draft-ietf-oauth-v2-1), but MCP has required it since its first authorization revision. It folds a decade of security advice into the core: PKCE is mandatory by default for every client, with a narrow exception for some confidential clients, and the weak plain method is prohibited; the implicit and password grants are gone; redirect addresses must match exactly; bearer tokens may not travel in URLs; and refresh tokens for public clients must be sender-bound or single-use. For agents, which often run as public clients on a laptop or in a browser, these are exactly the protections that matter.

Scopes: start small, step up

The MCP security guidance recommends a progressive, least-privilege scope model and names wildcard or all-in-one scopes as a common mistake. OWASP's Excessive Agency entry lists excessive permissions as one of three root causes of agent incidents, and its Top 10 for Agentic Applications treats identity and privilege abuse as a category of its own.

In practice I design scopes around capabilities, not systems:

• Read and write apart. content:read and content:write, invoices:read and invoices:approve. An agent that summarises never needs write.
• Destructive actions separate. Deleting, sending and paying get their own scopes, and the client asks the user before using them.
• Tools follow scopes. Since July 2026 a server may list only the tools the caller's scopes allow, so the agent never sees what it cannot use. That also helps accuracy; see MCP server best practices for tool design.
• Role checks on the server. A scope is a ceiling, not a grant. The server still checks what this user may do with this record.
• Short-lived tokens. Minutes to hours, refreshed with sender-bound refresh tokens, revoked when the user leaves.

Where credentials actually leak

Most agent credential problems I see are not exotic attacks but keys in files. GitGuardian's 2026 report counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34%, with secrets for AI services up 81% to 1.28 million (GitGuardian, March 2026). It found 24,008 unique secrets in MCP configuration files alone, 2,117 of them still valid, and noted that popular MCP setup guides tell users to paste API keys into configuration files or command-line arguments. And remediation is slow: most secrets confirmed valid in 2022 were still valid in January 2026.

Delegated OAuth removes the long-lived key from the laptop entirely. Where a static key is unavoidable, for a local server or a machine-to-machine integration, keep it in a secrets manager, scope it to one system, and rotate it on a schedule.

Broad credentials are also what turned prompt injection into data leaks in the published GitHub and Supabase MCP incidents, covered in AI agent architecture: from demo to production.

The delegated access checklist

How much weight this evidence deserves

Sources

• Model Context Protocol specification, version 2026-07-28: Authorization.
• Model Context Protocol changelog, 2025-06-18.
• Model Context Protocol changelog, 2025-11-25.
• Model Context Protocol changelog, 2026-07-28.
• Model Context Protocol: Security best practices.
• Model Context Protocol specification, version 2026-07-28: Tools.
• Jones et al. (2020). RFC 8693: OAuth 2.0 Token Exchange.
• Hardt, Parecki and Lodderstedt. The OAuth 2.1 Authorization Framework, draft-ietf-oauth-v2-1-16 (September 2026).
• GitGuardian (March 2026). The State of Secrets Sprawl 2026.
• OWASP (2025). LLM06:2025 Excessive Agency.
• OWASP (December 2025). Top 10 for Agentic Applications for 2026.