Non-Human Identity Governance: What SCIM Can and Can't Do

The Identity Management Crisis No One Is Talking About

Most organizations today have more AI agents and service accounts than they have employees — and almost none of them are properly governed. This is a security and compliance blind spot that is being widely overlooked. While enterprises pour significant effort into managing the identity lifecycle of human employees, non-human identities (NHIs) are quietly proliferating in the shadows, expanding the attack surface at an alarming rate.

With the rise of generative AI and automation, service accounts, API keys, machine identities, and AI agents are growing far faster than the human workforce. Every automation script, every integration, every AI assistant potentially maps to a set of credentials that carry real permissions. The problem is: who created them? What can they access? When should they be revoked? In most organizations, these questions go unanswered.

What SCIM Is — and Why It's Relevant to NHI

SCIM (System for Cross-domain Identity Management) is an open standard for automating the exchange of identity information between systems. It was originally designed to simplify the provisioning and deprovisioning of human user accounts across enterprise applications — when an employee joins or leaves, SCIM automatically syncs account creation or deletion across SaaS systems.

What SCIM Can Do for Non-Human Identities

Technically, SCIM doesn't distinguish between human and machine identities. A service account or integration account can be created, updated, and deleted via the SCIM protocol just like a human user account. This means SCIM can offer some non-human identities:

• A unified provisioning interface: Create and manage machine accounts across multiple systems in a standardized way
• Automated lifecycle synchronization: When an identity is disabled in the source system, automatically revoke it in downstream systems
• Auditable operation logs: Provide structured logging for identity creation and changes

For service accounts that exist as proper "accounts" and are managed by an identity provider (IdP), SCIM offers a ready-made governance path.

SCIM is built on REST architecture and uses JSON for data exchange. The current mainstream version is SCIM 2.0 (RFC 7642/7643/7644). Its core mechanism establishes a standardized "push channel" between an identity provider (IdP — such as Okta, Azure AD, or Ping Identity) and a service provider (SP — such as Salesforce, Slack, or GitHub): the IdP acts as the authority, sending HTTP requests to the SP to create (POST), update (PUT/PATCH), or delete (DELETE) identities, with the SP responding in a standard format. This "push-based" design differs fundamentally from "pull-based" directory sync — SCIM doesn't require the SP to periodically poll the directory, and changes can propagate in near real time. In enterprise deployments, SCIM is most commonly paired with SSO (Single Sign-On): SSO handles authentication, SCIM handles account lifecycle management, and together they form the foundation of IAM (Identity and Access Management) infrastructure.

Where SCIM Falls Short

SCIM's value is real, but its capabilities have clear limits. Treating SCIM as a complete solution for non-human identity governance leaves dangerous gaps.

The Credential Types It Can't Reach

A large number of non-human identities don't exist in the form of "user accounts" that SCIM can understand. API keys, OAuth tokens, TLS certificates, cloud platform IAM roles, Kubernetes service accounts — these machine credentials are typically managed natively by their respective platforms, operating entirely outside SCIM's scope. SCIM cannot discover them, let alone revoke them.

These credential types — the ones that fall outside SCIM's reach — are often the most numerous and the highest risk in practice. API keys are typically generated directly by developers in platform consoles, with no centralized issuance or revocation process, making "create and forget" scenarios extremely common. OAuth tokens present the problem of long-lived refresh tokens that can be exploited indefinitely if leaked. TLS certificates, if not brought under a centralized Certificate Lifecycle Management (CLM) system, may expire unnoticed — causing service outages or being replaced with weakly encrypted versions. Cloud platform IAM roles (such as AWS IAM Roles or GCP Service Accounts) have permission policies directly tied to infrastructure; if abused, the blast radius can cover an entire cloud environment. Kubernetes service accounts are a credential type unique to containerized environments, with tokens automatically mounted into Pods — if left unrestricted, they become easy pivot points for lateral movement. To address these types, the industry typically needs to introduce dedicated secrets management tools (such as HashiCorp Vault or AWS Secrets Manager) or cloud-native workload identity solutions (such as SPIFFE/SPIRE) to fill the governance gap.

It Can't See the True Boundaries of Permissions

SCIM focuses on the "existence" and "ownership" of an identity — not what an identity can do. A service account provisioned via SCIM may be granted far more permissions in the target system than it actually needs. SCIM has no understanding of the principle of least privilege and cannot evaluate whether an AI agent's actual permissions are appropriate. Permission governance requires dedicated entitlement analysis capabilities.

It Can't Handle Dynamic and Ephemeral Identities

Modern AI agents and cloud-native workloads are often ephemeral — they spin up on demand, are used, and then disappear, with lifecycles measured in minutes. SCIM is designed around a relatively stable account model and is poorly suited for these high-frequency, transient identity patterns.

The concept of ephemeral identity emerged from the evolution of cloud-native and zero-trust architectures. Traditional IAM assumes identities are long-lived, stable entities, and is designed around the slow cycle of "create — use — revoke." But in microservices, serverless functions, CI/CD pipelines, and AI agent frameworks (such as LangChain agents or AutoGPT derivatives), an "identity" may only exist for the duration of a single task execution — anywhere from a few seconds to a few minutes. The industry's response is to replace static credentials with dynamic credentials: workloads request short-lived tokens at runtime from a credential authority (such as Vault or a cloud provider's IAM STS), and once the task completes, the token naturally expires — fundamentally eliminating the risk of long-term credential exposure. The account model that SCIM depends on is incompatible with this approach, because it has no semantics for "token request" and "immediate expiry."

Building a Complete NHI Governance Framework

Once you understand SCIM's true role, the right approach is to place it within a larger governance framework — not to expect it to do everything on its own.

A complete non-human identity governance program requires at least several layers working in concert: a discovery layer that continuously inventories all machine credentials, wherever they exist; a classification and ownership layer that assigns a responsible owner and purpose label to every identity; a permission governance layer that evaluates and reduces over-provisioning; a lifecycle layer — where SCIM can genuinely contribute — that handles standardized provisioning and deprovisioning; and a monitoring and rotation layer that enforces regular rotation and anomaly detection for secrets, certificates, and other credentials.

In this framework, SCIM is a useful piece of the puzzle — but only one piece. The real risk lies in mistaking it for the whole picture. Organizations need to first gain full visibility into the non-human identities in their environment, then determine which ones SCIM can cover and which ones require dedicated machine identity management tooling to address.

Conclusion

The number of non-human identities has quietly surpassed the human workforce, while governance has fallen dangerously behind. SCIM provides a practical starting point — particularly for service accounts that exist as formal accounts and can be managed by an IdP. But it is powerless against API keys, tokens, certificates, and ephemeral AI agents, and it has no understanding of permission depth. Using SCIM where it excels, while honestly acknowledging its limits, is the rational posture for confronting this identity governance crisis.