Notifications & Integrations

Route enforcement events and policy violations to Slack, SIEM, PagerDuty, Jira, or any HTTP endpoint — triggered per policy rule, so the right team gets the right alerts.

Rivaro emits two distinct categories of outbound integration: alert channels for human-readable violation notifications, and telemetry exports for machine-readable OpenTelemetry streams to your observability stack.

Where to find it in the app

Dashboard → Administration → Notifications.

The Notifications page has two tabs:

• Alert Channels — create, edit, test, and delete the channels (Slack, PagerDuty, SIEM, Webhook, etc.) that fire on policy violations
• Telemetry Exports — configure OTLP destinations (Datadog, Honeycomb, Splunk Observability, Grafana, Dynatrace, New Relic, Elastic, custom) for continuous span export

Once a channel exists, attach it to a policy rule by opening Policies & Authority, editing the rule, and setting the Notification channel field at the bottom of the rule editor. The same channel can be attached to many rules; each rule attaches to one channel.

Supported Alert Channels

Create these from Administration → Notifications → Alert Channels → Add channel.

Channel	Description
Slack	Post violation alerts to channels with configurable message format
Microsoft Teams	Send cards to Teams channels or webhooks
SIEM	Push events in CEF or JSON format to Splunk, Sentinel, or any SIEM
PagerDuty	Create incidents for critical and high severity violations
ServiceNow	Create ITSM incidents and change requests
Jira	Create tickets in any Jira project
Email	Send violation alerts by email
Webhook	POST to any HTTP endpoint with a configurable payload
Datadog (events)	Post events to the Datadog events API
Splunk (HEC events)	Post events via Splunk HEC

Supported Telemetry Exports (OTLP)

For continuous observability — not just per-violation alerts — Rivaro speaks OpenTelemetry OTLP and ships a built-in GenAI semantic-convention bridge that emits spans matching the OTel GenAI spec (gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens, etc.) plus Rivaro-specific attributes for decisions, detections, and receipts.

Create these from Administration → Notifications → Telemetry Exports → Add exporter.

Backend	Notes
Datadog	OTLP/HTTP to Datadog's OTel intake; honors DD-API-KEY
Honeycomb	OTLP/HTTP to api.honeycomb.io with x-honeycomb-team
Splunk Observability	OTLP/HTTP to your realm's ingest
Grafana Cloud	OTLP/HTTP to Grafana's cloud OTel endpoint
Dynatrace	OTLP/HTTP to your Dynatrace env's /api/v2/otlp/v1/traces
New Relic	OTLP/HTTP to otlp.nr-data.net with API key
Elastic	OTLP/HTTP to your Elastic deployment's APM endpoint
Custom OTLP	Any OTLP-compatible collector / vendor we don't ship a preset for

How notifications work

Notifications are attached to policy rules, not to detection types globally. This gives you fine-grained control: you can fire a PagerDuty alert when CREDENTIALS_API_KEY is detected at egress, while only logging PII_EMAIL at ingress.

The end-to-end workflow:

1. Create a notification channel in Administration → Notifications → Alert Channels.
2. Open Policies & Authority and edit the policy rule you want to wire up.
3. Set the rule's Notification channel field to your new channel.
4. When that rule fires, Rivaro sends the event to the channel.

Creating an alert channel

Open Administration → Notifications → Alert Channels and click Add channel. Pick the type, give it a name, configure the destination (webhook URL, API key, etc.) and choose a content strategy.

Content strategy

The Content strategy dropdown controls how much of the detection data is included in the notification:

Strategy	What's sent	Use when
Metadata only	Detection type, severity, actor ID, timestamp — no content	Sensitive environments where raw content must not leave the platform
Processed content	Metadata + redacted/masked version of the detected content	When you need enough context to triage without exposing raw data
Raw content	Full metadata + the original detected content	SIEM integrations or internal security tools with appropriate access controls

SIEM integration

When you create a channel with type SIEM, the configuration form asks for the SIEM endpoint, your authentication (HEC token / API key / Bearer), and a format choice:

