SCIM 2.0 (System for Cross-domain Identity Management) is the protocol that lets your identity provider drive user and group membership changes into downstream applications automatically. For AI platforms specifically, it is the mechanism that ensures access never goes stale: when someone joins your organization, they get the right agent access on day one; when they leave, it disappears within minutes of the deprovision event. For how SCIM fits into the broader enterprise identity picture alongside SSO, see SSO and SCIM: enterprise identity for AI tools.

The Joiner-Mover-Leaver Problem for AI Tools

Every organization manages a continuous flow of identity events. People join teams, change roles, take on new responsibilities, move between departments, and eventually leave. In traditional SaaS, a missed offboarding might mean a departed employee can still read a project management board. With AI agents that have access to internal APIs, databases, and communication channels, the blast radius of stale access is substantially larger. This is why how to implement least privilege for AI agents is inseparable from lifecycle automation — least-privilege access means nothing if stale access is never removed.

Manual provisioning does not scale past a few dozen users. Your IT team will face a backlog of access requests, and offboarding tickets lag even further. The result is a growing tail of dormant accounts with live credentials attached to agents that can still act on them.

SCIM closes this gap by making your identity provider (Okta, Microsoft Entra ID, OneLogin, and others) the single source of truth. When HR systems or directory changes trigger an IdP event, that event propagates to every connected application that speaks SCIM — without a ticket, without a manual step.

What SCIM 2.0 Actually Does

The SCIM 2.0 specification (RFC 7643/7644) defines a standard REST API that identity providers use to manage two resource types: Users and Groups. The IdP sends HTTP requests to your application's SCIM endpoint, and your application translates those into real account and membership changes.

The core operations break down cleanly:

Users. A POST /Users call provisions a new account. A PATCH /Users/:id with active: false deprovisions it — in a well-implemented system, this triggers session revocation, not just a flag. Name changes arrive as PATCH updates and keep the user record current.

Groups. A POST /Groups creates a group. Member add and remove operations arrive as PATCH requests with member arrays. Groups in SCIM map naturally to teams or roles in the downstream application.

Pagination. The protocol defines pagination via startIndex and count query parameters, which matters when syncing thousands of users in a large enterprise directory.

The protocol is intentionally simple. Its value is not sophistication — it is that every major IdP implements it, so integration is a configuration exercise rather than a custom engineering project.

Groups to Teams: JIT Role Mapping

One of the more powerful patterns SCIM enables is just-in-time role assignment through group mapping. Instead of managing role assignments in the AI platform separately from the IdP, you declare that members of a specific IdP group receive a specific role when provisioned.

This means your IdP becomes the authoritative roster for roles as well as membership. When a user moves from "Engineering" to "Engineering Managers" in Okta, the SCIM sync propagates that change downstream, adjusting their permissions to match their new responsibility.

The constraint worth understanding: SCIM-driven role grants should not be able to elevate users to the highest privilege levels automatically. If a misconfigured group mapping could silently make arbitrary users organization owners, you have turned your IdP into a privilege escalation path. A properly designed SCIM implementation refuses to grant owner-level roles through automated group sync and requires that assignment through an explicit, audited admin action.

Deprovision Is the Critical Path

Provisioning gets most of the attention because it is associated with a positive event — someone new joining and getting access. Deprovisioning is where security programs actually fail.

When a SCIM deprovision event arrives (a PATCH with active: false, or a DELETE), the right sequence is:

  1. Remove the user's membership from the organization.
  2. Revoke all active sessions and refresh tokens — not just mark the account inactive.
  3. Deactivate the global account only if the user has no remaining memberships in any other organization on the platform.

Steps 2 and 3 are where implementations diverge. An implementation that only flips an active flag leaves existing JWT sessions valid until they expire naturally, which could be hours. Token revocation on deprovision is not optional if you take the security posture seriously.

The third point matters for multi-tenant platforms. A user might belong to two organizations. Deprovisioning from one should not destroy their account entirely — only their membership, roles, and credentials scoped to the affected organization.

Setting Up SCIM in Practice

The setup flow is deliberately short. An organization owner enables SCIM in the security settings, generates a bearer token (shown once, not stored in plaintext), and pastes the base SCIM URL plus that token into the IdP's SCIM connector configuration. The IdP handles the rest.

