AAP: An OAuth 2.0 Authorization Profile for Autonomous AI Agents — Extending JWT with Capabilities, Delegation, and Oversight

JWT.io
1

Hi Auth0 community,

I’d like to share a project that addresses a gap we encountered when deploying AI agents in production: how to properly authorize autonomous agents using OAuth 2.0.

The Problem

OAuth 2.0 scopes work great for user-app-API interactions, but when your clients are autonomous AI agents, the model starts to break down. Scopes like read:web or write:cms don’t let you express:

  • “This agent can only search these specific domains, max 50 requests per hour”

  • “This agent can create drafts but needs human approval to publish”

  • “This agent delegated to a tool — track the chain and limit delegation depth to 2”

  • “Bind this token to a specific task so we can audit why an action was taken”

You end up building custom middleware for every constraint, and it doesn’t scale.

The Solution: Agent Authorization Profile (AAP)

AAP is an authorization profile built on top of OAuth 2.0 and JWT. It doesn’t replace anything — it extends standard tokens with five structured claims:

agent — Verifiable agent identity (ID, type, operator, model, runtime environment). Every token is traceable to a specific agent.

capabilities — Actions with server-enforced constraints. Instead of scope=read:articles, you get:

{
  "action": "cms.read_articles",
  "constraints": {
    "domains_allowed": [
      "docs.example.com"
    ],
    "max_requests_per_hour": 100,
    "time_window": {
      "start": "...",
      "end": "..."
    }
  }
}

Constraints are validated by the Resource Server — the agent can’t tamper with them.

task — Links the token to a specific task ID and purpose, enabling purpose-bound authorization and preventing token misuse across contexts.

delegation — Uses Token Exchange (RFC 8693) with automatic depth tracking. When Agent A delegates to Tool B, the AS increments depth, appends to the chain, and reduces privileges.

oversight — Declares which actions require human approval before execution, integrating approval workflows directly into the authorization layer.

How It Works with Existing OAuth Infrastructure

AAP is designed for incremental adoption:

  1. Your Authorization Server issues JWTs with AAP claims alongside standard OAuth claims

  2. Resource Servers that understand AAP enforce capabilities and constraints

  3. Resource Servers that don’t simply ignore the extra claims — backward compatible

  4. Agents authenticate via standard Client Credentials grant

  5. Delegation uses RFC 8693 Token Exchange

  6. Proof-of-possession via DPoP (RFC 9449) or mTLS (RFC 8705)

You can run AAP in parallel with your existing scope-based authorization and migrate incrementally.

Resources

We’ve published everything needed to evaluate and implement AAP:

The spec has been submitted as an IETF Internet-Draft (draft-aap-oauth-profile-01) to the OAuth Working Group.

Looking for Feedback

We’re particularly interested in hearing from developers who:

  • Are building or operating AI agents that call APIs in production

  • Have experience with OAuth 2.0 token customization and custom claims

  • Work in regulated environments (SOC 2, GDPR, HIPAA) where agent audit trails matter

  • Have opinions on capability-based authorization vs. traditional RBAC/scopes

Any feedback on the specification, schemas, or overall approach is welcome. We want to make sure this is practical and solves real problems before pushing further through the standards process.

Thanks for reading!