OAuth gives AI agents delegated, scoped, revocable access. Learn the four flows that fit agents, where OAuth falls short, and how to layer fine-grained authorization on top.
AI agents are making API calls on behalf of your users right now, and most of them are doing it with static API keys that never expire and permissions that were never scoped. This is the same mistake we made with service accounts a decade ago, except agents generate new intent autonomously, which makes over-permissioned access far more dangerous.
OAuth solves this problem. It already handles delegated, scoped, revocable access, which is exactly what agents require. This article walks through how OAuth flows apply to AI agents, how to design scopes and claims for least-privilege access, where OAuth falls short, and how to layer fine-grained authorization on top. The wider Ory take on identity for agentic AI shows how OAuth fits into the broader agent identity stack.
OAuth for AI agents is the security framework that lets autonomous assistants act on behalf of users without ever touching their passwords. Rather than hardcoding static API keys into an agent, OAuth allows the agent to request time-limited, revocable access tokens that carry only the permissions a user explicitly grants.
The principle at the center of this approach is least privilege. An agent receives exactly what it requires for a specific task, nothing more. This matters because AI agents, unlike traditional software, generate new intent on their own. They decide what to do next, which means an over-permissioned agent becomes an unpredictable liability.
AI agent identity occupies its own category. Traditional user identity assumes a human is making decisions in real time. Machine-to-machine identity assumes a pre-configured automation is running a predictable script. Agent identity differs from both because the agent creates new intent rather than simply forwarding a user's request.
This distinction shapes how you design authorization. A cron job calling an API does the same thing every time. An LLM assistant booking a meeting might decide to reschedule three other meetings first, and you probably want to know about that before it happens.
| Identity Type | Who Decides | Token Holder | Example |
|---|---|---|---|
| User Identity | Human user | Browser/app | Logging into Gmail |
| Machine Identity | Pre-configured automation | Backend service | Cron job calling an API |
| AI Agent Identity | Autonomous agent | Agent runtime | LLM assistant booking a meeting |
OAuth already solves the core problem agents face: delegated, scoped, revocable access. There's no reason to invent a new protocol when one already exists that handles constrained permissions without sharing raw credentials.
The fit is natural. Users can grant an agent read-only calendar access without exposing their email. Administrators can cut off agent access at any time. Every token issuance and API call can be logged for audit purposes. For broader OAuth context, our guide on when to use OAuth 2.0 and OpenID Connect covers the core protocol decisions.
Four OAuth flows cover most AI agent scenarios. The right choice depends on whether a user is present and how the agent is deployed.
This flow applies when a user is present and explicitly consents to agent access. The agent prompts the user to log in and approve permissions via a consent screen. PKCE (Proof Key for Code Exchange) protects against interception attacks. That protection matters because agents often run in environments you don't fully control.
This flow applies when no user is present and the agent acts on behalf of an organization or service account. Backend agents running scheduled tasks commonly use client credentials. Think nightly data sync or automated report generation.
This flow applies when an agent already has a user's access token and requires a downscoped or differently-audienced token to call another API. Token exchange follows the IETF Token Exchange specification (RFC 8693). It prevents an agent from carrying more permissions than required for a specific downstream call.
This flow applies when the agent runs on a device with no browser or UI. The user authorizes on a separate device by entering a code. IoT-style agent deployments and CLI-based agent tools commonly use device authorization. For the recent Hydra release that ships first-class agentic authentication via device flow, see the Hydra v25.4 agentic authentication launch.
The On-Behalf-Of pattern, often called OBO, is how an agent proves it's acting for a specific user rather than just itself. The IETF draft-oauth-ai-agents-on-behalf-of-user specification formalizes this pattern for AI agents.
The flow has three steps. First, the user authenticates and consents via the identity provider. Second, the authorization server issues a constrained delegation token to the agent. Third, the agent attaches that token as a Bearer token when calling resource APIs.
The resource server can then verify both who the user is and that the agent is authorized to act on their behalf. This verification creates a clear chain of accountability from user to agent to action. For a real-world example of OBO in action, see enabling the agentic economy with Ory and Skyfire.
Scopes and claims determine what an agent can do and how its actions are traced. Getting this right is the difference between auditable, least-privilege access and uncontrolled agent behavior.
Start with your application's current RBAC or ABAC model. Scopes work best when they mirror what users already can and cannot do. Inventing a parallel permission system just for agents creates confusion and gaps.
Custom claims like agent_id, task_id, or session_id allow resource servers to trace which agent performed which action. This traceability is how you answer "what happened?" after an incident.
The aud claim restricts where a token is valid. A token for Service A shouldn't work against Service B. Audience binding prevents token replay attacks across your infrastructure.
Short-lived access tokens, measured in minutes rather than hours, limit the window of exposure if a token is compromised. Agents rely on refresh tokens for continuity. Revocation endpoints allow immediate cutoff when something goes wrong. For the broader picture, see our guide on token lifecycle management.
Sometimes an agent benefits from pausing and asking before acting. This is consent beyond initial OAuth authorization. It's runtime consent for high-risk operations.
OWASP ranks prompt injection as the number one risk for LLM applications. Human-in-the-loop authorization is one of the few defenses that works even when the agent's reasoning has been compromised by malicious input.
OAuth is not a complete solution. Several threat vectors remain even when OAuth is implemented correctly. Ory's agentic AI security page covers the wider threat model, and agentic AI security with MCP and OAuth goes deeper on the MCP-specific risks.
A confused deputy attack tricks an agent into using its legitimate permissions for illegitimate purposes. The agent becomes an unwitting accomplice. Over-scoped tokens amplify this risk because if the agent has write access to everything, a single prompt injection can cause widespread damage.
Malicious prompts can instruct the agent to use its OAuth token in unintended ways. An attacker might embed instructions in a document that tell the agent to exfiltrate data via an authorized API call. The call looks legitimate because the token is valid. OAuth alone cannot prevent this kind of misuse.
Tokens that outlive user intent create risk. If a user mentally revokes trust but consent persists technically, the agent keeps acting. Short token lifetimes and active revocation mitigate this gap between user intent and system state.
When Agent A calls Agent B calls Agent C, attribution breaks down. Without delegation chain tracking and actor claims, you lose the ability to trace who authorized what. That opacity makes incident response difficult and compliance audits nearly impossible.
OAuth handles authentication and coarse-grained delegation well. It does not solve fine-grained, contextual authorization. Agents often require more than scopes. They require policies that evaluate context at runtime.
Additional authorization layers fill these gaps. Relationship-based access control and policy engines evaluate the specific action, the specific resource, and the specific context before allowing an operation to proceed. For the AI-specific picture, see access controls for AI and LLM systems.
The Model Context Protocol (MCP) is emerging as a standard for agent-to-application communication. OAuth fits naturally into MCP's authorization model.
MCP servers expose tools that agents can call. OAuth protects those tool endpoints. The agent presents a Bearer token to the MCP server before executing any tool, and the server validates the token before responding. For an end-to-end implementation walkthrough, see the MCP server authentication with Ory Hydra integration guide.
RFC 7591 defines dynamic client registration, which allows new agents to onboard without manual client_id provisioning. This automation is how you scale agent deployments without creating a bottleneck of IT tickets for every new agent.
Tokens work best when audience-bound to specific MCP servers. A token for your calendar MCP server shouldn't work against your CRM MCP server. Audience binding prevents cross-tool token replay attacks.
OAuth provides the access token. A policy engine evaluates whether the specific action is allowed. Ory Keto and similar Zanzibar-style systems handle this second layer of authorization.
This layered approach is how you achieve row-level, relationship-based, and contextual authorization for AI agents. OAuth gets you in the door. Fine-grained authorization decides what you can touch once you're inside.
Ory provides identity for agentic AI at the scale teams deploying agents need. Ory Hydra handles OAuth 2.0 and OpenID Connect. Ory Keto provides fine-grained, Zanzibar-style authorization. Both support MCP and emerging standards like the IETF OBO draft.
The platform is open source at its core, with deployment flexibility across self-hosted, SaaS, and hybrid configurations. Token operations run at low latency, which matters when agents are making hundreds of API calls per minute.
Explore Ory's agentic AI IAM solution
No. OAuth handles delegation and coarse-grained scopes. An additional authorization layer is required for fine-grained, contextual decisions and protection against prompt injection.
Distinct client IDs per agent or agent type allow independent auditing, rate-limiting, and revocation. Shared client IDs make it harder to isolate problems.
Machine-to-machine OAuth serves pre-configured automations that do the same thing every time. AI agent OAuth handles dynamic, user-delegated, context-dependent permissions where the agent creates new intent.
Yes, via token exchange flows. Tracking the delegation chain with actor claims is essential for maintaining auditability across multiple agents.
MCP does not mandate a single flow. Authorization code with PKCE and dynamic client registration are common patterns for MCP-based agents.
OAuth isn't a silver bullet for AI agent security, but it's the foundation. Treat tokens as short-lived, scopes as narrow, audiences as bound, and delegation chains as something to track from day one. Layer a policy engine on top for the runtime decisions OAuth was never designed to make. The teams that do this early avoid the kind of agent identity rewrites the rest of the industry is about to spend a lot of time on. For a deeper look at where this lands for CISOs, the Agentic AI Identities webinar covers the readiness gap, and the customer identity and access management hub covers where agent identity fits in the full picture.
