# SCIM for AI, one year later: What's changed in the IETF agent identity draft > Source: > Published: 2026-09-30 00:00:00+00:00 # SCIM for AI, one year later: What's changed in the IETF agent identity draft A year ago, two competing IETF drafts were racing to define how SCIM represents AI agents. Here's what changed, and why the companies behind them are now writing one draft together. Back in October 2025, [we covered](https://workos.com/blog/scim-agents-agentic-applications) the earliest attempt to answer a question that didn't really exist a few years before it: how does SCIM represent an AI agent as an identity, the same way it already represents a human user? At the time, the honest answer was "nobody agrees yet." Two separate drafts were competing to define the shape of an agent resource in SCIM, and neither had settled the basic design questions. A year on, that's changed in a way worth revisiting. The two competing efforts have moved through a formal consolidation process, surfaced a genuinely hard design question in the process, and landed on a single draft with joint authorship from the same companies that were previously proposing separate answers. Here's what happened. ## Where things stood in October 2025 At IETF 124 in Montreal, two different drafts were on the table, each proposing a different way to represent agents as a resource type in SCIM. The first, from Okta's M. Abbey and R. S. Cohen, took an application centric approach. Rather than treating an agent as its own first class resource, it modeled agents as related to an "agentic application," with an explicit relationship type describing how the agent connects to that application: owned, authorized, or guest. The second, from Microsoft's M. Wahl, took a more direct approach: a platform neutral schema for representing an AI agent's identity itself in JSON format, transferable through the standard SCIM protocol, without routing everything through an application resource first. Both were reasonable answers to the same question. Neither was clearly winning, and the difference between them wasn't cosmetic. It was a real disagreement about whether an agent's identity should be modeled as its own thing, or as a property of the application it belongs to. ## What changed: consolidation, not just more competition By IETF 125 in March 2026, the working group had moved from "two competing drafts" to an explicit, named consolidation effort, tracked as its own agenda item rather than left to resolve informally between authors. That process surfaced a harder question than either original draft had fully answered: what is SCIM actually supposed to cover here, and what should it explicitly leave to other standards? The working group's own framing draws a distinction between what it calls public agent identity and ephemeral private workload identity, and whether SCIM should extend to both or only the former. Tied to that is a sharper articulation of what SCIM does and doesn't provision: SCIM provisions the right to an identity, not the identity itself, whereas a standard like SPIFFE issues the actual credential separately, only after a workload proves it matches what it claims to be. That's a meaningfully clearer line than existed in either original draft, and it's the kind of design decision that shapes everything downstream, including how federation works: under the emerging model, federation is bilateral and human authorized, with federated domains sharing agent identities via SCIM while non-federated domains simply don't see them. ## The result: one draft, three companies The most concrete evidence that this consolidation actually worked is the draft it produced. draft-wzdk-scim-agent-resource-00, published in June 2026, is co-authored by M. Wahl and P. Dingle of Microsoft, D. Zollner of Okta, and I. Kazzouzi of Nextident. That author list is the headline as much as the content is. A year earlier, Microsoft and Okta were each publishing their own separate approach. Now they're publishing one document together, alongside a third organization that wasn't part of the original conversation at all. That's a real signal of forming consensus, not just two drafts existing side by side. The current draft's stated purpose is to establish an agentic identity so that an agent can subsequently be authenticated and authorized to interact with a service, while explicitly noting that an agent identity's attributes can differ from a human user's. It keeps the same core SCIM lifecycle model, that a client can update and remove that agent's record and associate it with groups, roles, and entitlements, rather than inventing a parallel system. To make that concrete, the kind of relationship the earlier Abbey and Cohen draft defined, an agent's connection to the application it belongs to, looked roughly like this: The consolidated draft's final attribute set isn't settled yet, this is illustrative of the shape being discussed rather than a spec quotation, but it gives a sense of what "an agent as a SCIM managed identity" concretely looks like: an identifier, a reference, a display name, a relationship type, and a way to point back at external systems that also know about the agent. ## Where this leaves the SCIM, OAuth, and SPIFFE boundary This is the part that connects most directly to the broader non-human identity picture. Independent of the IETF process entirely, a recent academic survey of agent identity protocols draws the same boundary the working group is converging on: SCIM for agents addresses provisioning lifecycle rather than runtime authorization, and while organizations already invested in IETF standard infrastructure benefit from that alignment, no single current draft, SCIM included, provides holder-attenuable delegation, cross-protocol bindings, and provenance tracking in one unified protocol. That's worth sitting with. It means the layered model we described previously, SCIM handling who exists and whether they're still active, with OAuth and SPIFFE handling scoped and short lived runtime access on top, isn't just a simplification we made for that piece. It's the same conclusion the standards body and outside researchers are independently arriving at from different directions. SCIM's role in agent identity is being scoped down to what it's actually good at, rather than stretched to cover the whole problem. ## What to actually do with this Nothing here is stable enough to build against yet. draft-wzdk-scim-agent-resource-00 carries informational status, not standards track, and is set to expire in December 2026, which is a reasonable date to check back and see whether it's been renewed, replaced, or promoted. If you're designing schema today with agent identity in mind, the practical takeaway is narrower than "wait for the RFC." It's this: model your agent identities as their own resource with clear lifecycle hooks, the way the consolidated draft is trending, rather than betting on the application centric model from the original Abbey and Cohen draft. And don't expect SCIM to solve runtime authorization or credential issuance for agents on its own. That part of the problem is explicitly being left to OAuth and workload identity standards like SPIFFE, by design, not by omission. This is exactly the kind of spec evolution that's easier to track when provisioning isn't something you're maintaining by hand. WorkOS Directory Sync keeps pace with SCIM's working group output for human identity today, and agent identity is moving quickly enough that we're actively watching this consolidation rather than building against any single draft prematurely. [See how WorkOS handles identity provisioning](https://workos.com/directory-sync).