OAuth Was Designed for Humans at Keyboards
OAuth 2.0 was built around a specific mental model: a human sits at a browser, clicks "Authorize," reviews the requested permissions, and grants a third-party app limited access to their account. The authorization is intentional, visible, and bounded. The human can revoke it. The session ends when the user closes the tab.
AI agents break every assumption in that model. The agent acts autonomously, often across long-running sessions. It may request tokens without the user observing which scopes are being requested. It stores credentials to re-use across tasks. It may delegate further to sub-agents. The "authorize and forget" pattern that works acceptably for a connected app becomes a liability when the authorized party is an autonomous agent with tool access.
The result is a growing class of authorization vulnerabilities that security teams haven't fully mapped yet, because the threat model for agentic AI is still being written in real time.
The Token Lifecycle Problem
In a standard OAuth flow, access tokens are short-lived (typically 1 hour) and refresh tokens allow renewal without re-prompting the user. This design assumes the authorized client is a bounded, auditable application. With AI agents, the authorized client is a reasoning system that can decide to use its credentials in ways that weren't anticipated at authorization time.
An agent authorized for a one-time task ("summarize my emails from last week") may store the refresh token indefinitely. The user forgets the authorization exists. Months later, the token is still valid. If the agent deployment is compromised, the attacker inherits long-term, silent access to the user's Gmail, Calendar, and Drive — without triggering any re-authorization prompt.
Agents that handle multiple tasks over time may request progressively broader scopes. An agent that starts with read-only calendar access may later request write access, then contacts, then email — each individually justified by a specific task. No single authorization event looks alarming. The cumulative scope, held in a single token set, represents full account access.
# Scope accumulation over a multi-week agent engagement Week 1: calendar.readonly # "check my schedule" Week 2: calendar.events # "book this meeting" Week 3: contacts.readonly # "who is this person?" Week 4: gmail.readonly # "find that email thread" Week 5: gmail.send # "reply to this for me" Week 6: drive.file # "attach this document" ------------------------------------------------------ Result: effective full Google Workspace access, accumulated across 6 low-friction auth prompts
Agent-to-Agent Token Delegation
Multi-agent architectures introduce a delegation problem that OAuth's token model handles poorly. When a primary agent spawns a sub-agent to complete part of a task, it may pass its own access token to the sub-agent. The sub-agent, which may be less trusted, less hardened, or running in a different environment, now has the same credentials as the primary agent.
OAuth has a token exchange specification (RFC 8693) designed for delegation scenarios, but it requires deliberate implementation. Most agentic frameworks today use ad-hoc token passing — the simplest approach that works, and the one with the worst security properties. A compromised sub-agent with a delegated token is indistinguishable from the authorized primary agent from the resource server's perspective.
# How token delegation typically works today (insecure) primary_agent.tools = [gmail_tool, calendar_tool, file_tool] primary_agent.token = user_oauth_token # full scope # Agent spawns specialist sub-agents, passes token directly email_agent = SubAgent(token=primary_agent.token) file_agent = SubAgent(token=primary_agent.token) # Each sub-agent now has the same privileges as the user # Compromise any sub-agent = compromise the user's account
MCP Servers as OAuth Credential Stores
MCP servers that connect to external services (Google Workspace, GitHub, Slack, Notion) typically store OAuth credentials in their configuration — either as long-lived tokens or as app credentials that can generate tokens on demand. The MCP server becomes a credential aggregation point: one compromise yields access to every connected service.
The attack surface is compounded by the fact that MCP servers are often run locally (stdio transport) with minimal authentication. A malicious process on the same machine, or an indirect prompt injection that reaches the file tool, can read the MCP configuration file and extract credentials for every connected service.
| Compromise Scenario | What the Attacker Gets |
|---|---|
| MCP config file read via path traversal | All OAuth tokens for all connected services |
| Indirect injection → agent reads ~/.config/mcp | Token exfiltration without any UI interaction |
| Malicious npm package in agent dependencies | Environment variable harvest including OAUTH_TOKEN |
| Compromised sub-agent with delegated token | Full scope of primary agent's authorization |
What Secure Agent Authorization Looks Like
Fixing this requires rethinking the authorization model for agents at the architecture level, not just patching individual implementations. Several principles apply.
Generate a new, minimally-scoped token for each agent task. When the task completes, revoke it. The token should carry only the permissions required for that specific task — not the agent's full scope accumulation. This requires the authorization server to support dynamic, short-lived token issuance, which major providers (Google, Microsoft, GitHub) do support but most agent frameworks don't take advantage of.
Use Demonstrating Proof of Possession (DPoP, RFC 9449) or mTLS token binding to tie tokens to a specific agent's cryptographic identity. A stolen token is useless without the private key. This prevents token exfiltration attacks — even if the token is extracted from MCP config or environment variables, it cannot be used from a different process.
Use OAuth token exchange (RFC 8693) when delegating to sub-agents. The primary agent exchanges its token for a narrower-scoped token specific to the sub-task, rather than passing its own token directly. The exchange creates an audit trail and ensures sub-agents can't exceed the scope they were delegated.
Surface all active agent authorizations to users in a single, auditable view. Users should be able to see which agents hold tokens, what scopes they have, and when they were last used — and revoke any of them with one click. Most OAuth providers offer token management pages; agent platforms should surface this information prominently rather than burying it in settings.
The Regulatory Horizon
Agent-held OAuth tokens are increasingly in scope for data protection regulation. If an AI agent holds a refresh token granting access to a user's email and calendar, that agent is effectively a data processor with long-term access to personal data. GDPR's data minimization principle and purpose limitation requirements apply — and most current agent deployments would struggle to demonstrate compliance.
The EU AI Act, now entering enforcement phase, adds further requirements around transparency and human oversight for high-risk AI systems. An agent that autonomously acts on behalf of users using long-lived credentials, with no visible audit trail, sits uncomfortably close to the high-risk category in several sector definitions.
The teams building agentic products today are accumulating regulatory debt at the same time as they accumulate security debt. The authorization model needs to be rebuilt for agents — not because it would be nice to have, but because the alternative is a wave of incidents that regulators will use to define the space for everyone.