SCIM for AI extends lifecycle control to agent identities

At a glance

What this is: The draft extends SCIM to AI agents and agentic applications, giving non-human identities standard lifecycle objects, ownership, and token correlation.

Why it matters: It matters because IAM teams need a consistent way to provision, review, and deprovision agents alongside human users, especially as non-human identities spread across enterprise apps.

👉 Read WorkOS's article on SCIM for AI and agent provisioning

Context

SCIM for AI identity management starts with a simple problem: today, many AI agents and automation bots are provisioned outside the same lifecycle controls used for people and service accounts. That creates gaps in ownership, deactivation, auditability, and runtime traceability when the identity subject is not human.

The draft tries to close that gap by adding first-class agent resources to SCIM rather than inventing a separate provisioning model. For IAM, NHI, and platform teams, the operational question is whether current directories, access reviews, and offboarding processes can represent an agent cleanly enough to support revocation, accountability, and investigation.

Key questions

Q: How should security teams govern AI agents in SCIM-based environments?

A: They should model agents as first-class identities with owners, lifecycle state, and credentials tied to the same governance process used for other non-human identities. That means provisioning, review, suspension, and deprovisioning must all be traceable to a named accountable party, not buried inside an application-specific automation stack.

Q: Why do AI agents complicate existing identity governance workflows?

A: Because many identity programmes were built around human users or static service accounts, not entities that can move across applications, protocols, and credentials. Once an agent can act through multiple surfaces, teams need a consistent way to track ownership, scope, and revocation across the full lifecycle.

Q: What breaks when agent identities are managed like ordinary users?

A: You often lose the distinction between the human account and the digital worker it represents, which weakens auditability and can obscure runtime access paths. That makes offboarding, investigation, and entitlement review harder, especially when tokens, certificates, and app memberships are stored in different systems.

Q: How do organisations keep legacy SCIM systems usable for agent governance?

A: They should define a fallback mapping that preserves agent meaning even when a system only understands User resources. The key is to keep lifecycle actions, ownership, and correlation data intact so the agent can still be deactivated, reviewed, and traced without losing identity context.

Technical breakdown

SCIM resource modeling for agents and agentic applications

The draft introduces two new SCIM resource types, Agents and AgenticApplications, so a non-human worker and the platform that hosts it can each have their own identity record. That matters because SCIM was designed around users and groups, but agent governance needs separate objects for the worker, its host application, its owners, and its entitlements. The schema also preserves familiar SCIM patterns such as filtering, external IDs, and lifecycle state through an active flag. In practice, this turns AI agents into managed directory objects rather than application-specific records.

Practical implication: inventory which agent-like systems still live outside SCIM so you can decide where standard provisioning can replace custom logic.

Ownership, certificates, and protocol metadata in NHI governance

The draft adds ownership references, x509Certificates, roles, entitlements, and protocol metadata to the agent model. That is not just bookkeeping. It creates a machine-readable link between the identity, the human or group accountable for it, and the credentials or protocols used at runtime, including OpenAPI, A2A, and MCP-Server. This is classic NHI governance extended to AI agents: credentials can be rotated or revoked, but only if the identity record carries enough structure to bind those controls to the right subject.

Practical implication: align agent credential inventory, ownership, and rotation workflows so every runtime credential can be traced back to a named owner.

Token correlation and lifecycle fallback for legacy SCIM systems

The subject attribute is the bridge between provisioning and authentication because it lets inbound tokens map back to the SCIM agent record. If a platform cannot support the new agent objects, the draft proposes falling back to a User resource with LinkedObject metadata so older systems can still manage lifecycle events. That compatibility layer is useful, but it also reveals the transitional state of the market: many programmes will have to govern agents before every directory, IdP, and app can speak the same schema.

Practical implication: define a fallback mapping for agent identities now so deactivation and audit trails still work when downstream systems lag the spec.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SCIM for AI is really a lifecycle governance problem, not a protocol novelty. The draft matters because it gives IAM teams a standard way to represent agent identities, but the deeper shift is that agents can now be governed through the same joiner-mover-leaver logic used for people and other NHIs. That changes how entitlement review, offboarding, and accountability should be designed across the stack. Practitioners should treat the draft as a lifecycle anchor, not just a schema update.

Owner-of-record is the control that makes agent governance auditable. The draft’s owner references turn an otherwise ambiguous digital worker into an identity with explicit accountability, which is the missing prerequisite for review and incident response. Without that reference, agent access becomes hard to challenge, hard to revoke, and even harder to assign after the fact. Practitioners should make owner assignment a mandatory onboarding condition for every agent identity.

