[scim] Re: [EXTERNAL] SCIM for AI Agents: Use Cases for Discussion

[jim pasquale <[e-mail]>]

+1 Pam, spot on.

> On Apr 14, 2026, at 4:26 PM, Pamela Dingle <Pamela.Dingle=[e-mail]> wrote:
> 
> Hi all,
> 
> My current thoughts (fwiw) on the use cases are as follows:
> 
> We can't not do #1.  While many kinds of agents will be counted and authenticated as workloads, it is highly likely that some agents will be counted and authenticated as if they were humans.  The canonical example here is the "digital co-worker" construct - human co-workers may wish to assign work to, authorize, or communicate with a digital co-worker in all the same ways they collaborate with fellow humans.  That means that the digital co-worker will need to be populated in people pickers, email autofills, and other historically directory-backed UX elements across multiple cross-domain resources.  Any of those kinds of elements that are SCIM backed will need to "just work".  This puts implementers between a rock and a hard place right now because the only option that doesn't break all the interfaces would be to use the User resource type for agents.  We as a working group need to decide how agents can co-exist in situations where the standing presumption has been that non-human entities are never part of active collaboration.  
> Use case #4 should be complimentary with work on agent cards here:  https://github.com/Agent-Card/ai-card/pull/27.  It may be that SCIM aligns with agent card schema for attribute naming.  It could be that a reference to the card becomes a standardized attribute within a SCIM agent resource.  
> Use case #7 could be a good option for applying a lightweight abstraction layer over multiple agent registries.  Managing every phase of available, approved and instantiated agents across multiple registries is going to look an awful lot like a meta-directory problem.  If there are other standardization efforts here it would be great to catalog them.
> 
> I am 100% in support of "less is more" - the sooner we make a proposal the sooner we can get feedback from those who are expecting to represent agents in existing traditional UX situations.  
> 
> Cheers,
> 
> Pam
> 
> From: Ismael Kazzouzi <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, April 2, 2026 9:10 AM
> To: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; Pamela Dingle <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; Mark Wahl <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] SCIM for AI Agents: Use Cases for Discussion
>  
> You don't often get email from [e-mail] <mailto:[e-mail]>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>	
> Hi all,
> 
> Following the productive discussion at IETF 125 <https://www.youtube.com/watch?v=ACBw_p2ZhCE>, the SCIM Agentic Schema workstream (Pam Dingle, Macy Abbey, Mark Wahl, Danny Zollner and Ismael Kazzouzi) is working toward a consolidated draft. Before we bring that draft forward, several participants rightly emphasized that well-defined use cases and clear terminology should come first. 
> 
> This email is that step: start with the problem, keep the initial scope narrow, and define what we mean. So below we lay out the use cases we're considering and invite the group to challenge, refine, or add to them.
> 
> Feedback reminder from the session:
> 
> "Use cases first, draft second". Multiple participants (Bjorn, Justin, Grace, Chris) emphasized that well-defined use cases and clear terminology must come before a specification draft.
> "Less is more". Macy (via chat) cautioned against feature creep in the initial draft.
> Durability concern. SCIM has natural latency; whether it fits very ephemeral agent instantiations is an open question.
> Class vs. instance. Is SCIM representing the agent template/class or a specific running instance? Remains unresolved.
> 
> 
> Terminology (Working Definitions)
> 
> For the purpose of these use cases, we use "agent" broadly to mean a non-human software entity that acts autonomously or on behalf of a user, and that requires identity, lifecycle management, or access governance beyond what OAuth client registration alone provides. We intentionally avoid a narrow definition at this stage. The use cases below are meant to stress-test where the boundaries should be.
> 
> We also distinguish:
> Agent class: a template or type of agent that can be instantiated (e.g., "Acme Travel Assistant v2")
> Agent instance: a specific running instantiation of an agent class, bound to a context (e.g., a particular user's session or a particular Kubernetes pod)
> 
> Whether SCIM should model one or both is an open question we'd like input on.
> 
> 
> Use Cases
> UC1: Agents Participating in Existing IAM Systems
> Autonomous agents that request privileges and act as primary actors in enterprise systems should participate in existing SCIM-based identity and access transactions alongside users but must be distinguishable from them.
> 
> An enterprise manages access to shared resources (document repositories, cloud projects, APIs) through groups provisioned via SCIM. When an agent needs access to one of these resources, an IDP administrator adds the agent to the same access group that governs human access. The group now contains both human and agent members. Administrators list, audit, and manage membership uniformly regardless of member type. The agent goes through the same approval workflow as a user. At the same time, compliance teams can filter group membership by resource type to answer questions like "which agents have access to our production environment?" or "how many non-human identities hold admin privileges?"
> 
> Without a standardized agent resource type, organizations represent agents as pseudo-users,  mirroring the legacy Active Directory service account pattern and therefore losing the ability to distinguish them. This leads to audit blind spots, policy gaps (e.g.,  no way to enforce "agents may not hold break-glass admin roles" at the resource-type level), lifecycle failures when agent decommissioning doesn't follow the same workflows as user offboarding, and governance sprawl as separate systems are built to  manage agent access alongside SCIM-managed user access.
> 
> Why SCIM: Groups already support heterogeneous member types, and the $ref and group.members.type sub-attributes allow identifying the resource type of each member. A standardized agent resource type means agents can be provisioned, added to groups, governed, and audited through the same SCIM pipeline used for users while remaining distinguishable at every layer.
> 
> UC2: Enterprise Agent Fleet Provisioning
> An enterprise deploys a fleet of AI agents (e.g., an HR assistant, a sales copilot, an IT support bot). The identity team needs to provision these agents into target SaaS applications through the same IDP and SCIM pipeline they already use for users.
> This includes creating the agent identity, assigning it to groups that control resource access, and eventually disabling or removing it.
> 
> SCIM client: Identity Provider (e.g., Entra ID, Okta)
> SCIM service provider (server): Target SaaS application (e.g., Atlassian, Salesforce)
> 
> Why SCIM: Reuses existing provisioning infrastructure. The agent lifecycle (create, update, disable, delete) mirrors user lifecycle operations that SCIM already handles.
> 
> UC3: Agent-to-Person Entitlement Relationships
> An enterprise wants to control which users a specific agent can act on behalf of, and with what level of access. For example: 25 people are entitled to use GitHub Copilot within a GitHub EMU organization. Of those 25, only 10 should have Copilot act on their behalf when accessing data in Atlassian. And within those 10, the entitlements may differ per user: user 1 gets readWrite to Confluence, user 2 gets readOnly to Jira.
> 
> This raises the question of how these relationships are represented. Is this tracked on the agent resource, on the user resource, or on some other resource type? Is this an entitlement model where the agent has entitlements to operate on users' behalf, or where users have entitlements to interface with agents? These are open questions we'd like input on.
> 
> When a user leaves the organization, any agents entitled to act on their behalf must be discoverable and the relationship must be decommissioned as part of offboarding.
> 
> SCIM client: Identity Provider or Identity Governance system
> SCIM service provider: Application that hosts the agent or the resource being accessed
> 
> Why SCIM: SCIM already models relationships between resources. Extending this to agent-user entitlement relationships enables governance over who an agent can act for and with what scope.
> 
> UC4: Agent Protocol Discoverability
> An enterprise has provisioned several agents from different vendors. A consuming system or another agent needs to discover what protocols a given agent supports (e.g., A2A, MCP, SPIFFE, OAuth) and how to reach it. The agent's SCIM record could include or reference metadata such as an agent card URL, supported protocol identifiers, or endpoint URIs.
>  SCIM client: Identity Provider provisioning agent metadata
>  SCIM service provider: Agent registry, application directory, or agent runtime platform
> 
> Why SCIM: SCIM is already the system of record for identity metadata. Adding discoverable protocol capabilities avoids building a parallel discovery mechanism for agents that are already provisioned via SCIM.
> 
> UC5: SPIFFE-Based Workload Identity Provisioning
> Consider an organization uses SPIFFE for workload attestation; when the administrator approves a new AI agent for deployment, the agent's SPIFFE registration entry (SPIFFE ID, attestation selectors such as k8s labels, cloud metadata, image hashes) needs to be provisioned into the SPIFFE server (e.g., a SPIRE server or a Workload Identity Provider).
> The enterprise wants to manage this through the same SCIM pipeline used for users and OAuth clients, rather than maintaining a separate provisioning system. This is explicitly a human/admin-controlled process. It applies in scenarios where template-based or federation-based approaches are not desirable. For instance, when an organization needs fine-grained administrative control over which agent  identities are registered, based on real-world customer requirements for compliance or policy enforcement.
> The provisioning can occur within a single trust domain (admin provisions an agent identity into their own SPIFFE server) or across trust domains (admin provisions an agent identity from an external partner into a federated SPIFFE trust domain). It is important to distinguish between provisioning a registration entry (the right to an identity, including its attestation selectors) and provisioning a template (a reusable pattern from which multiple registration entries can be created). Both may be valid use cases, and we'd like input on whether SCIM should support one or both.
> SCIM client: Identity Provider or Identity Governance platform (the admin-facing system)
> SCIM service provider: SPIFFE server / SPIRE server / Workload Identity Provider (WIDP)
> Why SCIM: SCIM provisions the right to an identity (the registration entry), not the credential itself. SPIFFE issues credentials at runtime after attestation. This cleanly separates provisioning from credential issuance and tests the extensibility  of the agent schema to non-OAuth identity models. SCIM doesn't replace SPIRE's registration API -- it sits in front of it.
> 
> UC6: Fleet-Wide SPIFFE Selector Update on Infrastructure Change
> An organization has 200 agents registered as SPIFFE workloads, each with attestation selectors tied to their deployment environment (e.g., Kubernetes namespace labels, cloud instance metadata, container image hashes). An infrastructure change occurs: the team migrates from one Kubernetes cluster to another, or rotates to a new set of signed container images. The SPIFFE identities remain the same, but the attestation selectors that prove "this workload is who it claims to be" must be updated across the entire fleet. Without this update, agents will fail attestation at runtime and lose their credentials.
> SCIM client: Identity Provider or infrastructure automation platform
> SCIM service provider: SPIFFE server / SPIRE server / Workload Identity Provide.
> Why SCIM: This is a bulk update operation on provisioned identity metadata; exactly the kind of operation SCIM is built for. An IDP can issue a SCIM PATCH across the affected agent entries to update selectors without touching the SPIFFE IDs or disrupting the agents' logical identities. Doing this through a unified SCIM pipeline avoids the need for operators to script directly against SPIFFE server APIs or maintain a separate bulk-management tool for workload identity.
> UC7: Agent Governance and Status Tracking
> Before an agent is activated in an enterprise, it must go through an approval workflow. The enterprise needs to track agents that are pending approval, approved but not yet instantiated, active, suspended, or disallowed by policy. This goes beyond the binary active/inactive model used for users.
> SCIM client: Identity Governance platform
> SCIM service provider: Agent registry or application directory
> Why SCIM: Governance and status tracking are lifecycle operations. Rather than building a separate governance system for agents, extending SCIM's existing model keeps agent management unified with user management.
> 
> We welcome all feedback on the mailing list. If you'd like to join the workstream meetings, reach out to any of us directly.
> 
> Best,
> Pam, Danny, Macy, Mark, Ismael
> 
> _______________________________________________
> scim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]