A few operational details matter:

Token security. The bearer token is the only credential between the public internet and your user directory. It should be stored as a one-way hash server-side, transmitted over TLS only, and rotatable without service interruption. Treat it with the same care as a root API key.

Brute-force protection. The SCIM endpoint is publicly routable, reachable by anyone who knows the URL. Rate limiting and brute-force detection on the bearer token validation path are necessary, not optional. Failures should return a uniform 401 regardless of whether the token was wrong or the organization was invalid — enumerating organization IDs through error differentiation is a real attack vector. For the broader security policy controls that complement SCIM, see security policies: passwords, sessions, and IP restrictions.

PATCH allowlisting. The SCIM PATCH operation on a User resource can carry arbitrary field updates. A safe implementation allowlists the fields it will act on — typically active, given name, family name, and display name — and silently ignores or rejects anything else. Allowing a SCIM PATCH to update authentication-state fields or account identifiers would be a serious privilege escalation risk.

Praesidia's SCIM Implementation

Praesidia implements the full SCIM 2.0 Users and Groups protocol surface, accepting provisioning events from any compliant IdP. Users provisioned via SCIM are created with org membership and any role assignments declared in the group mapping configuration. Group membership changes are applied incrementally so that additions and removals stay in sync without full re-syncs.

The bearer token is stored securely and validated in constant time to prevent timing side-channels. Failed authentication attempts are logged as audit events and counted against per-IP rate limits. Field updates are restricted to a safe allowlist, and deprovisioning terminates all active sessions for the affected membership scope.

Group mapping configuration is available in the integrations section of the admin panel. Owners can declare that a specific IdP group should grant a specific organization or team role to its members upon provisioning. Owner-level role grants are explicitly excluded from what group mappings can do, keeping the highest privilege path out of automated sync.

For more on how identity integrates across SSO, SCIM, and RBAC, see SSO and SCIM: enterprise identity for AI tools and RBAC and custom roles for AI operations.

Common questions

Does SCIM work alongside SSO, or do I need to choose one? They serve different purposes and work together. SSO handles authentication — it proves who someone is when they try to log in. SCIM handles provisioning — it ensures the account exists and has the right memberships before the login even happens. Most enterprise deployments use both: SCIM to create and remove accounts automatically, SSO to authenticate sessions. Using SSO without SCIM means you still need to manually manage who gets to log in; SCIM without SSO means accounts are provisioned but users authenticate with local credentials. See single sign-on for AI agent management: SAML and OIDC for how the SSO side of that pairing works.

What happens if the SCIM sync fails partway through a group update? SCIM events are individual HTTP requests, not transactions. If a group member-add PATCH partially applies before an error, the IdP will typically retry the full operation. A well-behaved SCIM server handles idempotent retries correctly — re-adding a member who is already present should succeed without duplicating the membership. Monitoring SCIM sync errors from the IdP's provisioning logs is the fastest way to catch partial failures; most IdPs surface these in their connector activity report.

Can I use SCIM without handing my IdP full control over roles? Yes. Group mapping is opt-in. You can enable SCIM for basic lifecycle management — provisioning and deprovisioning accounts — without declaring any group-to-role mappings. Users provisioned this way arrive with a base membership and no elevated roles. Role assignment then happens through the platform's own admin interface, which keeps role governance separate from directory sync. This is a reasonable middle ground for organizations that want automated offboarding but prefer to manage elevated access manually.

What SCIM Buys You

The core value of SCIM is eliminating the time window between an identity event and access reflecting it. Without SCIM, that window is however long it takes someone to file a ticket and for it to be processed — often days. With SCIM, it collapses to the IdP's sync interval, typically minutes.

For AI platforms, that window matters because agents are not passive viewers — they act. Stale access attached to a departed employee's account, or an over-provisioned role left behind after an internal move, is not merely a compliance problem — it is an operational risk. SCIM is the mechanism that keeps access aligned with organizational reality as quickly as your IdP can push the change.

If your organization uses an IdP that supports SCIM 2.0, wiring it to your AI platform is one of the highest-leverage identity controls you can add. The provisioning side is straightforward; spend the time to verify that deprovision is tested and token revocation actually fires — those are the moments that count when someone leaves unexpectedly. For how SCIM-driven role changes interact with team access controls, see organizing access with teams.