Non-human identity governance: Where SCIM fits (and where it doesn't)

Ask most security teams how many employees they have and they'll give you a number within a few seconds. Ask how many API keys, service accounts, and AI agents have standing access to their systems, and the honest answer is usually "we don't actually know."

That gap has a name now. Non-human identity, or NHI, has become its own security category in the last year, with its own dedicated OWASP Top 10 and a growing set of vendors building products around exactly this problem. The number getting cited most often is stark: something like 91 percent of organizations are already using AI agents in some form, while roughly 10 percent have any real governance over them. Most companies have already crossed the line from "a few service accounts we manage by hand" to "an identity sprawl problem," and most haven't noticed yet.

SCIM is built for exactly this kind of lifecycle problem, and it's tempting to assume it just extends cleanly to non-human identities. It mostly does, but not entirely, and the gap matters.

Why this isn't just "more users"

Human identity has a built in lifecycle that most organizations already enforce reasonably well. Someone joins, HR creates a record, IT provisions access. Someone leaves, HR terminates the record, access gets revoked. Even when this process is slow, it's at least a process, with a clear trigger and a clear owner.

There's a term for the discipline that exists for humans and is largely absent for machines: user lifecycle management, or ULM, the process of managing a user's access to an app from onboarding until they're removed. ULM is well established for employees. It barely exists for machines.

Non-human identities don't follow that pattern.

A service account doesn't hand in notice. An API key doesn't get flagged in an HR system when the project it was created for ends. An AI agent can spin up sub-agents to complete a task, each one inheriting some version of its permissions, with no equivalent of an org chart tracking who reports to whom. A single new integration can mint several credentials during setup and never revisit any of them again. The result is that non-human identities multiply faster than human ones, expire less predictably, and are far less likely to show up in a routine access review, simply because nobody set up a routine for them in the first place.

This isn't a hypothetical risk. Machine credentials and service accounts have been behind a meaningful share of major breaches for years, precisely because they tend to be long lived, broadly scoped, and unmonitored compared to human accounts protected by MFA and conditional access policies.

Where SCIM actually helps

The core problem SCIM solves for humans, standardized lifecycle management across systems, is exactly the same shape of problem non-human identities have. Creating, updating, and deactivating a service account or an agent identity is a legitimate use of SCIM's existing provisioning model, and applying it consistently is one of the more practical steps an organization can take today.

Treating a service account like any other SCIM managed identity gets you a few things immediately: a defined creation event instead of an ad hoc one, an owner of record instead of an orphaned credential, and a deactivation path that doesn't depend on someone remembering the account exists. SCIM's group model also carries over more directly than it might seem. The same grouping mechanism that lets a directory provider categorize human employees by team, like putting every engineer under an "Engineering" group, works just as well for segmenting service accounts and agents by system, team, or risk tier, instead of treating every non-human identity as one undifferentiated pool. For the subset of non-human identity that behaves like a slower moving, longer lived version of a human account, which describes a lot of service accounts and integrations, SCIM's existing model is a reasonable fit without waiting for anything new.

Where SCIM runs out of road

Where it gets harder is anything that doesn't fit the "long lived account with a fixed role" shape, which increasingly describes AI agents.

SCIM has no native concept of scoped, resource level permissions. It can tell a system that a user or service account exists and what group it belongs to, but it has no standard way to express "this agent can read from this specific data source for the next four hours and nothing else," which is closer to the access pattern agents actually need.

SCIM also has no standard story for credential rotation. Human accounts are protected by passwords that expire, MFA, and session policies. Non-human credentials are frequently static API keys that get created once and never rotated, and SCIM's schema doesn't address that gap at all.

And, as covered in more detail in our piece on SCIM's agentic identity drafts, there's currently no finalized way for SCIM to represent an agent's identity as something distinct from a human user or a generic service account. Multiple proposals are competing to define this, and none is stable enough to build against yet.

This is where SCIM hands off to other standards rather than solving the whole problem itself. Workload identity frameworks like SPIFFE are designed specifically for short lived, cryptographically verifiable machine identity. OAuth based approaches handle scoped, time limited authorization in a way SCIM's schema was never built for. The realistic picture isn't "SCIM versus these standards," it's SCIM covering lifecycle and directory sync while something like SPIFFE or OAuth covers the scoped, ephemeral access layer on top.

A quick way to check where you stand

Before reaching for a new tool or standard, it's worth answering a few blunt questions:

• Do you actually know how many non-human identities (service accounts, API keys, agents) have standing access to your systems right now, and would you find out about a change as it happens rather than during a periodic audit? Real time delivery of provisioning changes, through webhooks or an events API, is what makes the difference between the two.
• Do any of them expire automatically, or do they all persist until someone manually notices and removes them?
• Are they included in the same access reviews as human accounts, or do they live in a separate, less scrutinized process, if any process at all?
• If an integration or agent was deprecated six months ago, would its credentials still work today?

If most of those answers are uncomfortable, the fix usually isn't a new framework. It's applying the same discipline to non-human identity that most organizations already apply to human identity: a defined lifecycle, a clear owner, and a way to actually see what exists.

Where this is headed

Non-human identity governance is still an early, fast moving space, and the standards underneath it, SCIM included, are still catching up to how these identities actually behave in practice. For the lifecycle half of the problem, provisioning, deprovisioning, and keeping directory data in sync, that's solvable today with the tools already available.

WorkOS Directory Sync handles exactly that half for human identity, keeping user lifecycle in sync across every major IdP without you having to build and maintain the SCIM layer yourself. Agent identity is moving quickly, and it's an area we're actively building toward as the underlying standards mature. See how WorkOS handles identity provisioning.