SCIM for AI: How a new IETF draft redefines identity management for agents and agent applications

overview

Over the past 10 years, SCIM (Cross Domain Identity Management System) has quietly become the backbone of user provisioning across the enterprise. It’s a protocol that allows identity providers (such as Okta, Azure AD, and SSOJet) to automatically create and delete user accounts across dozens of SaaS applications.

But something new is happening.

AI agents are no longer a scientific project. Log in to your CRM, retrieve data from APIs, and even approve workflow requests. These agents, often powered by extensive language models and custom automation logic, are becoming active participants in enterprise systems. However, they do not have a consistent identity model.

This is what the new IETF “Agents and Agenttic Applications” draft aims to fix.

This proposal extends SCIM beyond human users to AI agents and agent applications, creating a standardized framework for provisioning, managing, and deactivating digital workers.

In short, this is SCIM for the AI era and a long overdue upgrade to modern identity systems.

Why AI agents need identity standards

Today, enterprises use SCIM to automatically synchronize user accounts. When you join a company, you get accounts for Google Workspace, Slack, and Salesforce. Once they leave, those accounts will be immediately deactivated.

Now imagine your organization operates 50 in-house AI assistants. One person answers HR questions, another handles IT support tickets, and a few more help generate code reviews.

Each of these bots is:

API access key available
Interact with real data
act autonomously on behalf of humans

However, there is no standardized way to track, authenticate, or deprovision them. Most organizations store these credentials manually, creating significant governance blind spots.

The new SCIM draft argues that AI agents should be managed identities, with ownership, entitlements, and lifecycle events, just like human users.

This change has deep implications for security, auditing, and automation.

What’s new in Draft

The IETF proposal introduces two new SCIM resource types: agents and agenttic applications. Together, these bring machine entities into the same lifecycle as human users.

1. agent – Digital workers with a clear identity

Ann agent Represents a non-human identity such as a chatbot, automation bot, or AI assistant.

This includes attributes such as:

name and displayName — Who or what is it?
agentType — “bot”, “assistant”, “service”, etc.
owners — a responsible person or group
applications — Which system does it belong to?
protocols — Supported communication types (OpenAPI, A2A, MCP Server, etc.)
x509Certificates — Encrypted credentials
subject — Mapping between SCIM and authentication tokens (such as OIDC) sub)

This structure allows you to:

Automatically provision new agents
Assign roles or permissions
Pause it or cleanly delete it when you no longer need it

example:

GET /scim/v2/Agents?filter=name eq "customer-support-bot"

result:
An object that describes the bot’s name, status, ownership, and credentials. Managed under the same security and compliance policies as employees.

2. agent application – System hosting the agent

The second new resource type, agent application, represents the platform or environment that hosts the agent. Think of it as a container for digital workers.

Define:

name, descriptionoperating status
applicationUrls (Login, API, or SSO endpoint)
oAuthConfiguration (How the agent authenticates)
Linked agents it manages
lastAccessed — for auditing and lifecycle cleanup

Example query:

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

This two-way mapping (agent ↔ application) provides clear trust boundaries. Each agent knows which app it belongs to, and each app knows which agents it is responsible for.

This level of clarity is critical for compliance teams and SOC analysts looking to track automated behavior within large systems.

Schema compatibility and backward support

Since not all systems support these new resource types yet, the draft includes a graceful fallback model.

through /ServiceProviderConfig On endpoints, SCIM servers can advertise whether they support agents and AgenticApplications.

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

If not supported, the client can fall back to treating the agent as follows: User Objects — with additional extensions that mark them as non-human identities.

{
  "userName": "research-bot",
  "displayName": "Research Assistant Bot",
  "urn:ietf:params:scim:schemas:extension:LinkedObject:2.0:User": {
    "linkedObjectType": "Agent"
  }
}

This hybrid approach allows interoperability Between the old and new SCIM implementations.

Security and governance implications

This draft is not just about schemas, it’s about accountability.
The details of the implementation from a security perspective are as follows.

Ownership and accountability

All agents must have at least one owner (a human user or group). This allows all autonomous actions to be traced back to the responsible entity. This is a key compliance and forensics requirement.

Credential lifecycle management

By embedding the certificate (x509Certificates) and protocol metadata directly into SCIM, organizations can now manage token rotation, revocation, and expiration natively, without the need for external manual steps.

App-agent boundary

The relationship between an agent and the application that hosts it is explicitly defined using references. This makes the approval path transparent and instantly revoked when an app or agent is retired.

Audit and traceability

addition of lastAccessed Timestamps bring necessary hygiene to lifecycle management.
Security teams can easily flag dormant agents and inactive applications to ensure that unused credentials don’t remain around indefinitely.

Why is this important for platforms like SSOJet?

At SSOJet, we have always believed that identity is not limited to humans, but is the connective tissue between all services, systems, and now all intelligent agents.

The expansion draft validates that vision.

Here’s why this evolution aligns with SSOJet’s direction:

Integrated provisioning: SCIM should not be suspended on user accounts. Agent provisioning will be seamless as well.
Auditability at scale: SSOJet’s SCIM implementation already tracks the human lifecycle. Extending it to machine entities is a natural step.
Security-first design: Clear ownership and certificate-bound credentials can provide complete visibility and governance over AI agent activity.
Future-proof directory synchronization: As enterprises embrace autonomous AI workers, SSOJet aims to make them part of the same secure provisioning framework as other employees.

In essence, the SCIM for AI movement is about bridging human and machine governance, and SSOJet plans to be at the forefront of this transformation.

takeout

Rather than reinventing identity management, the new SCIM agent extension refines it for new classes of entities.

It recognizes a future in which:

Bots and assistants log into corporate systems
AI models operate with delegated authority
And identity management extends beyond people

The IETF draft lays the foundation for a secure, compliant, and interoperable AI ecosystem by standardizing how these agents are described, authenticated, and audited.

If you’re already relying on SCIM for your users and groups, it’s time to start thinking about how your organization will provision and manage AI identities.

Because the future of identity is no longer just about humans, but about everything that acts on your behalf.

References

*** This is a Security Blogger Network syndicated blog for SSOJet – Enterprise SSO & Identity Solutions, created by SSOJet – Enterprise SSO & Identity Solutions. Read the original post: https://ssojet.com/blog/scim-for-ai-how-the-new-ietf-draft-redefines-identity-management-for-agents-and-agentic-applications

Source link