SSO and SCIM Provisioning for AI Agent Identities

What SSO and SCIM were built to do, and what an AI agent is

SSO exists to solve one problem: a person authenticates once, and a federated token from a central identity provider carries that trust across every connected service. No re-entering passwords, no separate logins per app. It was built around a human sitting at a keyboard, starting a session, and eventually walking away from it.

SCIM solves something related but different. It's a REST API standard that automates the tedious, error-prone parts of identity management: onboarding a new hire, syncing their attributes across systems, cutting off access the day they leave. Also built with a human employee in mind, start to finish.

An agent is neither of those things. It's a software process that invokes tools, holds credentials, and takes actions, often with nobody watching the session in real time. Structurally, it needs an identity to authenticate as, a defined scope of what it can touch, a lifecycle with a beginning and an end, and a record of what it did: the same things a human needs. The needs rhyme. The execution doesn't automatically translate, and that mismatch is where most implementations start to leak.

Non-human identities now outnumber human users across most enterprise environments, sometimes by a factor of 25 to 50, and that population grew 44% between 2024 and 2025. The industry's default response has been to bolt SSO and SCIM onto agents and call it solved. That instinct gets the first half right and skips the hard part. SSO and SCIM handle authentication and provisioning well, but neither one governs what an agent actually does once it's holding a valid token, and that gap is exactly where the damage happens. 85% of IT teams say every agent in their environment is accounted for. Only 42% can name who actually owns each one, and 68% of IT security incidents now involve machine identities, a figure that reflects how far the ownership gap has already spread.

Where SSO maps cleanly onto agent authentication

This part works without much argument. Tie an agent's identity to the enterprise IdP instead of a hardcoded API key sitting in a config file, and everything downstream gets simpler and safer. Centralized token issuance means one place credentials come from, one place they get revoked, one place an auditor actually looks.

OAuth 2.1 is what makes this practical for agents specifically. SSO-issued tokens flow into agent workflows through OAuth 2.1, with a resource server acting on behalf of an agent protocol and the enterprise IdP acting as the authorization server. Enterprises already understand this division of labor from years of web app authentication, so nothing here demands new mental models.

The July 2026 update to the MCP spec tightened things further. MCP servers are now formally OAuth 2.1 resource servers, full stop. Resource Indicators, defined in RFC 8707, provide the mechanism to ensure a token minted for one MCP server can't get replayed against another. That single requirement shuts down a token-confusion problem that would otherwise let a compromised or misdirected token wander into systems it was never meant to touch.

OAuth 2.0 Protected Resource Metadata, defined in RFC 9728, gives a client a way to figure out on its own which authorization server it should be talking to. None of this required inventing new SSO infrastructure. Existing enterprise identity providers slotted into these roles without modification, which says a lot about how well SSO actually fits this problem.

Where SCIM maps onto agent provisioning and lifecycle management

Skipping a provisioning standard leaves agent credentials scattered off-directory: buried in config files, dropped into environment variables, spun up as one-off secrets nobody tracks. Visibility disappears fast, and governance disappears right behind it.

Enterprise SCIM provisioning closes that gap by giving agent identities the same centralized lifecycle management humans already get: onboarding, attribute sync, access auditing, clean deprovisioning, just aimed at non-human identities instead of employees.

The clearest sign this mapping is being taken seriously is an IETF draft, draft-abbey-scim-agent-extension-00, published October 16, 2025, by M. Abbey and R. S. Cohen at Okta. It extends the SCIM 2.0 model specifically to cover AI agents and the applications that host them, adding new resource types and schemas built for agentic constructs rather than forcing agents to awkwardly impersonate human user objects.

The draft introduces new resource types and schema attributes designed around agentic constructs, covering things like role assignments, group membership, application trust relationships, and access recency, giving security teams the structured data they need to flag stale access before it becomes a liability nobody remembers granting.

Where these frameworks break when applied to agents without modification

Human SSO rests on an assumption that quietly falls apart with agents: that a person is present who can consent, in the moment, to what's being authorized. Delegated authorization flows depend on that real-time back-and-forth. An agent acting alone, mid-task, with no one watching the session, has nobody to hand that consent to.

Delegation is the second crack, and it's the one most teams underestimate. Agents routinely need to act on a user's behalf across several downstream services in sequence, not just one. Standard OAuth token issuance was never built for multi-hop, attenuated delegation, where each hop is supposed to carry less authority than the last. An explicit extension is needed for this, or an agent can end up holding more power three services downstream than it should have ever been granted. Without deliberate scope attenuation at each hop, chained delegation can leave a downstream agent holding more authority than was ever intended.

