TL;DR: OAuth remains a sound delegated authorization protocol, but enterprise AI agents operate across multi-step, multi-protocol workflows where fixed scopes, token-only context, and shallow delegation chains fail to govern runtime behaviour, according to Aizome. The real gap is behavioural governance across the execution path, where intent drift and cross-system action decisions outgrow entry-point auth controls.
NHIMG editorial — based on content published by Aizome: Beyond the Token: Why OAuth Solves the Wrong Problem for Enterprise AI Agents
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams govern enterprise AI agents beyond OAuth?
A: Use OAuth for delegated access, but add runtime governance that evaluates the current action, workflow context, and delegation depth before sensitive operations proceed.
Q: Why do scoped tokens break down for enterprise AI agents?
A: Scoped tokens assume behaviour is predictable enough to be described at provisioning time.
Q: What breaks when identity is treated as a one-time authorization event?
A: The programme loses visibility into whether the current action still matches the original approval.
Practitioner guidance
- Separate access checks from action checks Keep OAuth, PKCE, and token exchange as entry controls, then add a second governance step that evaluates whether the current action still matches the workflow intent before execution proceeds.
- Map agent delegation chains end to end Document supervisor agents, worker agents, sub-agents, and downstream tools so you can see where intent is diluted across the chain and where accountability becomes ambiguous.
- Correlate identity events across protocols Join logs from OAuth, API key use, managed identity, and MCP-style tool access so behavioural drift is visible even when no single protocol shows a policy violation.
What's in the full article
Aizome's full post covers the operational detail this analysis intentionally leaves at the architecture level:
- A deeper walkthrough of OAuth 2.1, DPoP, PKCE, token exchange, and where each helps or stops helping in agent workflows.
- Specific examples of how multi-hop delegation degrades intent across supervisor, worker, and sub-agent chains.
- A fuller explanation of the runtime governance layer that sits above identity and token security in enterprise agent stacks.
- The article’s own framing of how standards work such as SPIFFE and OAuth fit into the longer-term agent identity picture.
👉 Read Aizome's analysis of why OAuth falls short for enterprise AI agents →
Enterprise AI agents and OAuth limits: what IAM teams miss?
Explore further
OAuth solves authentication and scoped authorization, not runtime governance. That distinction is the central issue for enterprise AI agents. When an agent can decide what to do next, the security question moves from access grant to action legitimacy, which token-based models cannot answer on their own. Practitioners should treat OAuth as one layer in a broader control stack, not the full answer.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows that exposure and revocation are still disconnected in many environments.
A question worth separating out:
Q: How can teams reduce risk when agents use multiple protocols in one workflow?
A: Build correlation across the full protocol chain so identity events from OAuth, API keys, managed identity, and tool-specific credentials are analysed together. That allows teams to spot behaviour that looks compliant in each individual layer but unsafe when viewed as one execution path.
👉 Read our full editorial: OAuth solves the wrong problem for enterprise AI agents