Credential and protocol sprawl is the hidden risk SCIM for AI exposes. By allowing certificates, entitlements, and protocol declarations inside the identity model, the draft acknowledges that agents will authenticate and communicate through multiple channels at once. That expands the surface area for stale certificates, overbroad entitlements, and inconsistent revocation across systems. Practitioners should expect governance failures where agent identity data is split across directories, secrets stores, and application-specific metadata.

SCIM compatibility will determine whether agent governance scales or fragments. The LinkedObject fallback is a useful bridge, but it also signals that many environments will continue to treat agents as users until their downstream systems catch up. That creates a governance bifurcation between systems that understand agent semantics and systems that only understand human-shaped records. Practitioners should plan for dual-path lifecycle handling until directory, IAM, and application support converges.

SCIM for AI will accelerate standardisation, but it will also expose weak NHI operating models. Once agent identities are represented consistently, gaps in ownership, stale access, and runtime correlation become easier to see. That is good for governance and uncomfortable for programmes that have relied on ad hoc bot management. Practitioners should use the draft as a forcing function to unify how human, machine, and agent identities are lifecycle-managed.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• For a broader governance lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle patterns that also apply to agents once SCIM can represent them.

What this signals

Agent governance will move from bespoke automation handling to standard lifecycle operations. Once SCIM can represent agents and agentic applications, programmes that still treat them as app-specific scripts will expose avoidable blind spots in ownership, offboarding, and audit correlation. The practical signal is to normalise agent records now rather than wait for every downstream system to catch up.

SCIM for AI creates a governance boundary between identity data and runtime behaviour. The identity record can become authoritative for ownership, credentials, and active state, but only if teams keep that record in sync with secrets stores and application logs. That makes identity lifecycle discipline the control plane for agent accountability.

At scale, the problem is not just more agents, but more unmanaged agent relationships. In our research, 98% of companies plan to deploy even more AI agents within the next 12 months, yet only standardised identity models will make that growth governable. Use OWASP NHI Top 10 and NIST AI Risk Management Framework guidance to frame how those relationships should be bounded.

For practitioners

• Map agent identities into your SCIM lifecycle model Identify every AI assistant, automation bot, and agentic application that currently sits outside SCIM. Decide whether it should be represented as a dedicated agent object, a fallback linked user object, or a temporary exception until downstream support exists.
• Make owner assignment mandatory for every agent Require a named human or group owner before an agent can be activated. Tie that ownership to access reviews, incident response routing, and deactivation approval so accountability survives runtime delegation.
• Bind credentials to the identity record, not the app wrapper Track certificates, tokens, and protocol metadata in the same governance workflow as the agent record. That lets you revoke access when the identity changes state instead of hunting for scattered secrets in separate systems.
• Test your fallback path for legacy directories If a target system cannot consume Agent and AgenticApplication resources, define how LinkedObject metadata will preserve meaning and how deactivation will propagate. Validate that audit logs still identify the agent, the owner, and the host application.
• Review stale agent detection as part of lifecycle hygiene Use last-accessed timestamps and inactivity thresholds to find agentic applications and dormant agent relationships that no longer have a business purpose. Remove or suspend those identities before they accumulate standing access.

Key takeaways

• SCIM for AI turns agents into governable identities, not just application logic.
• Accountability, credential binding, and lifecycle state are the controls that make agent identities auditable.
• Identity teams should prepare for a transition period where legacy systems need fallback mappings for agents.

Key terms

• Agent Identity: An agent identity is the managed record for a non-human entity that can authenticate, act, and be governed across systems. In SCIM terms, it needs canonical identity data, lifecycle state, and ownership so teams can provision, review, and revoke access without treating the agent as an anonymous script.
• Agentic Application: An agentic application is the platform or system that hosts, exposes, or authorises one or more agents. It is separate from the agent itself, which lets identity teams model where the worker lives, who controls it, and which applications or APIs it can reach.
• LinkedObject Metadata: LinkedObject metadata preserves meaning when a system cannot natively represent an agent resource. It gives downstream tools a way to recognise that a user-shaped record actually stands for a non-human identity, which helps keep deactivation, audit, and correlation intact during transition periods.
• Token Correlation: Token correlation is the process of matching a runtime authentication token to the provisioned identity record that owns it. For agents, this closes the gap between directory state and live access, making it easier to trace API calls, enforce inactive status, and investigate behaviour.

Deepen your knowledge

SCIM for AI identity management and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a provisioning model for agents alongside human and machine identities, it is worth exploring.

This post draws on content published by WorkOS: SCIM for AI: Inside the new IETF draft for agent and agentic application provisioning. Read the original.