SAML and OIDC for AI Tool Authentication in the Enterprise

Enterprise AI adoption has outrun the people whose job is to track it. The average enterprise now runs 14 distinct AI tools; IT knows about four or five, according to Productiv's 2026 numbers. That gap is an identity problem: tools that never touch an identity provider can't be governed, audited, or shut off when someone quits. SAML and OIDC are the two protocols deciding whether an AI tool sits inside that governed perimeter or floats outside it, unaccounted for, until something breaks.

So which protocol handles which tool? SAML and OIDC each solve a real, distinct slice of the problem. Neither one, alone or combined, has an answer for AI agents acting without a human anywhere near the keyboard, and that's the part worth sitting with.

How SAML 2.0 works and where it still belongs in the enterprise

SAML runs on XML assertions, signed by the identity provider, carried through the browser via POST binding, and picked up by the service provider on the other end. Trust between the two sides is set up ahead of time, through metadata exchange and certificate pinning. No dynamic handshake happens at login; the relationship is already on file before anyone shows up to use it.

Every major enterprise identity provider still speaks SAML fluently. Okta, Microsoft Entra ID, Google Workspace, Ping Identity, all of them support it, because the installed base demands it. That installed base is exactly where SAML keeps earning its keep. Organizations with a decade of SAML plumbing already in the walls aren't ripping it out for something newer. Financial services, healthcare, government: these tend to have SAML woven into contracts and downstream systems that would take a small army to unwind. Any AI tool with a browser front end that can play along in a standard SP-initiated or IdP-initiated flow fits into that world without friction.

The cost shows up later, and quietly. Each new relying party means another certificate to rotate, another metadata file to keep synced. Manageable when your SSO estate is stable. Less so once the AI tool count starts climbing the way it has been lately. NIST SP 800-63C-4, published in 2025, still recognizes SAML at every assurance level, but flags XML canonicalization and parser-differential bugs as a structural risk for anyone building fresh on top of it. Most of SAML's actual failures trace back to governance discipline, not the protocol itself. A certificate rotation slips by two weeks, a metadata file drifts out of sync, and nobody notices the gap until something breaks in production.

How OIDC works and why it fits the modern AI tool surface better

OIDC takes OAuth 2.0 and layers identity on top of it. The ID token it hands back is a signed JSON Web Token, not an XML document, and that sounds like a small distinction until you've had to debug both. JWTs are compact, easy to pass around in HTTP headers, and they skip the XML parsing machinery that gives SAML its headaches.

The Authorization Code Flow with PKCE, standardized in RFC 9700 in 2025, keeps tokens off the front channel and ties the code challenge to the original request. That matters for AI tools running as native apps or single-page clients, which is most of them now. The discovery document at /.well-known/openid-configuration lets a brand-new AI tool configure itself with almost no manual wiring, and when onboarding speed is the thing you're optimizing for, that's the gap between a same-day integration and a two-week ticket queue.

OIDC wins in a few specific spots. SaaS-native, API-first AI tools were never built with XML federation in mind, and mobile or desktop coding assistants like Cursor or GitHub Copilot can't sit through a browser redirect the way a web app does. Anywhere token lifetime, scope, and refresh need to be managed by code instead of a person clicking through an admin console, OIDC fits better. As of 2025, 72% of enterprises run multi-protocol SSO estates, which means most organizations are already running SAML and OIDC side by side, whether or not anyone signed off on that officially. OIDC's token model also opens a path to the machine-to-machine flows AI agents actually need. More on that later, because it's the harder problem.

The protocol decision in practice: matching SAML or OIDC to an AI tool

The decision comes down to what the AI tool supports, what the identity provider can broker, and how much certificate and lifecycle overhead the identity team can absorb without losing a weekend to it. Browser-based enterprise AI platforms, Copilot for Microsoft 365, Glean, tend to arrive with SAML support already built in. API-native or developer-facing tools default to OIDC because that's what their SDKs were written against from day one.

Most enterprise identity providers, Okta and Entra ID chief among them, broker both without complaint. The real question is which side a given tool lands on, and how fast the organization keeps adding new ones. If AI adoption is moving at a steady clip, OIDC's autodiscovery cuts per-tool setup time enough that you'll actually feel it. SAML stays fine where the relying-party count holds steady; it gets expensive fast once that count starts climbing.

