OAuth for AI agents exposes the limits of static API keys

At a glance

What this is: This is an analysis of how OAuth should be used for AI agents, with the key finding that static API keys are a poor fit and delegated, scoped, revocable tokens are the baseline.

Why it matters: It matters because IAM teams now have to govern agents that act on behalf of users and services, and that changes how you scope, revoke, audit, and layer authorisation across human and non-human identities.

By the numbers:

• 28,65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• Internal repositories are 6x more likely to contain secrets than public ones, with 32.2% versus 5.6%, contradicting the assumption that private repos are safe.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read Ory's analysis of OAuth for AI agents and delegated access

Context

AI agent OAuth is about delegated identity, not just authentication. The core problem is that agents can act independently at runtime while still needing constrained access to user and service resources, which makes static API keys and broad, long-lived permissions a poor fit for identity governance.

The article argues that OAuth is the right baseline for AI agents because it provides scoped, revocable tokens, but it also shows where OAuth stops: coarse-grained delegation is not the same as fine-grained runtime authorisation. That distinction matters for IAM, PAM, and NHI governance because the control question is no longer only who can sign in, but what an agent can do once it has a token.

For agentic AI programmes, the operational challenge is not adopting a new protocol for its own sake. It is deciding how to express least privilege, revocation, audience binding, and approval gates when the identity subject is an agent that can create new intent while executing a task.

Key questions

Q: How should security teams govern AI agents that use OAuth access?

A: Security teams should inventory each agent, limit scopes to the minimum required, assign an owner, and monitor its behaviour continuously. They should also define revocation steps before an incident occurs, because delegated OAuth access can become a lateral-movement path when an agent is compromised. Governance should cover discovery, approval, review, and offboarding as a single control loop.

Q: Why do service accounts and AI agents create different identity risk than employees?

A: Service accounts and AI agents create different risk because they are not managed through HR lifecycle events, yet they often hold broad technical permissions and can act at machine speed. That makes ownership, monitoring, and revocation harder to sustain with human-centric controls. Risk rises when their access is persistent, poorly documented, or spread across multiple platforms.

Q: What breaks when AI agents rely on static OAuth scopes for MCP access?

A: Static OAuth scopes break because they describe delegated permission at the moment of issuance, not the live intent behind each agent action. In MCP, the agent can chain tool calls, change context, and trigger downstream effects that were never visible when the scope was granted. Security teams need per-action authorization, not just valid authentication.

Q: Who is accountable when an AI agent uses delegated access incorrectly?

A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.

Technical breakdown

OAuth token delegation for AI agents

OAuth gives an agent a token that proves delegated authority without exposing the user’s password or a raw API key. In agent deployments, that delegation can happen through authorization code with PKCE, client credentials, token exchange, or device authorization, depending on whether the agent is user-facing, background, on-behalf-of, or headless. The important architectural point is that OAuth handles who is allowed to act, but only at the token boundary. It does not decide whether a specific tool call, resource lookup, or downstream action is appropriate in the moment.

Practical implication: Treat OAuth as the delegation layer and pair it with separate runtime policy checks for sensitive actions.

Scopes, claims, and audience binding in agent identity

Scopes define the broad permission set, claims add traceability, and audience binding keeps a token usable only against the intended resource server. For AI agents, those three pieces matter because the same token can otherwise be reused across multiple tools or downstream services, creating unnecessary blast radius. Short-lived tokens and revocation endpoints reduce exposure further, but only if claims such as agent_id, task_id, or session_id are carried through the call chain. Without that traceability, incident response and audit become guesswork.

Practical implication: Map scopes to existing RBAC or ABAC models, bind tokens to a single audience, and require agent and task claims in every access token.

Why OAuth falls short without fine-grained authorisation

OAuth is not a row-level policy engine. It cannot evaluate conversation context, relationship-based access, or whether a request is reasonable given the task in progress. That gap becomes visible when an agent must choose between many valid actions, or when prompt injection tries to steer a valid token toward an invalid outcome. In practice, OAuth answers whether the token is real and scoped. A policy engine answers whether the exact action on the exact resource should be allowed right now.

Practical implication: Add Zanzibar-style or equivalent fine-grained authorisation for runtime decisions that scopes cannot express.

Threat narrative

Attacker objective: The objective is to make a legitimate agent use its valid access in ways the user or operator never intended, turning delegated authority into data exfiltration or unauthorised action.

1. Entry occurs when an AI agent receives delegated access through OAuth rather than a static shared secret, which reduces credential exposure but still creates a valid token boundary for abuse.
2. Escalation happens when prompt injection or confused-deputy behaviour turns a legitimate token into an instrument for unintended API calls, data access, or tool misuse.
3. Impact is reached when a scoped agent is allowed to chain actions across tools or services without a separate runtime policy check, expanding the blast radius of one compromised reasoning step.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static API keys are the wrong baseline for AI agents: they assume the identity subject is predictable, re-usable, and safe to expose as a long-lived secret. AI agents generate new intent at runtime, so a key that never expires gives an attacker or compromised prompt a durable execution path. The implication is that agent identity governance has to move away from shared secrets as a default pattern.