Format	Description
CEF	Common Event Format — industry standard for SIEM ingestion, compatible with Splunk, Sentinel, QRadar
JSON	Structured JSON payload — use with custom log shippers or log aggregators

Every event sent to your SIEM includes:

• Detection type and risk category
• Severity (CRITICAL / HIGH / MEDIUM / LOW)
• Policy action taken (BLOCK / REDACT / LOG)
• Actor ID, agent ID, session ID
• Organization and tenant context
• Timestamp and request metadata
• Content (subject to the chosen content strategy)

Webhook integration

Use the Webhook channel type to integrate with any system that accepts HTTP POST requests. The configuration form asks for the URL and any custom headers (Authorization, signing keys, etc.). Rivaro sends a structured JSON payload — the schema is shown in the channel's detail view after creation.

Testing a channel

Every channel on the Alert Channels list has a Test action that sends a synthetic event to the destination. Use this before attaching to production rules so you can verify the destination receives the alert and that authentication is correct.

Telemetry export — OTLP setup

OTLP exports run continuously, not per rule. Once configured under Administration → Notifications → Telemetry Exports, every detection, policy decision, session boundary, and signed receipt becomes an OTel span emitted to your observability backend.

To create an exporter, click Add exporter, pick a preset (Datadog, Honeycomb, Splunk Observability, etc.) or Custom OTLP, and fill in:

• Endpoint — the OTLP/HTTP collector URL
• Headers — vendor-specific auth headers (e.g. x-honeycomb-team, DD-API-KEY, Authorization: Bearer ...)
• Dataset (Honeycomb) or token (other vendors) — as required by the chosen preset

The bridge handles authentication via OTLP header injection.

What gets exported

Each OTel span includes both the vendor-portable GenAI semantic-convention attributes and Rivaro-specific governance attributes:

OTel GenAI semantic conventions (vendor-portable):

• gen_ai.system — openai, anthropic, bedrock, vertex, azure_openai, sagemaker, etc.
• gen_ai.request.model, gen_ai.response.model
• gen_ai.usage.input_tokens, gen_ai.usage.output_tokens
• gen_ai.operation.name — chat, text_completion, embeddings, tool_call

Rivaro-specific attributes (governance evidence):

• rivaro.decision — ALLOW / BLOCK / REDACT / DEFER / etc.
• rivaro.detection.types[] — every detection type fired on this request
• rivaro.actor.id, rivaro.actor.trust_score
• rivaro.policy.matched_rule, rivaro.policy.template
• rivaro.receipt.jti — the AARM receipt JTI for cross-correlation

This means your existing dashboards (cost, latency, error rates) work out-of-the-box; you don't need to write Rivaro-specific queries to chart token spend or model usage.

Sample query — Honeycomb

SELECT COUNT, AVG(gen_ai.usage.input_tokens)
WHERE gen_ai.system = "openai" AND rivaro.decision = "BLOCK"
GROUP BY rivaro.detection.types

Pull-mode telemetry export

In addition to push-mode OTLP, you can pull raw audit records out of Rivaro on demand — useful for ad-hoc SIEM backfills or for systems that prefer pull over push. The Telemetry Exports tab has a Pull export action that builds a parameterized download (time range, decision filter, agent / user / detection-type filter, format choice of JSON NDJSON or CEF). The response is streamed; large pulls indicate truncation in the export's status footer so you can re-run with a narrower window.

Notification channel fields

These fields are visible on every channel row in the list:

Field	Description
Name	Display name
Type	Channel type: any of the alert or OTLP types above
Active	Whether the channel is enabled
Content strategy	Metadata only, Processed content, or Raw content (alert channels only — OTLP exports use OTel attribute conventions)
Rules attached	Number of policy rules using this channel (alert channels only)
Configuration	Channel-specific config (endpoints, API keys). Sensitive fields are encrypted and displayed as placeholders.

Toggle a channel off via the Active switch to temporarily disable notifications without deleting the channel or unwiring rules.

Next steps

• Enforcement & Policies — Create the rules that trigger notifications
• Policy Templates — Apply notification channels to template-based rules
• Actor Governance — Governance events can also trigger notifications