On the OIDC side, token hygiene matters more than people expect going in: short-lived access tokens, often around 15 minutes, refresh token rotation, and scopes narrowed to exactly what the tool needs and nothing more. There's a hard limit worth naming directly, too. When an AI tool needs to act on a user's behalf against a downstream API, a SAML assertion, bound to the browser session that created it, cannot travel with that request. It just can't. OIDC token exchange, defined in RFC 8693, or a gateway that propagates identity downstream, is what actually solves this. For enterprises running both legacy SAML apps and a growing AI stack, the practical move is treating the identity provider as a broker sitting above both protocols: let SAML keep serving what it already covers, let OIDC take the new territory it was built for.

Where both protocols stop: the non-human identity problem AI agents create

Here's the wall both protocols hit. SAML and OIDC interactive login flows assume a human at a browser, typing a password or tapping a push notification. Neither has anything to say about an AI agent authenticating against a production API at two in the morning, with no one watching and no browser anywhere in sight.

Non-human identities already outnumber human users in enterprise environments by a wide margin, somewhere between 50-to-1 and 144-to-1 depending on whose research you trust, and that population is growing rapidly year over year. AI agents are the fastest-growing slice of it. CyberArk's 2025 report names AI as the top creator of new identities carrying privileged, sensitive access, ahead of every other category tracked.

The common workaround is to hand the agent a shared service account and call it solved. That single move stacks up three separate problems at once. It creates one credential whose compromise takes down everything the agent touches; it skips per-user permission logic entirely, so the agent inherits whatever the service account can reach rather than what any specific person is allowed to do; and it renders audit logs useless, because every action shows up under the same identity whether it was routine or catastrophic.

The fallout is already on the books. Researchers found 24 million leaked non-human-identity credentials on GitHub in 2025, and 70% of the ones from 2022 were still valid when discovered, per the OWASP NHI Top 10 report. SpyCloud's 2026 Identity Exposure Report recaptured 18.1 million exposed API keys and tokens, 6.2 million of which were credentials or authentication cookies tied specifically to AI tools. Agents need their own machine identities, scoped, rotatable, revocable, auditable on their own terms. Not human credentials handed down and reused because nobody had time to build the real thing.

The OAuth 2.0 flows that govern machine-to-machine AI authentication

For non-human agents, OAuth 2.0 already has the right machinery. Most teams just haven't wired it up yet. The Client Credentials Grant lets an agent authenticate with its own client ID and secret, or an mTLS certificate, directly at the token endpoint: no user, no browser redirect, no session. RFC 8693 Token Exchange builds a delegated chain, where the agent presents a user's token and trades it for a scoped agent token that carries the user's identity downstream, without ever exposing the original credential. JWT Bearer Assertions let the agent sign its own claim with a private key, so the authorization server checks a signature instead of comparing a shared secret. Workload Identity Federation, using SPIFFE and SPIRE, assigns a cryptographic identity to the workload itself rather than to a service account credential, an approach now being formalized in the IETF's WIMSE working group.

Token exchange matters most for MCP-connected agents specifically. An agent acting on a user's behalf should carry that user's scoped identity into every downstream call it makes, so authorization stays per-user at the API layer instead of collapsing into one blanket decision for the whole agent. A production gateway checks incoming agent identity, whether that's a JWT, OAuth 2.0 with PKCE, or OIDC, and propagates it forward to the MCP servers it connects to. If a user can't delete a repository, the agent acting on their behalf can't either. Full stop.

This isn't hypothetical, and it isn't sitting somewhere in the future. Roughly 90% of agents in current enterprise deployments hold excessive privileges, and AI agents move data at roughly 16 times the rate of human users, according to research from Obsidian Security. The blast radius of a misconfigured agent identity is a live number in production systems right now, not a slide in someone's risk deck.

RBAC for AI agents: why capability-scoped permissions replace role-based ones

RBAC was built for human job functions, where a person is a "reader" or an "admin" of some system and that label roughly maps to what they actually do all day. Agents have tasks, not job functions, so the permission model has to match: the right to call one specific API endpoint, invoke one specific tool, read one specific class of resource. Not membership in some broad role that was designed with a person in mind from the start and never redesigned since.