OAuth solves delegation, not authorisation completeness: the protocol answers who can act and under what coarse scope, but it does not answer whether a particular tool call is appropriate right now. That is why agent IAM must layer policy evaluation on top of token issuance. Organisations that stop at scopes have improved authentication hygiene but still leave runtime abuse paths open.

Fine-grained authorisation is the missing control plane for agentic AI: row-level, relationship-based, and context-aware decisions are where agent risk becomes operationally governable. Scopes, claims, and audience binding reduce blast radius, but they do not replace contextual policy enforcement. Practitioners should treat OAuth as necessary plumbing, not as the full trust model.

Agent identity is neither user identity nor machine identity: a cron job repeats a predefined action, while an agent can choose the next action, the next tool, and the next call sequence. That distinction means existing IAM categories blur once the actor can generate intent autonomously within a session. The right governance question is not whether the agent is authenticated, but whether its delegated authority remains bounded as its behaviour changes.

From our research:

• DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• The control lesson carries forward into OWASP NHI Top 10, where identity and privilege abuse sit alongside prompt-injection and tool-misuse risks.

What this signals

Ephemeral delegation, not permanent access, is becoming the default design requirement for AI agents. As organisations move agents from demos into production, the question is no longer whether OAuth is available, but whether the surrounding IAM model can enforce short-lived, audienced, and revocable access at the same speed as the agent’s decisions. Teams that keep static credentials in the path will inherit avoidable blast radius.

Runtime policy is where agent identity governance becomes real. OAuth scopes can define coarse intent, but only policy engines and approval gates can stop an authorised agent from taking an unsafe branch at execution time. That means IAM, PAM, and application security teams need a shared control model instead of treating agent access as a pure authentication problem.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the governance issue extends beyond token issuance into the tool layer. Agentic programmes should expect identity risk to follow the integration surface, not just the model layer, which makes audience binding and lifecycle control part of the same programme.

For practitioners

• Replace static agent secrets with delegated tokens Move AI agents off long-lived API keys and onto short-lived OAuth tokens wherever the workflow allows. Keep revocation available at the token issuer and make expiry measured in minutes rather than hours for high-risk actions.
• Bind each token to one resource audience Set aud claims so a token issued for one MCP server or API cannot be replayed against another service. This reduces cross-tool misuse when an agent is tricked into calling an unintended endpoint.
• Require agent and task claims in every token Add agent_id, task_id, and session_id claims so every downstream action can be traced to a specific actor and purpose. That traceability is essential when an investigation needs to reconstruct what the agent did and why.
• Layer runtime policy over OAuth scopes Use a policy engine for row-level and context-aware decisions, especially for deletions, sharing, payments, and cross-system writes. OAuth should establish delegated access, while policy should decide whether the specific action is acceptable.
• Add human approval gates for high-risk actions Trigger step-up confirmation when an agent crosses into sensitive operations such as external sharing, fund movement, or irreversible deletion. This limits damage when prompt injection changes the agent’s reasoning mid-session.

Key takeaways

• AI agents should not be governed with static API keys because their runtime behaviour makes long-lived shared secrets too easy to abuse.
• OAuth is the right delegation layer for agents, but scopes alone do not provide the fine-grained, contextual authorisation needed for safe operation.
• Security teams need short-lived tokens, audience binding, and separate runtime policy before agent identity can be treated as governable at scale.

Key terms

• Delegated Access Token: A delegated access token is a short-lived credential issued for a specific task on behalf of an identity. In agentic environments, it limits what the runtime can do, where it can go, and how long the authority lasts, which is essential when access must be brokered rather than carried.
• Audience Binding: A control that limits a token to a specific downstream resource or service. It prevents credential replay across tools and keeps delegated access aligned to the exact action the system was allowed to perform.
• Fine-Grained Authorization: Fine-grained authorization is access control that evaluates specific resources, actions, and context rather than granting broad application-level permission. For AI agents, this is the difference between merely connecting to a system and being limited to the exact data or action the task requires.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.

What's in the full article

Ory's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of which OAuth flow fits each agent pattern, including user-delegated, autonomous, on-behalf-of, and headless scenarios.
• Implementation guidance for scopes, claims, audience binding, and revocation in agentic architectures.
• The article’s view of how OAuth fits alongside fine-grained authorisation for runtime policy decisions.
• Additional context on MCP server authorisation patterns and token exchange in agent-to-agent calls.

👉 The full Ory article covers OAuth flows, token design, and where fine-grained authorisation must take over.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.