What OAuth Provides

OAuth 2.0 is the industry standard for delegated authorization. It allows a user to grant an application access to their resources on another service without sharing credentials. The user authenticates with the resource server, consents to a set of scopes, and the application receives an access token.

OAuth provides several important capabilities: token-based delegation (the application acts on behalf of the user), scope-based access (the token is limited to specific permissions like email:read or calendar:write), refresh tokens for long-lived sessions without re-authentication, and token revocation when access needs to be withdrawn.

It's a well-understood, battle-tested protocol with broad ecosystem support. Nearly every major API supports OAuth, and developers know how to implement it. For user-to-application delegation, it works exactly as designed.

Why OAuth Isn't Enough for AI Agents

OAuth was designed for a specific interaction model: a human user delegates access to an application, and that application performs actions within well-defined scopes. AI agents break several assumptions this model relies on:

  • Scopes are static — OAuth scopes are granted at authentication time and remain fixed for the lifetime of the token. An agent with payments:write can make a $1 payment or a $10,000 payment. The scope doesn't distinguish between them.
  • No per-action cost evaluation — OAuth has no concept of action cost or risk level. A token that grants write access grants it equally for all writes, regardless of their real-world impact.
  • No human-in-the-loop for individual actions — once the user grants consent, every action within those scopes proceeds automatically. There's no mechanism for the user to review and approve specific high-risk actions while allowing routine ones.
  • No cryptographic proof of specific actions — an OAuth token proves the holder has delegated access, but it doesn't prove that a specific action was evaluated and authorized. There's no auditable proof linking a decision to a policy check.
  • Designed for user-to-app, not agent-to-service — OAuth's consent flow assumes a human clicks "Allow" in a browser. Agents operate autonomously, often calling multiple services in sequence, making the traditional consent model a poor fit.

These aren't flaws in OAuth — they're boundaries of its design. OAuth answers the question "does this application have permission to access this API?" It doesn't answer "should this agent perform this specific action right now?"

How OpenLeash Complements OAuth

OpenLeash is not a replacement for OAuth. The two systems solve different problems and work together naturally. OAuth handles authentication and delegation — proving who the agent is and what APIs it can access. OpenLeash handles per-action authorization — deciding whether a specific action should proceed given the current context.

Think of it as two layers. OAuth is the outer layer: the agent uses an OAuth token to authenticate with an API. OpenLeash is the inner layer: before making the API call, the agent checks with OpenLeash whether this particular action is authorized by its owner's policies.

An agent might have an OAuth token granting payments:write access to a payment API. Without OpenLeash, every payment is permitted. With OpenLeash, the agent calls POST /v1/authorize before each payment. The policy might allow payments under $100 automatically, require owner approval for payments between $100 and $1,000, and deny anything above $1,000. The OAuth token provides access to the API. The OpenLeash policy governs how that access is used.

The Combined Architecture

In a typical deployment, the two systems interact in a clear sequence:

  1. Authentication — the agent authenticates with external services using OAuth tokens. This establishes the agent's identity and grants API-level access.
  2. Action planning — the agent's model decides to perform an action, such as making a purchase or sending an email.
  3. Authorization check — before executing, the agent sends the action details to OpenLeash. The request includes the action type, target, cost, and any relevant context.
  4. Policy evaluation — OpenLeash evaluates the request against the owner's YAML policies, considering constraints like cost thresholds, counterparty trust, and time-based rules.
  5. Decision — OpenLeash returns ALLOW (with a proof token), DENY, REQUIRE_APPROVAL, or REQUIRE_STEP_UP. The agent proceeds accordingly.
  6. Execution — if allowed, the agent makes the API call using its OAuth token and attaches the OpenLeash proof token. The receiving service can verify the proof independently.

OAuth gets the agent through the door. OpenLeash decides what the agent is allowed to do once inside. Neither replaces the other — they address different layers of the authorization stack.

Key Differences Summary

The core distinctions between the two systems:

  • Evaluation timing — OAuth evaluates access at token issuance. OpenLeash evaluates at action time, every time.
  • Granularity — OAuth operates at the scope level (e.g., payments:write). OpenLeash operates at the individual action level (e.g., "pay $47.50 to Vendor X").
  • Context awareness — OAuth scopes are fixed. OpenLeash policies consider cost, counterparty, time, cumulative spending, and risk level for each action.
  • Human oversight — OAuth consent happens once upfront. OpenLeash can require human approval for specific actions based on policy rules.
  • Proof model — OAuth tokens prove delegated access. OpenLeash proof tokens prove a specific action was authorized by a specific policy at a specific time.
  • Verification — OAuth tokens are verified by the issuing authorization server. OpenLeash PASETO tokens can be verified offline by any party with the public key.
  • Design intent — OAuth was designed for user-to-application delegation. OpenLeash was designed for governing autonomous agent behavior.

Learn More

See how OpenLeash compares to other access control models: OpenLeash vs API Keys examines why static credentials fall short for autonomous agents. For foundational concepts, read about AI agent authorization, AI agent guardrails, human-in-the-loop controls, and PASETO proof tokens. Or dive into the documentation to start implementing.