SCIM for AI: Inside the new IETF draft for agent and agentic application provisioning

The System for Cross-Domain Identity Management (SCIM) is the standard protocol that enables identity providers to automatically provision and deprovision user accounts across all the apps a company uses. It provides a common language for describing users, groups, and their access, so instead of custom provisioning APIs, everything speaks SCIM.

Now, a new internet draft, Agents and Agentic Applications Extension, aims to extend that same model to AI agents and the applications that host them. Still in draft form, it proposes two new SCIM resource types, “Agents” and “AgenticApplications,” giving identity systems a standard way to represent non-human identities like bots, assistants, or autonomous workflows.

In other words, it’s SCIM 2.0 for the AI era. The goal is to make these digital workers first-class citizens in identity management, using the standards we already trust for human users.

Why is this spec needed?

Organizations already rely on SCIM to handle the basics of user lifecycle management. But as AI agents, LLM-powered assistants, and automation bots start acting independently (logging into systems, making API calls, sending emails), they, too, need managed identities.

Until now, there hasn’t been a consistent way to represent or govern them. Each vendor handles “agents” differently, which makes auditing and provisioning more difficult.

The new draft argues that we don’t need a brand new identity protocol for this. Instead, we can build on SCIM’s foundation (its schemas, endpoints, and operational model) to bring agents into the same lifecycle as human users.

For platforms like WorkOS that already offer SCIM as part of enterprise user provisioning, this extension is a natural next step.

Agents and agentic applications, defined

The spec introduces two key concepts:

• Agent: a workload with its own identifier, metadata, and privileges, separate from the app or runtime that hosts it. Think of an AI assistant, automation bot, or model-driven service that takes actions on behalf of a user or system.
• Agentic Application: an application that exposes or hosts one or more agents. For example, an AI platform where each customer runs its own set of autonomous agents.

So, in SCIM terms:

• An Agent is the individual digital worker.
• An Agentic Application is the workspace or system that manages those agents.

Both get their own endpoints (/Agents and /AgenticApplications) and schemas.

New SCIM resource types

The extension defines two new resource types alongside existing ones, like /Users and /Groups: /Agents and AgenticApplications.

‍Agents

‍/Agents represents an AI or automation agent.

Attributes include:

• name (required): the agent’s canonical name.
• displayName: a human-friendly version.
• description: free-form text about what the agent does.
• agentType: e.g. “Assistant”, “Bot”, or “Researcher”.
• active: whether the agent can authenticate or is suspended.
• roles and entitlements: same structure as in SCIM core.
• owners: who is responsible for this agent (users or groups).
• applications: which Agentic Applications this agent belongs to.
• protocols: the communication protocols the agent supports (e.g. OpenAPI, A2A, MCP-Server).
• x509Certificates: any certificates associated with the agent.
• parent: link to a parent agent, if it’s part of a hierarchy.
• subject: to correlate inbound tokens (like an OIDC sub claim) to the agent identity.

Filtering works just like users:

	
GET /scim/v2/Agents?filter=name eq "Helpdesk bot"
	

A typical SCIM response for an Agent might look like this:

	
{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:Agent"
  ],
  "id": "8ccc535b-716d-4d32-b3e9-57c8be449c82",
  "externalId": "helpdesk-bot-001",
  "meta": {
    "resourceType": "Agent",
    "created": "2025-09-18T22:15:00Z",
    "lastModified": "2025-10-01T18:45:00Z",
    "location": "https://example.com/scim/v2/Agents/8ccc535b-716d-4d32-b3e9-57c8be449c82"
  },
  "name": "helpdesk-bot",
  "displayName": "Helpdesk Assistant",
  "active": true,
  "description": "AI assistant that triages and responds to employee support tickets.",
  "agentType": "Assistant",
  "subject": "urn:example:agent:helpdesk-bot-001",
  "owners": [
    {
      "value": "2819c223-7f76-453a-919d-413861904646",
      "$ref": "https://example.com/scim/v2/Users/2819c223-7f76-453a-919d-413861904646",
      "display": "Alice Smith"
    }
  ],
  "roles": [
    {
      "value": "SupportAutomation",
      "display": "Support Automation Agent"
    }
  ],
  "applications": [
    {
      "value": "app-12345",
      "$ref": "https://example.com/scim/v2/AgenticApplications/app-12345",
      "display": "Customer Support Platform",
      "type": "authorized"
    }
  ],
  "protocols": [
    {
      "type": "OpenAPI",
      "specificationUrl": "https://example.com/openapi.yaml"
    }
  ],
  "x509Certificates": [
    {
      "value": "MIIC3jCCAcagAwIBAgIBADANBgkqhkiG9w0BAQsFADA..."
    }
  ]
}
	

