Identity Bridge
Everything on this page is new.
The Identity Bridge is off by default for every organization. If you haven't connected an identity provider, this changes nothing about how OpenBox governs your agents: nothing is sent anywhere.
Two Layers of Response
When OpenBox detects a Trust Incident (a HALT, a critical behavioral violation, or a trust-tier demotion), it responds in two layers:
- OpenBox blocks the next governed call for the affected agent: instantly, synchronously, and always on. This layer needs no identity provider at all; it's bounded to whatever OpenBox itself instruments.
- Your identity provider withdraws access estate-wide, only if the Identity Bridge is connected. This layer can reach applications OpenBox never instrumented, but it depends on your IdP's own evaluation and completes at the next grant issuance there, not instantly.
Layer 1 runs independently of the Identity Bridge and is why it exists: Layer 2 is broader in reach but slower and conditional on a connection, so OpenBox never relies on it alone.
Connecting an Identity Provider
New connections start in Monitor Mode: OpenBox evaluates which trust incidents would generate a signal and logs those candidates, but sends nothing to the identity provider yet. Use this period to confirm the right events are being identified before any signal actually leaves OpenBox.
Once you opt into live sending for the connection, each qualifying trust incident is emitted to your identity provider as a signal over the Shared Signals Framework (SSF), using the CAEP (Continuous Access Evaluation Protocol) event format. This lets your identity provider react to OpenBox governance the same way it already reacts to other continuous-access signals, for example stepping up authentication or revoking a session for the identity tied to a misbehaving agent.
Signal Types
| Signal | Fires On | Availability |
|---|---|---|
risk-level-change | Agent's trust tier enters ELEVATED or CRITICAL | Sent once a connection is live |
session-revoked | Agent's trust tier enters CRITICAL | Capability-gated and opt-in, more restricted than risk-level-change; contact OpenBox to enable |
Validated Receiver: Okta ITP
Okta Identity Threat Protection (ITP) is the first validated receiver.
Okta ITP is a paid Okta add-on, not something every Okta customer already has. It requires Okta Identity Engine, Workforce Identity, and the ITP add-on itself before it can receive signals from OpenBox.
Connect it under Organization → Identity Bridge:
| Field | Description |
|---|---|
| Okta Domain | Your Okta org domain |
| SSF Receiver Endpoint | Discovered automatically from your Okta domain, or entered manually |
| Transmitter Credentials | Generated by OpenBox for Okta to verify signal authenticity |
Use Test Connection to confirm Okta can receive a signal before relying on it in production.
What Gets Sent
Each signal's subject identifies the full context of the incident (the user, the agent by DID, the tenant, and the session involved), not just the agent. Alongside the subject, each signal includes the trust incident type and a timestamp.
Signals carry only classifications and pointers needed to correlate the incident to an identity. They do not include full session payloads, prompts, tool outputs, or other customer data.
Delivery is at least once: OpenBox retries failed deliveries, holds persistently-failing signals in a dead-letter queue (DLQ), and supports replay. The channel is strictly one-way and outbound: OpenBox sends signals to your identity provider but does not consume any decision or response back from it.
Turning It Off
Disconnecting the Identity Bridge stops signal emission immediately. Trust incidents continue to be recorded in OpenBox exactly as before; only the outbound signal to your identity provider stops.
Related
- Trust Incident: What qualifies as a signal-worthy event
- Adapt: Where trust incidents also drive in-platform recovery plans