The structural failure mode is excessive privilege accumulation. Agents routinely get handed far more access than the actual workflow needs, and every extra permission is one more way the blast radius widens if that agent gets compromised, or talked into doing something it shouldn't. IBM's 2025 Cost of a Data Breach Report found that nearly all organizations reporting an AI-related security incident had no proper AI access controls in place. That's nearly the whole sample. This is not an edge case.

The fix doesn't require building a new permission system from scratch. Tying agent permissions to identity provider groups that already exist, Okta groups, Entra ID security groups, reuses infrastructure security teams already know how to audit. For MCP servers, RBAC enforcement belongs at the gateway layer: every tool call gets checked against the calling identity's actual entitlements before it reaches the server, instead of being waved through just because authentication succeeded. This also does quiet, useful work against prompt injection. An agent that physically cannot pull data outside its defined scope can't be turned into a weapon for doing so, even when a bad instruction slips through everything upstream of it.

What ungoverned AI tool access actually costs: shadow AI as the identity failure mode

Any tool that never enrolls in SSO is invisible to the identity provider. It can't be audited, can't be revoked when someone leaves, can't have MFA enforced on it, because the IdP has no idea it exists. Without SSO in the loop, offboarded employees can keep access to AI platforms for six weeks or longer, simply because revocation depends on a human remembering to do it by hand.

Shadow AI carries a risk that ordinary shadow IT doesn't. What an employee types into a prompt can become training data for an external model the instant it's submitted, before any data-loss-prevention control gets a chance to act, and the data is already gone by the time anyone notices it's missing. Gartner found that 69% of organizations suspect, or have confirmed, that employees use prohibited AI tools. Suspicion isn't a control; it's an admission that the control doesn't exist. Netskope's 2026 data puts it even more starkly: 47% of generative AI users access these tools through personal accounts, sidestepping enterprise oversight entirely.

It costs real money, too. IBM's 2025 report found breaches involving unauthorized AI tools ran roughly $670,000 more, on average, than breaches that didn't involve them. Substitution is the fix that actually moves the needle. Healthcare Brew reported in 2026 that when organizations provide a governed, enterprise-grade AI tool as the sanctioned alternative, unauthorized use drops by 89%. People aren't sneaking around because they love risk; they're using whatever gets the job done fastest, and if the approved option is that option, they'll take it. Yet only 37% of organizations have any formal AI governance policy in place, per IBM's 2025 figures, which means most of the enterprise world is carrying this exposure without so much as a written policy to point to when someone asks.

How a governed identity layer for AI tools is built in practice

None of this gets solved by one product bought off a shelf. It's a set of integration points, stitched together, each one closing a gap the earlier sections already named. Start with the identity provider as the single source of truth: every AI tool, browser-based or API-native, authenticates through Okta, Entra ID, or an equivalent, and nothing reaches production without an enrollment record behind it.

From there, the protocol assignment follows the pattern already laid out: SAML for existing browser-based enterprise AI platforms, OIDC for SaaS-native and developer tools, client credentials or JWT assertions for agents and MCP servers. SCIM 2.0 handles the lifecycle piece, pushing provisioning and deprovisioning from the HR system out to every enrolled AI tool automatically, which is how that six-week offboarding gap collapses down to something close to zero. Token lifetime enforcement, short-lived access tokens, rotating refresh tokens, gets applied evenly across every OIDC-enrolled tool instead of left to whatever each vendor defaults to. Capability-scoped permissions stay tied to identity provider groups that already exist, rather than spawning a second, parallel permission system nobody remembers to update six months from now.

For MCP servers specifically, the gateway layer does the heavy lifting. It checks incoming identity, enforces RBAC on every tool call, propagates user identity downstream through token exchange, and logs each request for audit, the same job an API gateway has always done for REST APIs, just pointed at a newer kind of traffic. Real-time controls need to sit outside the model itself, not buried in a system prompt where they're one clever jailbreak from being ignored: PII tokenization before prompts reach a third-party model, prompt injection detection on the way in, secret and credential scanning on the way out.

Speakeasy's AI control plane is built around this exact shape of problem. It connects AI agents and MCP servers to enterprise systems through a single governed layer, enforces RBAC tied directly to Okta and Entra ID, catches shadow AI and prompt injection attempts as they happen, and surfaces cost and usage telemetry so the identity team finds out about a rogue tool before finance does, not three months after. Done this way, governed rollout is the fastest path to shipping AI tools that work and that someone can still explain to an auditor without flinching.