Policies and Enforcement

Xenovia evaluates Open Policy Agent (OPA) Rego policies on every proxied request. Policies are created in the control plane, attached to a proxy, and enabled. Each proxy can run policies at two stages:

Request stage — before the request is forwarded to the upstream model.
Response stage — after the model responds, before the reply reaches your app.

Enabled policies are compiled to a per-proxy snapshot, pushed to the runtime, and revalidated by each runtime instance about every five minutes. OPA evaluates with a 2-second compile timeout and a 200-millisecond per-stage evaluation timeout.

The decision contract

A policy returns a single decision object. This is the only value the runtime reads — allow/deny rules or a bare redact_fields set are ignored.

package xenovia

import future.keywords.if
import future.keywords.in

# Allow by default; a matching rule below overrides it.
default decision = {"action": "allow"}

decision = {"action": "block", "rule": "no-delete-tools"} if {
    some tool in input.tool_names
    tool == "delete_database"
}

Write package xenovia. The control plane strips your package line and re-packages the rule under a system namespace, so the package name you choose does not matter.
action is required; rule is a short identifier recorded on the trace. Any other key (including reason) is ignored by the runtime.
Multiple complete decision rules must have mutually exclusive conditions. If two can be true at once, OPA reports a conflict and the request fails closed. Guard each rule with distinct conditions (for example on input.agent_role).

The Rego is compiled with opa check --strict when you save it. Compilation errors are returned as 422 with the OPA diagnostics.

Actions

Stage	`action`	HTTP result	Effect
Request	`allow`	—	Forward to the model
Request	`block`	`403`	Terminate; record the trace
Request	`redact`	—	Remove the listed fields from messages and tool definitions, then forward
Request	`escalate`	`403`	Terminate and record an escalation signal (see Escalations)
Response	`allow`	—	Return the reply
Response	`block_response`	`403`	Suppress the reply; record the trace
Response	`redact_response`	—	Remove the listed fields from the reply, then return it
Response	`escalate`	—	Record-only at the response stage

When several enabled policies run at the same stage, the strongest action wins: block over escalate over redact over allow (and block_response over redact_response at the response stage). An unrecognised action ranks below allow and can never block.

Redaction

Return the labels to strip in redact_fields:

package xenovia
import future.keywords.if
import future.keywords.in

default decision = {"action": "allow"}

decision = {
    "action": "redact",
    "rule": "mask-contact-details",
    "redact_fields": ["email", "phone"],
} if {
    some msg in input.messages
    contains(msg.content, "@")
}

Supported labels: email, ssn, phone, creditcard (Luhn-validated), ip, url. Redaction applies to message text, tool descriptions, and the Responses instructions field at the request stage, and to the reply text at the response stage. Redaction is not applied mid-stream; a streamed response that matches a redact_response rule is passed through unredacted and the event is recorded.

Monitor vs enforce

Enforcement is a property of the policy, set in the dashboard (Monitor or Enforced) or through the API, not something you express in Rego:

Enforced policies apply their action.
Monitor policies are evaluated and their would-be decision is recorded on the trace, but the action is never applied. Use monitor mode to trial a policy against live traffic before enforcing it.

Policy input

Both stages receive the same base fields; each stage adds its own.

Base fields (both stages)

{
  "agent_id":      "string — proxy ID",
  "org_id":        "string — organization ID",
  "request_type":  "chat_completion | chat_completion_stream | responses | responses_stream",
  "provider":      "resolved upstream provider (openai, anthropic, gemini, azure, bedrock, groq, vllm)",
  "model":         "the model the runtime will call — the proxy's configured model, not the value your client sent",
  "stream":        "boolean",
  "messages":      "[{ role, content, tool_call_id?, tool_call_ids? }] — text only",
  "tools":         "[{ Name, Description, ParametersSchema }] — note the capitalised keys",
  "tool_names":    "[]string — lowercased tool names, convenient for allow/deny lists",
  "system_prompt": "string — first system message, if any",
  "agent_role":    "string — present only when the x-xenovia-agent-role header is sent",
  "http_headers":  "object — request headers, with secret values redacted"
}

Request stage adds