SCIM's limit is subtler. It provisions the right to an identity. It doesn't hand over that identity's actual working credential. Workload identity systems like SPIFFE get their credentials through a completely separate mechanism, and SCIM doesn't bridge that gap on its own. Two systems, two sources of truth, and coordination somebody has to build by hand.

The deepest gap is runtime. SCIM governs who gets access, when, and for how long, and it stops there. It says nothing about what an agent does once it has that access, tool call by tool call, and most enterprises haven't built anything to cover that layer yet.

The threat landscape that fills the gaps SSO and SCIM leave open

None of this is theoretical. Tool poisoning is already a measured attack pattern: a malicious MCP server crafts tool-response payloads designed to steer a model's output toward something it shouldn't do. Research from Wang et al. clocked a mean attack success rate of 73% in testing, and security scans have found roughly 5.5% of live MCP servers already showing tool-poisoning behavior. One in twenty, running right now.

Prompt injection is worse, and growing faster than almost anything else in the field. HackerOne's 9th Annual Hacker-Powered Security Report clocked a 540% surge in prompt-injection vulnerabilities and named it the fastest-growing threat category in AI security.

Cross-server tool shadowing gets less attention, but it's no less real: one MCP server redefines tools that technically belong to a different server, letting it intercept sensitive operations meant for somewhere else. It's a structural flaw in how tool namespaces resolve, not an exotic edge case.

Then there's the exposure that makes everything else worse. An internet scan found at least 1,862 publicly accessible MCP instances answering unauthenticated requests. SSO only helps where authentication is required in the first place, and an open door doesn't care how good the lock is on the door next to it.

A complete implementation: layering runtime controls on top of SSO and SCIM

Get the foundation right first. Register every agent as a first-class identity in the enterprise IdP, never as a service account quietly sharing credentials with a human. Let SCIM provisioning, informed by the agent-specific extensions under active IETF development, handle onboarding, attribute sync, and deprovisioning automatically instead of by hand. Run every agent interaction on short-lived, scoped OAuth 2.1 tokens instead of a long-lived API key sitting in a config file waiting to get found. Enforce PKCE on every client-side agent flow, mandatory in the MCP spec since November 2025.

Delegation needs its own layer on top of that foundation. Token-binding or attenuated delegation should guarantee that when an agent acts on a user's behalf, the downstream token carries reduced scope, not inherited scope. Resource Indicators, defined in RFC 8707, stop a token minted for one MCP server from getting accepted by a different one. Least privilege has to get enforced twice: once at provisioning, and again at runtime, because whatever SCIM grants should function as a ceiling, never a floor.

Runtime control is where identity alone runs out of road. Every tool invocation needs checking against the agent's provisioned permissions in real time, not validated once at session start and forgotten after. Sensitive operations call for JIT (just-in-time) credential issuance, a credential that exists only long enough to finish one task before it disappears. Threats like tool poisoning, prompt injection, and intent drift need active behavioral monitoring on top of that, because access control by itself can't see any of them coming.

None of this means much without traceability. Every action an agent takes should tie back to a tamper-proof audit log stamped with that agent's provisioned identity. Full OpenTelemetry (OTEL) tracing across multi-agent workflows keeps cross-agent actions traceable end to end, instead of letting them vanish into a black box the moment one agent hands work to another. And the access-recency tracking that the SCIM agent extension draft is designed to enable should be doing real work here too, flagging stale access automatically before an unmanaged credential shows up later in a breach report.

What the evolving standards landscape means for teams building this now

Not everything here is settled. A good chunk of it already is, though, and that's what teams should build on now instead of waiting for the rest to catch up.

OAuth 2.1 with PKCE is safe ground: formally aligned with the July 2026 MCP spec update, and every major identity provider already supports it. SCIM 2.0's core protocol is mature and broadly implemented across the industry, and while the agent-specific extensions remain in draft form, the base protocol underneath them is production-grade and already battle-tested. OpenID Connect, for federated identity across organizational boundaries, is stable too and running at enterprise scale already.

The agent-specific layer, the SCIM extensions, the delegation semantics, the runtime governance patterns, is still being written in real time. That's an argument for building on the parts that are solid now, not for waiting around, and staying close enough to the standards work to adopt the rest as it lands.