Skip to main content

​
What You’ll Accomplish

Event Routing connects platform events to runbooks. When a subscribed event fires, the gateway renders the event payload through the subscription’s parameter mapping and dispatches the target runbook automatically. You can:
  • Revoke access automatically when DLP flags sensitive data in a session.
  • Trigger remediation the moment a guardrail rule fires.
  • Page on-call when the AI analyzer rates a session as high risk.
  • Pre-stage evidence collection when a PCI-tagged connection is opened.
  • Replay a failed dispatch from history without waiting for the original event to fire again.
Event Routing is an experimental feature. It’s enabled by default since version 1.85.0 — on earlier versions an admin enables it per organization.

​
How Event Routing Works

1

Event fires inside the gateway

A typed event is emitted at an audit-relevant moment: a session opens or closes, a review is approved or denied, the DLP analyzer flags entities, a guardrail trips, the AI analyzer rates a session, or a PCI-tagged connection is opened.
2

Active subscriptions are matched

The gateway looks up subscriptions for that event type in the org. Only subscriptions with status active produce dispatches.
3

Parameter mapping renders the payload

Each runbook parameter is filled from an event payload field using a JSONPath reference (e.g. $.session_id, $.user). Same-name fields are pre-matched when you create the subscription.
4

Runbook is dispatched and executed

The dispatcher launches the runbook against the subscription’s resource role using the rendered parameters.
5

Dispatch is recorded on the subscription

A dispatch row lands in the subscription’s history with a status and duration. Failed dispatches can be replayed from the UI.

​
Event Catalog

​
Subscription and Dispatch Statuses

​
Subscription Status

A subscription can be paused to stop dispatching and resumed to re-enable it.

​
Dispatch Status

Failed dispatches can be manually replayed — replay is never automatic. A replay reuses the stored event payload, so no new event needs to fire.

​
Common Recipes

​
Recipe 1: Revoke AI Agent Access on PII Detection

Event: alert.sensitive_data_detected Runbook: revoke-ai-agent-access.md Parameter mapping: Fires whether or not a redaction was applied. Use alert.data_masked instead if you only want to react when values were actually replaced.

​
Recipe 2: Quarantine a Connection on Guardrail Violation

Event: session.guardrail_violation Runbook: quarantine-connection.md Parameter mapping: A session that trips multiple rules emits one event per rule, producing one dispatch per rule. Add a query_excerpt mapping to pass context to the runbook.

​
Recipe 3: Page On-Call for High-Risk Sessions

Event: session.anomaly_detected Runbook: page-oncall.md Parameter mapping: Does not fire for low or medium ratings, or when AI analysis is disabled for the org.
Ready to set it up? The Event Routing configuration guide covers enabling the feature, creating and managing subscriptions, auditing dispatch history, and troubleshooting.

​
Next Steps

Runbooks

Configure the repositories and runbook files that Event Routing dispatches.

Guardrails

Define rules so a violation can trigger an automated runbook response.

Live Data Masking

Turn on DLP so sensitive-data alerts can drive automatic remediation.

Access Requests

Set up approvals so JIT decisions can kick off follow-up runbooks.