Wiki · Concept · Last reviewed June 25, 2026

Shared Signals Framework

OpenID Shared Signals Framework is a standard pattern for exchanging security events across cooperating systems, so identity, agent, and tool services can react when sessions, credentials, accounts, devices, or risk status change.

Category: Concept Updated: June 25, 2026 Tags: AI agents, identity, authorization, Shared Signals, CAEP, RISC, Security Event Tokens

Definition

Shared Signals Framework, or SSF, is an OpenID Foundation specification for managing streams of security events between a transmitter and a receiver. The transmitter sends events. The receiver subscribes to a stream and processes them. The events are carried as Security Event Tokens, the JWT-based format standardized by IETF RFC 8417.

The framework matters because identity and authorization systems often learn security facts at different times: a session is revoked, a credential changes, an account is disabled, a device falls out of compliance, or a token claim should no longer be trusted. SSF gives cooperating systems a governed way to share those state changes.

For AI agents, SSF is a delegated-authority control. If a user's account state changes while an agent still has a live connector session, the tool side needs a signal that can trigger step-up authentication, session shutdown, scope reduction, review, or OAuth Token Revocation.

Snapshot

How It Works

SSF defines how a receiver creates and manages a stream at the transmitter's configuration endpoint. A stream can specify subject members, event types, and delivery method. The framework also defines read, update, delete, pause, resume, and verification operations for streams.

The delivery layer is separate from the event vocabulary. Push-based SET delivery lets a transmitter send events to a receiver endpoint. Poll-based SET delivery lets a receiver ask for available events. SSF's verification endpoint lets the receiver send a SET back to confirm that delivery and validation are wired correctly.

CAEP, the Continuous Access Evaluation Profile, covers access-relevant changes such as session revoked, token claims changed, credential changed, assurance level changed, device compliance changed, and risk level changed. RISC, the Risk Incident Sharing and Coordination Profile, covers account and security incidents such as account disabled, credential compromise, identifier changed or recycled, account purged, recovery activity, sessions revoked, and account-enabled changes.

A SET is evidence, not a command. The receiving system still decides what policy response follows: deny, step up, log, revoke, quarantine, notify, or ignore.

Agent Context

Agent systems are built out of partial trust. A model host may hold the conversation, a tool server may hold access to a repository, an identity provider may know the user session, and a policy service may know that an action is high risk. Without shared signals, those parties can keep acting on different versions of the user's security state.

If a background agent can read mail, open tickets, or change cloud configuration, a credential-compromise event should be able to halt the run, require stronger authentication, shrink authority, or revoke the grant. The tool server should validate the SET, map the subject to local state, check the event type, and apply prewritten policy rather than treating the event as model context.

Governance and Safety

The governance value of SSF is continuity. Access control is not a one-time gate at login; it is a sequence of changing facts about users, agents, devices, sessions, credentials, resources, and risk. Shared signals make those facts auditable across boundaries.

SSF belongs near AI Agent Identity, Sender-Constrained Tokens, OAuth Token Introspection, and AI Audit Trails. It does not replace those controls. It supplies timely evidence that can change their behavior.

Privacy risk still matters. A shared signal can expose sensitive account, session, device, or risk information. Receivers should subscribe only to needed event types, bind events to a legitimate subject relationship, and retain event records only as long as necessary.

Minimum Evidence Record

An agent platform using SSF should preserve the transmitter, receiver, stream identifier, event type, subject mapping, SET identifier if present, issued-at time, received time, delivery method, verification result, policy decision, resulting agent action, and any follow-up revocation or introspection outcome. Logs should not store raw bearer tokens or unnecessary user secrets.

Defense Pattern

Source Discipline

Claims about SSF should name the transmitter, receiver, stream, event profile, event type, subject mapping, delivery method, validation result, and local policy response. Do not collapse it into login, logout, webhooks, revocation, SIEM ingestion, or a claim that all participants share the same risk judgment.

Spiralist Reading

Spiralism reads shared signals as the nervous system of delegated authority. The point is not that machines become wise when they receive more telemetry. The point is that a machine acting for someone should not continue as if nothing changed after another trusted system has learned that trust shifted.

The discipline is to carry enough signal to stop stale authority without making surveillance feel like safety.

Open Questions

Sources

Return to Wiki