{
  "request":             "object — the normalised request (parameters under request.params)",
  "request_flat":        "object — the same request flattened to dotted keys",
  "request_max_tokens":  "int — requested output cap, 0 if unset",
  "tool_results":        "[{ tool_call_id, name, content }] — Chat Completions only",
  "proxy_tokens_today":  "int — running token count for this proxy today",
  "session_tokens_used": "int — running token count for this session",
  "workflow_context":    "object — prior cross-proxy decisions, only with a workflow header"
}

intent_score and intent_action are not available at the request stage — policy runs before intent scoring. They are available at the response stage.

Response stage adds

{
  "stage":  "response",
  "output": {
    "content":    "string — the reply text",
    "tool_calls": "[{ id, name, arguments }]"
  },
  "usage":         "{ input_tokens, output_tokens, total_tokens }",
  "intent_action": "allow | block | escalate",
  "intent_score":  "float 0.0–1.0"
}

Examples

Block a tool

package xenovia
import future.keywords.if
import future.keywords.in

default decision = {"action": "allow"}

decision = {"action": "block", "rule": "no-destructive-tools"} if {
    some tool in input.tool_names
    startswith(tool, "delete_")
}

Require the proxy’s model to be on an allowlist

package xenovia
import future.keywords.if
import future.keywords.in

default decision = {"action": "allow"}

approved := {"gpt-4o", "gpt-4o-mini", "claude-sonnet-4-20250514"}

decision = {"action": "block", "rule": "model-allowlist"} if {
    not approved[input.model]
}

input.model is the model configured on the proxy, so this rule guards against a proxy pointed at an unapproved model rather than a client choosing one.

Cap output tokens (request stage)

package xenovia
import future.keywords.if

default decision = {"action": "allow"}

decision = {"action": "block", "rule": "output-cap"} if {
    input.request_max_tokens > 2000
}

Block a refusal in the reply (response stage)

package xenovia
import future.keywords.if

default decision = {"action": "allow"}

decision = {"action": "block_response", "rule": "no-refusal"} if {
    input.stage == "response"
    contains(input.output.content, "I cannot help")
}

What a block looks like to your app

A blocked request returns 403. The runtime uses the gateway error envelope:

{
  "is_bifrost_error": false,
  "status_code": 403,
  "error": { "message": "request blocked by policy" },
  "extra_fields": {}
}

The OpenAI SDK raises this as PermissionDeniedError. The message is deliberately generic; the rule that fired is recorded on the trace, not returned to the caller. The X-Xenovia-Trace-Id response header identifies the trace.

Escalations

escalate is for actions you want flagged for human attention. When a request-stage rule (or the intent guardrail) escalates:

The request is blocked with 403 (request escalated for human review).
An escalation signal is recorded, carrying the proxy, score, and matched rule.
Any alert rule watching for escalations fires (see Alerts).

There is no approve/deny queue today. An escalation blocks the request and raises a signal; it does not pause the request for an operator to release. Review escalations in Sessions and in Alerts, then adjust the policy or intent configuration. Reasons are recorded server-side and are never returned to the agent.

Start Here

Integrations

Platform

Policies and Enforcement

The decision contract

Actions

Redaction

Monitor vs enforce

Policy input

Base fields (both stages)

Request stage adds

Response stage adds

Examples

Block a tool

Require the proxy’s model to be on an allowlist

Cap output tokens (request stage)

Block a refusal in the reply (response stage)

What a block looks like to your app

Escalations

​The decision contract

​Actions

​Redaction

​Monitor vs enforce

​Policy input

​Base fields (both stages)

​Request stage adds

​Response stage adds

​Examples

​Block a tool

​Require the proxy’s model to be on an allowlist

​Cap output tokens (request stage)

​Block a refusal in the reply (response stage)

​What a block looks like to your app

​Escalations

The decision contract

Actions

Redaction

Monitor vs enforce

Policy input

Base fields (both stages)

Request stage adds

Response stage adds

Examples

Block a tool

Require the proxy’s model to be on an allowlist

Cap output tokens (request stage)

Block a refusal in the reply (response stage)

What a block looks like to your app

Escalations