Wiki · Concept · Last reviewed June 25, 2026

SCIM Security Event Tokens

SCIM Security Event Tokens are the RFC 9967 event profile for coordinating asynchronous identity-provisioning changes, replication, and request completion between SCIM systems.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: SCIM, Security Event Tokens, identity provisioning, AI agents, access governance

Definition

SCIM Security Event Tokens are defined by IETF RFC 9967, System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs), published as a Proposed Standard in May 2026. The RFC defines SCIM security events using the Security Event Token format from RFC 8417 so SCIM service providers and receivers can exchange asynchronous identity-provisioning messages.

The profile updates RFC 7643 by adding service-provider configuration attributes, and it updates RFC 7644 with an optional asynchronous SCIM request capability. The practical problem is scale and coordination: when multiple clients or services create, patch, delete, activate, or deactivate SCIM resources, polling every resource with repeated GET requests becomes inefficient and fragile.

A SET is not a command. RFC 8417 frames SETs as statements of fact from an issuer about a subject. A receiver validates and interprets the event, then applies its own policy response. That distinction matters for agents because a provisioning event should trigger local checks, reconciliation, revocation, or logging, not blind obedience.

Event Model

RFC 9967 defines the URI prefix urn:ietf:params:scim:event. Events are grouped into feed events, provisioning events, and miscellaneous events. Feed events include feed:add and feed:remove, which indicate that a SCIM resource has entered or left an event feed; they do not necessarily mean the resource was created, deleted, or deactivated.

Provisioning events use the prov namespace. They cover create, patch, put, delete, activate, and deactivate changes. Create, patch, and put events can use notice or full variants. A full event can carry resource data, while a notice event can be used as a trigger for later retrieval or reconciliation. Delete, activate, and deactivate have their own event types. RFC 9967 says a deactivation event typically means the subject may no longer have an active security session, while also leaving exact semantics to the event publisher and receiver agreement.

The miscellaneous namespace includes misc:asyncresp, an event for asynchronous request completion. RFC 9967 also defines use of the HTTP Prefer: respond-async header so a SCIM client can request asynchronous processing and later receive a completion event.

Agent Context

For AI-agent systems, SCIM events are account lifecycle signals. An enterprise may provision a durable agent identity, assign it to groups, connect it to tools, and then change or retire it as projects, owners, or risk posture change. A SCIM event can tell downstream systems that the identity record moved, but it does not prove the agent should continue acting.

A useful agent platform should map SCIM events to enforcement. A deactivate event might suspend a connector, revoke refresh tokens, cancel pending tool work, or require owner review. A patch or put notice might trigger a fresh SCIM GET before an agent uses a changed group membership. A delete event should not leave a shadow credential in a queue, cache, browser profile, or long-running job.

Governance Risks

Event confusion. Feed membership, provisioning state, authentication state, and authorization state are different. A feed removal is not the same as account deletion.

Stale authority. Events arrive after a resource changed, while agents may still be running with old sessions or tool credentials.

Over-sharing. Full events can carry sensitive resource data. Notice events plus retrieval can reduce payload exposure when receivers do not need every attribute.

Delivery gaps. High-change resources, especially large groups, can create throughput and recovery problems. RFC 9967 recommends patterns such as using PATCH, notice events, aggregation, and recovery storage.

False certainty. A signed event proves origin and integrity; it does not prove that every downstream service has applied the corresponding policy action.

Governance Pattern

Source Discipline

Use RFC 9967 for SCIM event claims, RFC 8417 for SET structure, RFC 7643 for SCIM schema, and RFC 7644 for SCIM protocol behavior. Do not collapse SCIM events into Shared Signals Framework, OAuth Token Revocation, or a vendor webhook. They may interact, but they are different mechanisms.

Spiralist Reading

Spiralism reads SCIM events as the choreography of institutional memory. The system does not only create identities; it must notice when they move, narrow, fail, or end. For agents, that is the difference between delegated work and unattended authority.

Open Questions

Sources

Return to Wiki