Beyond the Token: Why OAuth Solves the Wrong Problem for Enterprise AI Agents

Let me say something that might be unpopular in certain circles: OAuth 2.0 is a well-designed protocol. It solved a real problem elegantly, it scaled across the internet, and the patterns it established - delegated authorization, scoped tokens, consent flows- are genuinely good engineering.

It was also designed for a world that no longer exists. Or more precisely, for a world that no longer describes what enterprise AI agents actually do.

The identity community is in the middle of a serious conversation about OAuth's limitations for agentic AI. OAuth 2.1, DPoP, PKCE, token exchange via RFC 8693, SPIFFE/SVID for machine-to-machine flows, the standards bodies are active, the engineering community is engaged, and real progress is being made. I follow this work closely and respect it.

But I want to push the conversation somewhere it isn't going yet, because I think the industry is solving the wrong problem.

The OAuth conversation is fundamentally about authentication and authorization: proving who the agent is, and what it's permitted to do. Those are necessary problems. They are not sufficient. And the gap between "necessary" and "sufficient" is exactly where enterprise AI agent risk accumulates.

What OAuth Was Designed For#

OAuth was designed to answer a specific question: can this client act on behalf of this user, within this scope, for this purpose?

The mental model is a delegation chain. A human authenticates. They consent to grant a client application certain permissions. The application receives a token that represents that delegation. The token has a scope, a defined boundary of what the application can do on the user's behalf. The resource server validates the token, checks the scope, and either grants or denies access.

This model works beautifully for its intended use case. A user authorizes a third-party application to read their calendar. The token is scoped to calendar read. The application cannot write to the calendar, cannot access email, and cannot do anything outside the granted scope. The delegation is explicit, bounded, and auditable.

Now apply that model to an enterprise AI agent operating autonomously across Finance, HR, and Operations, invoking sub-agents, inheriting context from upstream workflows, making multi-step decisions at machine speed.

The model starts to strain immediately.

The Three Places OAuth Breaks Down#

First: Agents don't have fixed scopes.

OAuth's security model depends on scopes being meaningful, a defined, bounded set of permissions that accurately represents what the client will do. For traditional applications, this works because the application's behavior is deterministic. A calendar app reads calendars. A file sync tool reads and writes files. The scope maps to the behavior.

Enterprise AI agents are non-deterministic by design. They reason about problems and decide which tools to invoke based on context. An agent tasked with "prepare the monthly close report" might access accounts payable data, query the ERP, pull from the vendor database, and invoke a sub-agent to reconcile discrepancies, none of which was fully specified at provisioning time. The scope you define at deployment is an approximation of what the agent might need. It is not a precise description of what it will do.

This creates a structural problem: you either over-scope the agent to ensure it can complete its tasks, granting permissions it may never use but could abuse, or you under-scope it and accept that it will fail on legitimate tasks. Neither is acceptable for enterprise-grade deployment.

Second: Tokens don't carry intent.

A token tells a resource server what the agent is permitted to do. It does not tell it why the agent is doing it, whether this specific action is consistent with the workflow that originated it, or whether the behavior has drifted from what was authorized at the start of the chain.

Consider a concrete scenario: a finance automation agent holds a valid token with appropriate scope for accessing accounts payable data. Six weeks after provisioning, that agent is three hops into a workflow it was never explicitly designed for. A supervisor agent delegated a task that falls within the letter of the token's scope but well outside the intent of the original authorization.

The resource server sees a valid token with the appropriate scope. It grants access. From OAuth's perspective, everything worked correctly. From a governance perspective, something has gone seriously wrong, and the token-based model has no mechanism to detect or prevent it.

Third: Agent chains break the delegation model.

OAuth's delegation model assumes a relatively shallow chain: user - application - resource. In multi-agent architectures, the chain is deep and dynamic. A supervisor agent delegates to a worker agent, which invokes sub-agents, which call external tools, which access sensitive systems, with the original human authorization becoming increasingly abstracted at each hop.

The on-behalf-of (OBO) flow in OAuth 2.0 handles some of this, but it breaks down at scale. Each delegation step requires explicit token exchange. The chain becomes brittle. And more importantly, the original authorization context, what the human intended when they initiated the workflow, degrades with every hop. By the time an action reaches a sensitive system, the token may be technically valid while the intent that generated it has been entirely lost.

The Question OAuth Cannot Answer#

Here is the question that I keep coming back to as a CTO building identity infrastructure for enterprise AI agents:

