Runtime Policy Outcomes - HiddenLayer Docs

A Runtime Policy Outcome (RPO) is what Agentic Runtime Security emits when a policy evaluation produces an enforceable result against an AI interaction. Delivered to your systems as a data source on an integration, an outcome lets you alert, log, or trigger downstream automation.

How it works

Your system submits an AI interaction to HiddenLayer.
Agentic Runtime Security evaluates the interaction against the active policy for the project.
If the policy takes action, an outcome is emitted.
HiddenLayer delivers the outcome to every integration subscribed to the Runtime Policy Outcomes data source.

An outcome is produced only when a policy takes action — DETECT, REDACT, or BLOCK. Interactions that pass without action (NONE) do not generate one.

What an outcome contains

Field	Description
`manifest`	Standard platform event manifest (see below).
`policy_id`	Identifier of the policy that produced this outcome.
`session_id`	Runtime Security session identifier. Always present.
`interaction_id`	Identifier of the message within the session that produced this outcome. Use it to query the Runtime Security APIs for full interaction detail.
`external_session_ids`	Session identifiers from your upstream system, as supplied on the originating interaction. An array of `{ "id", "source" }` objects, where `source` labels the originating system. `null` when none were provided.
`requester_id`	Identifier of the entity that made the request. `null` when unavailable.
`evaluation`	Aggregate result of the policy evaluation (see below).
`detections`	Detection rules that fired. Each item has a `name`. Always an array, empty for an always-fire action with no active detection.

The manifest object carries the standard platform event fields:

Field	Description
`tenant_id`	Your HiddenLayer tenant identifier.
`correlation_id`	Correlation identifier for the originating request. Echoed from the `X-Correlation-Id` request header when the caller supplies one, otherwise assigned by HiddenLayer.
`event_id`	Unique identifier for this emission.
`event_at`	ISO 8601 timestamp (UTC) of the event.
`project_id`	The project the interaction was associated with.
`configuration_rule_set_version_id`	The policy ruleset version that evaluated the interaction.
`schema_name`	Fully-qualified schema name and version of the payload. Breaking changes ship as a new version (for example `_v2`), so subscribe to the version your integration expects.
`tags`	Reserved for HiddenLayer-internal metadata. Do not build logic on it; its contents may change without notice.

The evaluation object contains:

Field	Description
`action`	The policy outcome — the action your policy determined for this interaction: `DETECT`, `REDACT`, or `BLOCK`. This reflects the policy decision and may differ from what a constrained integration was able to enforce inline.
`highest_threat_level`	Highest threat level across contributing detections: `NONE`, `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`. Always one of these literal strings, never `null`. May be `NONE` when the action came from an always-fire policy condition (for example, always-on redaction) with no active detection.

Use session_id and interaction_id to correlate an outcome with the reconstructed session in the Console, where interaction_id identifies the specific message within it. See Agentic Sessions.

Delivery

Enable the Runtime Policy Outcomes data source on an integration. Each destination documents the setup and shows the payload as that destination receives it.

Destination	Guide
Webhook	Webhook Integrations
Splunk	Splunk
Azure Sentinel	Microsoft Azure Sentinel

A webhook or Splunk destination can subscribe to one or more data sources. An Azure Sentinel configuration carries exactly one, because a Log Analytics custom table has a single schema. You do not need to author a policy first. Every tenant is provisioned with a Default Policy whose HiddenLayer-authored system rules run in Detect mode for prompt injection, URL and hyperlink presence, and code presence, so configuring a destination is enough to start receiving outcomes. See Configure Policy in the Console to customize enforcement.

How outcomes relate to convictions

Convictions are produced by AI Runtime Security; outcomes are produced by Agentic Runtime Security. The two are not interchangeable — an outcome carries the full policy evaluation, which is richer than a conviction. Interactions evaluated by Agentic Runtime Security do not emit convictions, so enable the Runtime Policy Outcomes data source on any integration that should keep receiving events for that traffic.

Integrations

Put Agentic Runtime Security in front of your AI traffic with a guardrail or gateway integration.

​How it works

​What an outcome contains

​Delivery

​How outcomes relate to convictions

​Next

Integrations

How it works

What an outcome contains

Delivery

How outcomes relate to convictions

Next