Notifications
Clear all
Topic starter
07/06/2026 9:01 pm
TL;DR: A new IETF draft extends SCIM to AI agents and agentic applications, adding Agents and AgenticApplications resource types, owner references, certificates, protocol metadata, and token correlation so non-human identities can be provisioned and deprovisioned through standard identity workflows, according to WorkOS. That shift matters because lifecycle governance, accountability, and revocation now need to treat agents as managed identities, not informal automation.
NHIMG editorial — based on content published by WorkOS: SCIM for AI: Inside the new IETF draft for agent and agentic application provisioning
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map agent identities into your SCIM lifecycle model Identify every AI assistant, automation bot, and agentic application that currently sits outside SCIM.
- Make owner assignment mandatory for every agent Require a named human or group owner before an agent can be activated.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The exact SCIM resource shapes for Agents and AgenticApplications, including example payloads and schema fields.
- The compatibility fallback using LinkedObject metadata when a SCIM server cannot support new agent resources.
- The proposed attribute model for owners, roles, entitlements, certificates, and protocol references.
- How the subject attribute can correlate runtime tokens back to a provisioned agent identity.
👉 Read WorkOS's article on SCIM for AI and agent provisioning →
SCIM for AI and agent identities: what changes for IAM teams?
Explore further
08/06/2026 8:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SCIM for AI extends lifecycle control to agent identities