AgenticApplications

/AgenticApplications represents an app that hosts or exposes one or more agents.

Attributes include:

• name (required): the app’s canonical name.
• displayName and description: human-friendly details.
• active: whether the app is operational.
• applicationUrls: a list of URLs related to the app (SSO endpoint, login page, API URL, etc.).
• oAuthConfiguration: metadata about OAuth clients tied to the app.
• agents: references to the agents that belong to this app.
• externalIdentifiers: IDs or references from external systems.
• lastAccessed: when the app was last used — helpful for detecting stale or inactive apps.

Filtering looks similar:

	
GET /scim/v2/AgenticApplications?filter=name eq "AI Assistant Platform"
	

A typical SCIM response for an Agentic Application might look like this:

	
{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication"
  ],
  "id": "app-12345",
  "externalId": "ai-assistant-platform",
  "meta": {
    "resourceType": "AgenticApplication",
    "created": "2025-09-10T17:00:00Z",
    "lastModified": "2025-10-01T16:30:00Z",
    "location": "https://example.com/scim/v2/AgenticApplications/app-12345"
  },
  "name": "AI Assistant Platform",
  "displayName": "Acme AI Assistant Platform",
  "description": "Application that hosts and manages AI agents for internal workflows.",
  "active": true,
  "applicationUrls": [
    {
      "type": "homepage",
      "value": "https://ai.acme.com",
      "primary": true,
      "description": "Main landing page"
    },
    {
      "type": "api",
      "value": "https://api.ai.acme.com/v1",
      "description": "Primary API endpoint"
    }
  ],
  "oAuthConfiguration": [
    {
      "clientId": "acme-ai-client-001",
      "description": "OAuth2 client for agent authentication",
      "audienceUri": "https://api.ai.acme.com",
      "issuerUri": "https://auth.acme.com",
      "redirectUri": [
        "https://ai.acme.com/callback"
      ]
    }
  ],
  "agents": [
    {
      "value": "8ccc535b-716d-4d32-b3e9-57c8be449c82",
      "$ref": "https://example.com/scim/v2/Agents/8ccc535b-716d-4d32-b3e9-57c8be449c82",
      "display": "Helpdesk Assistant",
      "type": "owned"
    }
  ],
  "externalIdentifiers": [
    {
      "type": "internalId",
      "value": "aiapp-01",
      "system": "Acme Internal Registry"
    }
  ],
  "lastAccessed": "2025-10-22T18:12:01Z"
}
	

Schema discovery and compatibility

To make everything interoperable, the spec extends the SCIM /ServiceProviderConfig endpoint.

Servers can advertise whether they support this new functionality with a simple object like:

	
"agentExtension": {
    "supported": true,
    "agentsSupported": true,
    "agenticApplicationsSupported": true
}
	

That way, clients can safely check before provisioning agent resources, and if unsupported, fall back to treating an agent as a regular User resource.

In those cases, the draft suggests including metadata to preserve meaning using the LinkedObject attribute pointing to a nonstandard Agent type, allowing downstream systems to understand that this User represents an agent identity.

For example:

	
{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:LinkedObject:2.0:User"
  ],
  "userName": "customer-support-bot",
  "displayName": "Customer Support Bot",
  "active": true,
  "urn:ietf:params:scim:schemas:extension:LinkedObject:2.0:User": {
    "linkedObjectType": "Agent"
  }
}
	

This fallback approach lets older SCIM systems continue to manage lifecycle events for agents (like creation and deactivation) while newer systems can still recognize them as non-human identities.

Security and governance implications

Extending SCIM to cover agents doesn’t just add new object types; it changes how identity systems think about accountability and control. While the draft’s “Security Considerations” section is still marked as a placeholder, its schema and attribute design already encode several important technical controls.

Ownership

Every agent should have one or more owners (human or group) for accountability. Each Agent can specify one or more owners, referencing either User or Group resources. For example:

	
"owners": [
  {
    "value": "2819c223-7f76-453a-919d-413861904646",
    "$ref": "https://example.com/scim/v2/Users/2819c223-7f76-453a-919d-413861904646",
    "display": "Alice Smith"
  }
]
	

