SAML and OIDC Flows for Non-Human AI Agent Identities
SAML and OIDC weren't built for agents acting without humans.
Non-human identities now outnumber human ones inside most enterprises, and nobody planned for that shift. SAML and OIDC, the two protocols carrying the weight of enterprise identity for the last two decades, were built on one assumption: a person sits at a keyboard, clicks something, and waits for a response. AI agents break that assumption at every step, acting asynchronously, chaining calls across a dozen services, and spawning sub-agents that need their own credentials mid-task. This piece maps exactly where each protocol survives contact with agentic workloads, where it doesn't, and what enterprises are actually deploying instead.
The scale of the governance vacuum agents have created
Start with the ratio, because it's the number that makes the rest of this article necessary. Non-human identities outnumber human identities by more than 90 to 1 in many organizations, and some enterprises report ratios as high as 144 to 1, according to the Cloud Security Alliance's "State of Non-Human Identity and AI Security" survey. Between 2024 and 2025 alone, non-human identities grew 44 percent across the environments the CSA measured, a population explosion happening inside systems sized for a much smaller crowd. That's a population explosion happening inside systems that were sized and governed for a much smaller crowd, not a slow drift. That's a population explosion happening inside systems that were sized and governed for a much smaller crowd.
The credential picture beneath that growth reflects a deeper cause: most organizations were never set up to treat agents as distinct identity principals, which produces the shaky credential practices described next, as the following data show. Research into enterprise non-human identities found that only 21.9 percent of organizations treat agents as their own identity principals. Instead, 45.6 percent of organizations run agents on shared API keys, and most of the rest hand agents credentials that were built for humans and never meant to leave that context. Shared keys and borrowed logins are how you end up with an agent that has read access to finance, marketing, and HR simply because whoever provisioned it grabbed the nearest working key.
Accountability collapses right behind provisioning. The CSA survey found that only 28 percent of organizations can trace an agent's actions back to a human sponsor across all their environments. Flip that number around: in nearly three-quarters of enterprises, agents act without anyone clearly on the hook for what they did. Ninety-two percent of the same survey's respondents say their existing IAM tools can't handle AI and non-human identity risk, and 78 percent admit they have no documented policy for creating or retiring an agent identity. Agents are being born and left to wander with no birth certificate and no exit process.
None of this is theoretical anymore. Oasis Security research found that nearly half of surveyed organizations had already experienced a non-human identity compromise, and 66 percent of those incidents turned into a successful attack. A separate survey reported on the Okta blog found that 90 percent of organizations have no way to see what their agents are actually doing in production, and 54 percent had already suffered a security incident tied to an agent acting outside expectations. Separate research found that 90 percent of deployed agents held more permission than their task required. The gap between what agents can do and what anyone is watching them do is a current incident rate. It's a current incident rate.
Why SAML breaks for agents
SAML was built to solve one problem well: a human logs into a browser, the identity provider issues a signed assertion, the browser hands that assertion to a relying party, and a session opens. Every part of that sentence assumes a browser, a bounded session, and a single human named in the assertion's NameID field. Agents have none of the three. There's no browser context for a background process, no session boundary for something that runs for six hours unattended, and no individual human identity to put in the NameID slot when the "user" is a script calling five APIs in sequence.
Forced into a SAML world anyway, agent deployments tend to land on one of two bad patterns. Either the agent authenticates as if it were the human, which is functionally credential theft even when it's sanctioned internally, or a human logs in once, hands the session cookie to the agent, and that cookie now lives far longer than the task the human actually approved. Neither pattern gives anyone a way to scope the agent's access to what it's actually doing.
SAML also has no vocabulary for delegation depth. An assertion can't say "agent X is acting for user Y, who authorized scope Z, through this chain of calls." The assertion is flat by design; it was never meant to carry a chain, because the flow it was built for has no chain to carry. There's no SAML analog to token exchange, no equivalent of token binding for a client that never touches a browser. Patching that in would mean rebuilding the protocol's data model from scratch, at which point it isn't SAML anymore, it's something new wearing SAML's name.
None of this is a knock on SAML. The protocol does what it was designed to do, and does it well for the case it was built for: federated human login into web applications. The mismatch appears when someone tries to stretch SAML past the case it was built for. The workable answer, and the one that shows up repeatedly in enterprise architecture today, is to keep SAML exactly where it already sits, federating the enterprise identity provider into an OAuth or OIDC authorization server, and let that authorization server issue the tokens agents actually use. SAML becomes plumbing upstream of the agent, never the thing the agent talks to directly.
How OIDC and OAuth 2.0 fit and break for agent use cases
OAuth 2.0 and OIDC fare better than SAML, mostly because OAuth was never exclusively about humans clicking consent buttons. Short-lived, scoped access tokens are the right shape for an agent credential: a token that expires in minutes, carries a defined set of permissions, and gets checked against a specific resource server. Token introspection lets a downstream service confirm a token is still valid without pinging the identity provider on every single call, which matters when an agent might make hundreds of calls in a task. And the client credentials grant, covered in the next section, gives agents a way to authenticate without a human in the loop. The OpenID Foundation's October 2025 paper, "Identity Management for Agentic AI," states that current OAuth 2.0 and OIDC standards already handle a wide range of agent use cases, as long as the agent operates inside well-defined boundaries.
The trouble starts at the boundaries. That same paper flags three gaps the existing standards don't close. The first is mode ambiguity: an agent might act on its own initiative one moment and on a user's explicit behalf the next, and current systems have no reliable way to record which mode produced a given action. The second is fragmentation, as vendors build their own proprietary identity schemes to cover gaps the standards haven't filled yet, which is how interoperability problems get baked in early. The third, and probably the thorniest, is recursive delegation: an agent spawns a sub-agent, which spawns another, and nothing in the standard caps how deep that chain can go before someone loses track of who authorized what.
Multi-hop delegation is where OAuth's original design shows its age most clearly. OAuth 2.0 was built for one hop, App A calling App B on a user's behalf. Agentic workloads routinely need three or four hops: an orchestrator calls a research service, which calls a data service, which calls a third-party API, and each of those downstream services needs to verify the full chain back to the original authorization, not just trust whoever called it most recently. RFC 8693, the Token Exchange standard, is the closest existing tool for this, and the IETF OAuth working group's draft-ietf-oauth-identity-chaining extends it (pairing RFC 8693 with RFC 7523) specifically for multi-hop agent chains. As of early 2026 that draft had cleared working group last call and was in active revision, with IESG approval and formal Proposed Standard status not expected until summer 2026. It's close, but it isn't finished, and enterprises building agent pipelines today are working ahead of the standard rather than on top of it.
The On-Behalf-Of flow has a related gap. OBO patterns exist, but they lean on CIBA, Client-Initiated Backchannel Authentication, for human consent, and CIBA assumes a human is available to approve a push notification. That works fine for a handful of delegated actions a day. It doesn't work when an agent is issuing hundreds of downstream calls an hour and can't pause for a phone-based approval every time. Standard OAuth scopes add another layer of friction here: scopes tend to be coarse (read, write, admin) rather than task-specific, so there's a persistent gap between what a token technically allows and what the agent should be doing in that exact moment. And OIDC's ID token, built to tell a client who the human is, is the wrong tool for asserting an agent's own identity to a downstream service. It can tell you which human launched the agent. It says nothing about the agent itself.
The client credentials grant as the practical baseline for autonomous agent auth
When the delegation complexity is stripped away, the client credentials grant is where most autonomous agent auth actually lives today. The agent authenticates directly with the authorization server using its own client ID and a secret or certificate, no user, no consent screen, no redirect. It gets back a token and calls the resource server. This is the OAuth flow built for machine-to-machine traffic from the start, which makes it a much better fit than either SAML or the interactive OIDC flows: the agent is the principal here, not a stand-in for someone else.
Done right, it covers a fair amount of ground. Tokens can be issued with expiry measured in minutes or hours instead of days, scopes can be locked down to exactly the APIs a given agent needs, and every token issuance leaves a log entry tied to that agent's specific client ID, which is a real audit trail compared to a shared API key that a dozen services all quietly use.
It doesn't solve everything, though, and pretending otherwise is how organizations end up back in the incident statistics from the first section. The token itself says "agent X accessed resource Y." It says nothing about which human authorized agent X or why. There's no built-in way to mark whether the agent was acting autonomously or on a person's behalf at the moment of the call; that context has to be tracked somewhere else. And client secrets are, at bottom, still long-lived credentials unless someone actively rotates them, which puts the whole setup back in long-lived-credential territory if rotation isn't automated. NHIMG's 2025 report found that 73 percent of secrets held by non-human identities carry more permission than needed, and 1 in 20 AWS machine identities has full administrative rights. The client credentials grant just gives you the plumbing to enforce discipline, if someone actually enforces it, without preventing any of that on its own. It just gives you the plumbing to enforce discipline, if someone actually enforces it.
The fix isn't exotic, it's scope discipline applied consistently. Replace static client secrets with short-lived certificates or workload identity federation where the infrastructure supports it, SPIFFE/SPIRE issuing SVIDs is the standard route here. Scope every token to the minimum a given task needs. Set token expiry aggressively enough that an agent running a long task has to re-authenticate rather than sit on one token for its entire lifetime. And log every issuance with the agent's registered identity, the team that owns it, and the scope it was granted, because that log is the only thing standing between "agent X accessed resource Y" and an actual accountable trail. HashiCorp published dedicated 2025 guidance on applying SPIFFE/SPIRE to AI agents and non-human workloads specifically, and it's a mature, already-shipping path for organizations that want agent identity handled without betting the architecture on one vendor's platform. SVID-based auth removes the client secret from the equation entirely, which solves credential rotation by leaving nothing static left to rotate.
Token exchange and scoped delegation for user-delegated agent tasks
Client credentials cover an agent acting on its own. They don't cover the far more common case: a user tells an agent to go review an inbox and draft replies, and the agent now needs to act as that specific person, bounded to what that person authorized, for a limited stretch of time.
The obvious shortcut, handing the agent the user's own access token to replay, is also the one that wrecks accountability fastest. A downstream service that receives the user's token has no way to tell whether the user or the agent made the call. Audit logs collapse into one undifferentiated stream, and the agent's effective permissions become identical to the user's full permissions, whether or not the task called for that much reach.
RFC 8693, Token Exchange, exists specifically to close that gap. The agent presents the user's token along with its own client credentials to the authorization server, and the server responds with a new token, downscoped, that represents "agent X, acting for user Y, with exactly these permissions." The original user token is not passed along to the downstream service. The resulting delegation token, properly built, carries the agent's client ID in an act claim, the human's identity in the sub claim, scopes narrowed to the task at hand rather than the user's entire permission set, and an expiry tied to how long the task should realistically take.
Okta's own implementation of this, reaching general availability August 24, 2026, is a concrete illustration of the pattern rather than an abstraction. When a user launches a delegated agent, Okta issues a delegation token scoped to something specific, read-only and compose-level access to a particular productivity app rather than blanket access to it, valid for a defined window, tied back to that user, and auditable to the action that started it. Downstream systems see "agent X, acting for user Y, with these scopes, for this session," which is precisely the sentence a flat SAML assertion or a replayed OAuth token can never produce.
The chain gets harder once the delegated agent starts calling other services itself. Each additional hop needs to verify the entire delegation chain back to the original grant, not just trust whichever agent called it most recently, and that's exactly the case the draft-oauth-identity-chaining standard is built to cover, extending RFC 8693 for multi-hop scenarios and having cleared working group last call as of early 2026. Skip that mechanism and each downstream service can only see one hop back. The trust chain effectively goes dark past the first delegation. Recursive delegation, agents spawning sub-agents that spawn further sub-agents, remains unresolved: nothing in the current token model enforces a hard limit on how many layers deep a delegation chain can run, and the OpenID Foundation's October 2025 paper names it explicitly as an open problem. Until the standards catch up, that limit has to live somewhere else: as an explicit policy enforced at the authorization server, not as a convention left to whoever built the agent.
MCP's OAuth 2.1 mandate for enterprise agent auth
The Model Context Protocol went from a single vendor's internal project to a Linux Foundation standard in a little over a year, picking up OpenAI and Block as co-founders and Google, Microsoft, AWS, Cloudflare, and Bloomberg as supporting members along the way. By early 2026 it was seeing over 97 million monthly downloads, which puts MCP squarely in the category of infrastructure that enterprise security teams have to take seriously whether or not they chose it themselves.
MCP added OAuth 2.1 support for its HTTP transport in March 2025, under spec version 2025-03-26, and the profile it mandates is meaningfully stricter than plain OAuth 2.0. PKCE, Proof Key for Code Exchange, is required rather than optional. The implicit grant and the password grant, both long-standing sources of token leakage, are prohibited. Redirect handling is tightened to close off a category of open-redirect attacks that plagued looser OAuth implementations for years. The spec initially recommended dynamic client registration for onboarding new MCP clients, but that recommendation didn't hold: Client ID Metadata Documents became the preferred default in the November 2025 spec revision, and the July 2026 revision formally deprecated dynamic client registration in favor of that approach.
What that means in practice for an enterprise standing up agent tooling built on this kind of open protocol is fairly direct. Any agent talking to an MCP server over HTTP inherits a baseline that's already stricter than what a lot of internal OAuth 2.0 deployments enforce today, PKCE and clean redirect handling aren't optional add-ons, they're load-bearing parts of the transport. The arXiv figures cited earlier show that's a meaningfully higher floor than the client-credentials-plus-shared-secret pattern still running in nearly half of enterprise agent deployments. It doesn't resolve the harder problems, mode ambiguity, recursive delegation depth, multi-hop chain verification, all still sit outside MCP's scope and squarely inside the work the IETF's identity-chaining draft and the OpenID Foundation's ongoing work are trying to finish. But it does mean that organizations adopting MCP are, by the protocol's own requirements, starting from a stricter baseline than the market average, whether they set out to or not.
