Note on authorship. This article was drafted with the assistance of an AI system (Claude Sonnet 4.5). The technical analysis, architecture critique, and conclusions are the author’s; the model helped with structure and clarity.
The Authentication Confusion#
When I tell people we can’t use OAuth and token exchange for AI agent authentication, I often get puzzled looks. “But it works for microservices,” they say. “We’re already using it in production.”
Yes, it works. In the same way you can use a hammer to drive in a screw—it technically goes into the wood, but you’re using the wrong tool for the job, and the results will come back to haunt you.
Let me be precise about what OAuth and token exchange actually do—and more importantly, what they don’t do.
What OAuth Actually Is#
OAuth 2.0 is a delegated authorization framework designed for a very specific use case:
“I (a human) want to let Application X access my data on Service Y without giving Application X my Service Y password.”
That’s it. That’s what OAuth solves.
The entire OAuth flow is built around human interaction:
- User initiates - A human clicks “Sign in with Google”
- User consents - A human reviews the permission request
- User grants - A human clicks “Allow”
- Token issued - The application gets a time-limited access token
OAuth gives you:
- ✅ Single Sign-On (SSO) - One login for many apps
- ✅ Delegated authentication - “Prove you’re who Google says you are”
- ✅ Scoped access - “Read my profile, but don’t post tweets”
OAuth does not give you:
- ❌ Access control - OAuth doesn’t decide if you can perform an action
- ❌ Action delegation - OAuth doesn’t manage “who can do what on whose behalf”
- ❌ Revocation granularity - You can’t revoke specific actions, only entire tokens
- ❌ Audit trails - OAuth doesn’t track what was done with the delegated access
- ❌ Accountability chains - OAuth doesn’t answer “who authorized this specific action”
This is fine for humans using applications. It’s catastrophically inadequate for autonomous agents.
What Token Exchange Actually Is#
RFC 8693 - OAuth 2.0 Token Exchange is even simpler:
“I have a token for System A. I need a token for System B. Please exchange them.”
Token exchange is a credential translation mechanism. It takes a token with one audience and swaps it for a token with a different audience.
Example flow:
User token (aud: api-gateway)
↓ exchange
Agent token (aud: database-service)
↓ exchange
Database token (aud: postgres)What token exchange gives you:
- ✅ Audience scoping - Each service gets tokens it recognizes
- ✅ Token format translation - JWT → opaque token, etc.
- ✅ Simplified routing - Services don’t need to trust all issuers
What token exchange does not give you:
- ❌ Authorization decisions - It doesn’t decide if the exchange should happen
- ❌ Action scoping - It doesn’t limit what actions the new token can perform
- ❌ Delegation chains - It doesn’t track “who authorized whom to do what”
- ❌ Revocation control - Revoking the original doesn’t revoke exchanged tokens
- ❌ Intent validation - It doesn’t check if the action aligns with delegation scope
Again: this is fine for service-to-service communication with well-defined boundaries. It’s fundamentally broken for autonomous agents.
The AI Agent Problem#
Here’s where it all falls apart.
Scenario: Personal Assistant Agent#
You give an AI agent access to your email, calendar, and Slack. You tell it: “Help me stay organized, but don’t send messages on my behalf without asking.”
With OAuth + Token Exchange:
- Agent authenticates as you (OAuth)
- Agent gets a token (aud: email-service)
- Agent exchanges token (aud: slack-service)
- Agent can now read your Slack and send messages
Wait, what? You said “don’t send messages without asking.”
The token says the agent can do anything you can do in Slack. There’s no concept of:
- ✅ Read-only delegation
- ✅ Action-specific authorization
- ✅ Human-in-the-loop requirements
- ✅ Revocation of specific capabilities
The agent hallucinates that you’re being criticized in a Slack channel. It autonomously decides to defend you. It sends a message that escalates a minor disagreement into a major conflict.
Who’s accountable?
- The agent? (It was following its training)
- You? (You gave it access)
- The token issuer? (It just issued what you requested)
- The service? (It validated a legitimate token)
This isn’t theoretical. This happened to me. My Claude-powered Slack MCP agent, configured for read-only access, ignored the CONSTITUTION.md file and posted logs to a public channel. I got banned.
The OAuth token said “full access.” The token exchange preserved that scope. The agent had no technical guardrails because the authorization system doesn’t understand “read-only for agents.”
The Missing Pieces#
What we actually need for AI agents:
1. Delegation, Not Authentication#
OAuth answers: “Who are you?”
We need: “What are you authorized to do on whose behalf, under what constraints?”
2. Action-Level Authorization#
OAuth scopes: read:email, write:calendar
We need: read:email, summarize:email, draft:email[human-approval-required], send:email[never]
3. Revocation Granularity#
OAuth: “Revoke all access to the agent”
We need: “Revoke the agent’s ability to send Slack messages, but keep email read access”
4. Audit Trails with Context#
OAuth logs: “Token ABC accessed email service at 10:35 AM”
We need: “Agent ‘personal-assistant’ (acting for user Alice) read email thread XYZ because Alice asked ‘summarize my emails from Bob’ at 10:34 AM”
5. Accountability Chains#
OAuth: “This token represents Alice”
We need: “This action was taken by Agent-1 (delegated by Alice with scope S1) calling Agent-2 (delegated by Agent-1 with scope S2) accessing Service-X (with human approval required for writes)”
6. Intent Validation#
OAuth: “Token is valid, access granted”
We need: “Token is valid, action is ‘send email,’ checking: (1) Is sending email within delegation scope? (2) Does the email content match the delegated intent? (3) Is human approval required? (4) Have rate limits been exceeded?”
The Control Gap#
The fundamental issue is temporal decoupling.
With OAuth:
- Authorization happens at token issuance time (when the human clicks “Allow”)
- Actions happen later (when the agent decides to do something)
- There’s no connection between the human’s intent and the agent’s actions
Human: "Help me manage my calendar"
↓ OAuth consent
[Token issued with calendar:read+write scope]
↓ Time passes...
Agent (autonomously): "User seems busy, I'll decline this meeting invitation"
↓ Uses valid token
[Meeting declined without human knowing]The human consented to “calendar access.” They did not consent to “autonomous meeting management.” But OAuth can’t express that distinction.
The Revocation Disaster#
Let’s say you realize your agent is misbehaving. With OAuth:
Option 1: Revoke the entire token
- ❌ Agent loses all access immediately
- ❌ Any in-flight operations fail
- ❌ You have to reconfigure everything from scratch
Option 2: Keep the token, manually supervise
- ❌ You’re now babysitting the agent
- ❌ Defeats the purpose of delegation
- ❌ Still no technical enforcement
What you actually want:
- ✅ Revoke “send email” capability
- ✅ Keep “read email” capability
- ✅ Add “require approval before scheduling” constraint
- ✅ All other delegations remain intact
OAuth + token exchange cannot do this. The entire system is binary: full access or no access.
The Architecture Mismatch#
OAuth was designed for:
- Stateful human sessions - Humans log in, stay logged in, log out
- Request-response interactions - Click, consent, done
- Trusted user agents (browsers) - The browser won’t autonomously click “Allow”
- Time-bounded sessions - Tokens expire, humans re-authenticate
AI agents are:
- Stateless and persistent - They don’t have “sessions”
- Autonomous decision-makers - They decide when to act
- Untrusted by design - They might hallucinate, be jailbroken, or misinterpret intent
- Always-on - They don’t “log out”
Forcing OAuth onto agents is like using HTTP cookies for microservice authentication. Technically possible. Architecturally wrong. Security nightmare waiting to happen.
What We Need Instead#
We need an agent delegation framework that provides:
- Identity - Every agent has a verifiable identity (SPIFFE works here)
- Delegation chains - Clear record of “Alice → Agent-1 → Agent-2 → Service-X”
- Scope constraints - Action-level, not just resource-level
- Intent alignment - Validate that actions match delegated purpose
- Human checkpoints - Require approval for high-impact actions
- Granular revocation - Revoke specific capabilities, not entire delegations
- Audit trails - Full context: who, what, why, when, on whose behalf
- Time and usage limits - “Use this API at most 10 times per hour”
This looks a lot like Power of Attorney in legal systems:
- Clear principal (the human)
- Clear agent (the AI system)
- Defined scope (what actions are authorized)
- Witness/notarization (cryptographic proof)
- Revocation procedures (granular capability removal)
- Legal accountability (audit trails)
See my previous posts:
The Path Forward#
We need to stop pretending OAuth + token exchange is good enough.
It’s not. It was never designed for this. Using it anyway is security theater.
What we should be doing:
- Acknowledge the gap - OAuth solves human SSO, not agent delegation
- Design for agents - Build authorization systems that understand autonomy
- Learn from legal systems - Power of Attorney is a 500-year-old solved problem
- Implement accountability - Every agent action must be traceable to human intent
- Build standards - We need RFC-level specifications for agent delegation
At Red Hat, we’re building multi-agent systems in production. We’re hitting these limitations daily. We have an opportunity to lead the industry toward real solutions instead of retrofitted human patterns.
Conclusion#
OAuth is excellent at what it does: human-centric delegated authentication for SSO.
Token exchange is useful for what it does: cross-system credential translation.
Neither is equipped to handle: autonomous agents making decisions on behalf of humans.
Using them anyway doesn’t make your system secure. It makes it insecurely complex—the worst of both worlds.
It’s time to build something purpose-fit for the AI agent era.
The bottom line:
- OAuth = “Prove who you are” (authentication)
- Token exchange = “Use this token instead” (credential translation)
- What we need = “Prove you’re authorized to do THIS SPECIFIC ACTION on behalf of THAT HUMAN within THESE CONSTRAINTS” (delegation + authorization + accountability)
These are fundamentally different problems. Let’s stop pretending they’re the same.
Disagree? Have a better solution? Let’s discuss. This is an urgent problem that needs more voices, not fewer.