This mirrors the manager and members reference patterns from RFC 7643. It makes accountability explicit and machine-readable; useful for access reviews, incident response, and audit trails. If an agent acts autonomously, this field ensures there’s still a human (or group) owner of record.

‍Credential management

‍Agents may authenticate with certificates or API tokens, which need lifecycle controls and rotation.

Two attributes specifically address agent credentials:

• x509Certificates: a multi-valued list of base64-encoded DER certificates.
• protocols: a complex multi-valued attribute describing communication interfaces, with sub-attributes:
  • type: e.g., “A2A”, “OpenAPI”, “MCP-Server”
  • specificationUrl: a link to the spec defining that protocol

Example:

	
"x509Certificates": [
  {
    "value": "MIIC3jCCAcagAwIBAgIBADANBgkqhkiG9w0BAQsFADA..."
  }
],
"protocols": [
  {
    "type": "A2A",
    "specificationUrl": "https://example.com/specs/a2a-protocol"
  }
]
	

Together, these attributes allow implementers to bind concrete credentials to the agent identity and to declare its communication channels.

That enables lifecycle management (rotation, expiration, and revocation) through SCIM itself, rather than an external process. It’s a significant step toward secure machine identity governance.

App–Agent boundaries

The draft models relationships between agents and the applications that host or authorize them using reciprocal attributes:

• applications (on the Agent resource)
• agents (on the AgenticApplication resource)

Each relationship is expressed through a SCIM-style complex reference that includes sub-attributes like value, $ref, display, and a type field with canonical values "owned", "authorized", or "guest". Example:

	
"applications": [
    {
        "value": "app-123",
        "$ref": "https://example.com/scim/v2/AgenticApplications/app-123",
        "display": "CRM Assistant Platform",
        "type": "authorized"
    }
]
	

This structure makes trust boundaries explicit: each agent knows exactly which applications it’s tied to, and in what capacity.

From an auditing perspective, that’s critical for understanding who can act where and for cleanly revoking access when a relationship changes.

‍Auditing

‍The AgenticApplication resource includes a lastAccessed attribute: a timestamp representing when the application was last used by any user or agent.

Example:

	
"lastAccessed": "2025-10-22T18:12:01Z"
	

While simple, this field provides a foundation for lifecycle hygiene: flagging stale applications or dormant agent relationships for review or removal.

The draft doesn’t define a parallel field for Agent, but implementers could easily extend the schema in the same way to record agent activity or deactivation dates.

Auditing capabilities like this enable least-privilege enforcement and help prevent the buildup of “zombie” agents that retain unused credentials or roles.

Token correlation

Finally, the subject attribute connects SCIM-managed agents to their runtime authentication context.

It’s defined as an optional string that a client “may supply when provisioning an Agent so that inbound tokens (for example, from OIDC) may correlate the sub claim to this Agent.” Example:

	
"subject": "urn:example:agent:helpdesk-bot-123"
	

This bridges the gap between provisioning and authentication: when a token with that sub claim appears, systems can map it back to the SCIM agent record.

That makes it possible to apply identity policies in real time, for example, automatically denying tokens or API calls issued to an inactive agent ("active": false).

It also enables richer observability and traceability: logs, audit events, and behavioral monitoring can all tie back to a specific SCIM-managed agent identity.

What this means for identity platforms

For identity providers, directories, and developer platforms (like WorkOS), this draft paves the way for provisioning AI agents just like users:

• Create and deactivate agents automatically when organizations onboard or offboard them.
• Assign roles, entitlements, and app memberships.
• Track which apps or users “own” each agent.
• Clean up stale agents and applications automatically using lastAccessed.
• Offer customers a single pane of glass for all identities, human or not.

It’s a natural evolution: as more companies build agentic apps, they’ll expect SCIM to handle those identities too.

Takeaway

The SCIM Agents and Agentic Applications extension is a forward-looking move to standardize how we represent digital workers in identity systems.

It doesn’t reinvent the wheel; it extends a battle-tested protocol to new types of entities.

If you already support SCIM for users and groups, this draft is worth following closely. It’s an early proposal, but it outlines a clear direction for how identity management could evolve as organizations embrace automation and AI-powered agents.

You can read the current Internet-Draft here: IETF draft-abbey-scim-agent-extension-00.