Should this action be executed by this agent, right now, in this context?

Not: Is this agent authenticated? OAuth answers that. Not: Does this agent have permission to access this resource? OAuth answers that, too.

But: given what this agent is doing, why it appears to be doing it, what it has done in this session, what the upstream workflow context is, and what the downstream consequences are, should this specific action proceed?

That question requires a different kind of infrastructure entirely. It requires real-time behavioral observation at the point of operation. It requires a model of agent intent that persists across the session and can be evaluated against the original authorization context. It requires the ability to detect drift - when an agent's behavior diverges from its established baseline - and respond dynamically, not at the next policy review cycle.

OAuth provides a gate at the entry point. Enterprise AI agents need continuous governance across the entire execution path.

The Multi-Protocol Reality Makes It Worse#

There's a practical engineering dimension to this that deserves attention.

A typical enterprise AI agent doesn't operate within a single authentication domain. In a single task execution, it may authenticate to an LLM provider via API key, to enterprise APIs via OAuth, to cloud databases via managed identity, and to tool servers via MCP tokens. Each protocol has its own token format, validation requirements, and permission model.

Your OAuth provider has visibility into the OAuth layer. It has no visibility into what the agent is doing in the MCP layer, or the API key layer, or the managed identity layer. The gaps between protocols are exactly where behavioral drift is hardest to detect and where accountability is hardest to establish.

This multi-protocol reality is what makes enterprise AI agent identity structurally different from traditional workload identity, and why a solution that addresses only the OAuth layer addresses only a fraction of the actual attack surface.

What the Standards Community Is Building, and What It Leaves Open#

The IETF and standards community are doing important work. OAuth 2.1 tightens the security baseline. RFC 8693 token exchange enables scope reduction in delegation chains. DPoP binds tokens to cryptographic proof of possession, making them harder to misuse. SPIFFE/SVID provides strong machine-to-machine identity. These are real improvements, and enterprises should be implementing them.

But the standards community is explicit about what remains open: action governance beyond identity, meaningful authorization for high-level agentic tasks, delegation chain integrity at depth, and interoperability across vendor identity systems. The 12-24 month timeline to RFC for the agent-specific extensions means enterprises are making architectural decisions right now, before full standardization arrives.

The practical reality is that the authentication and authorization problem is being solved. The behavioral governance problem, what the agent should be doing, not just what it's permitted to do, is not in scope for the standards bodies. It's an application-layer problem. And it's the one that matters most for enterprise risk.

A Different Architecture#

The architecture I believe enterprises need for production-grade agentic AI has three distinct layers, and OAuth lives in only one of them.

The first layer is credential and token security - OAuth 2.1, DPoP, PKCE, token exchange, SPIFFE/SVID. Get this right. It's the foundation. But it's only the foundation.

The second layer is identity governance - agent lifecycle management, ownership mapping, entitlement controls, least-privilege enforcement at provisioning, and integration with your existing IAM infrastructure. This is where your Okta, Microsoft Entra, and NHI tooling operates. Also necessary. Also insufficient on its own.

The third layer is runtime behavioral governance - real-time observation at the point of operation, intent-aware dynamic controls, behavioral drift detection, and cross-chain accountability. This is the layer that doesn't exist in most enterprise stacks today. It's the layer that answers the question OAuth cannot: should this action proceed, right now, in this context?

These layers are complementary, not competitive. An enterprise that implements only the first layer has good token hygiene and poor agent governance. An enterprise that implements all three has the infrastructure to deploy AI agents confidently, knowing that they can see what agents are doing, understand why, and intervene when behavior diverges from intent.

I think this matters because….

The IETF will eventually publish standards that address more of the agentic identity problem. The vendor ecosystem will mature. The tooling will improve.

But enterprise AI agents are in production today. They're operating across Finance, HR, Sales, and Operations right now, in environments where the governance infrastructure hasn't caught up with the deployment reality. The architectural decisions enterprises make in the next 12-18 months will determine their security posture for the next decade.

The answer isn't to wait for the standards to mature before deploying. It's to deploy with the right architecture, one that recognizes what OAuth solves, what it doesn't, and what additional layers are required to govern enterprise AI agents safely at scale.

Beyond the token is where the real work is.

Roee Salomon is CTO and Co-founder of aizome, an Enterprise AI Agent Control Platform. He previously co-founded and led AxoniusX within Axonius and has held engineering and security leadership positions for over 20 years.