OPA policies

See OPA policies → for the conceptual model: the embedded policy engine, deny-overrides, and why an in-process policy engine adds no network hop. This page is the field-level reference: the Rego package each policy type declares, the policy editor, the input document a policy is evaluated against, and the two surface-level blocks (OPA Policy, VP Evidence) that turn evaluation on for a surface.

Evaluation layers

You create policies of three types, one per tab on the Policies page: Trust Fabric, LLM Policies, and IDE Policies. Each type’s Rego must declare a fixed package:

On an LLM Surface, inbound policy runs after source authentication. VP evidence, when enabled, is verified first. The appliance-wide (global) policies for the surface type run next, then the surface’s own OPA policy. Both are deny-overrides and fail-closed, so a deny from either one blocks the request, unless the deny comes from a global policy set to Monitor only.

A policy definition’s type (Trust Fabric, LLM, or IDE) determines the package its Rego must declare, and a mismatch is rejected at write time.

A gateway can enforce more than one policy definition at once, and a surface’s own policy is combined with any global policies for its type. The set is evaluated deny-overrides: every member must independently return allow = true, and the first to deny (or error) blocks the request. An account with permission to publish policies, Administrator by default, can additionally mark one or more definitions of any type as enforced globally across every surface of that type (for Trust Fabric, every gateway connection), ANDed with each surface’s own set. Each global assignment carries its own monitor-only flag so a would-be deny is evaluated and logged, but does not block the request, while the policy’s effect is observed before it goes live.

A missing or failed-to-compile engine for an enforced gateway or surface fails closed: the request is denied rather than let through. This is recorded in policy audit evidence as a missing_engine outcome.

Rego companion reason rules

Alongside allow, a policy’s package may declare allow_reason and deny_reason rules (derived from the query path by swapping the trailing .allow) to supply a human-readable message that flows into policy audit logs and observability:

package llm.policy
default allow = false
allow if { input.source_auth.claims.role == "admin" }
allow_reason := "Admin bypass" if allow
deny_reason := "Only admin callers may use this surface" if not allow

On an allow with no allow_reason rule, reason stays absent. On a deny with no deny_reason rule, the fixed fallback "Policy denied request" is used.

A handful of Rego builtins are rejected at write time regardless of layer:

Compiled policies also run under a fixed evaluation time limit and a fixed source-size limit, both non-configurable.

Policy definitions

A reusable Rego policy is what you create and edit on the Policies page: write it once, then reference it from as many surfaces (or a global assignment) as need the same rule, and every enforcement point picks up the exact version you save. Every save that changes the Rego is kept as a numbered version, listed in the editor’s Version history panel.

• Type has to match where you’ll enforce the policy: Trust Fabric for appliance-to-appliance traffic, LLM for LLM Surfaces, IDE for the IDE catalogue front door and its per-model policies. The Rego package has to match too, or the save is rejected. Type is locked once you save; changing it later means creating a new definition.
• Clear Enabled instead of deleting a policy you might reuse later. A disabled definition is skipped from any set that references it.
• Keep the sample input current as you edit the policy, so the Test (dry-run) panel keeps testing the case you’re actually trying to catch.

Once a policy has been saved, the editor also shows two panels:

• Test (dry-run): runs the Rego currently in the editor, saved or not, against a sample input with Run against the draft above. Nothing is enforced. The sample is saved with the policy.
• Version history: every saved version, with its Version, Name, Created, Author, and Description, a current badge on the version in force, and a comparison of any version with the current one.

A save that changes the Rego body adds a new version and makes it the enforced one; a save that only changes metadata (name, description, enabled) updates the current version in place. Past versions are kept for as long as the policy exists. Bindings resolve a policy by its ID, so renaming a policy leaves everything that enforces it working.

Sample input

The sample input in the Test (dry-run) panel lets you re-run a stored request against your policy before saving an edit. A good sample:

• Is real JSON matching the input document shape below, not a partial fragment. A policy that reads input.source_auth.claims.role needs a sample that actually populates source_auth.claims, or the dry-run won’t reflect what a live request looks like.
• Covers the specific caller and request shape your policy branches on. If your Rego has different rules for JWT-authenticated versus mTLS-authenticated callers, save (or keep swapping in) a sample for each path you need to check.
• Is updated whenever you add a new condition to the policy, so the dry-run keeps testing the case that condition is meant to catch, rather than a stale sample from an earlier version of the policy.

Global (appliance-wide) policy assignments

Held per policy type (Trust Fabric, LLM, IDE), enforced on every surface (or, for Trust Fabric, every gateway connection) of that type, independent of each surface’s own OPA Policy configuration and evaluated deny-overrides alongside it. It’s the right tool for an organisation-wide requirement, such as always checking a trust registry, that shouldn’t depend on each surface owner remembering to add it.

Global assignments are set on the Policies page itself: switch to the tab matching the policy’s type (Trust Fabric, LLM Policies, or IDE Policies), and each policy’s own row carries a Global switch. Making a policy global needs permission to publish policies, which defaults to Administrator; without it, the switch is disabled. Turning it on opens an Enforce globally confirmation; selecting Continue enforces that policy straight away across every surface (or gateway connection) of that type. The Monitor only checkbox then appears next to the switch.

• Before a new global policy goes live, check it with the Test (dry-run) panel. Once it is global, tick Monitor only straight away if you want to watch its decisions before it blocks traffic.
• Clear Monitor only once you’ve confirmed the policy’s decisions look right, so it actually enforces.

Input document

Every policy layer evaluates against a single, versioned input document (schema version 1). Only the fields relevant to the current request are populated; everything else is omitted.

Surface-level policy block

The OPA Policy block is the surface-level block, available on an LLM Surface, that connects a surface to the policies you’ve written and turns Rego enforcement on for its inbound traffic. There is no separate enabled toggle: dragging the OPA Policy element onto the canvas is what turns it on, and removing the element turns it off. When present and a policy is referenced, requests are evaluated after source authentication, with source authentication’s identity, the request’s headers, and everything else in the input document available to the Rego rule, and denied (403) on allow = false.

• Reference a single Policy Definition to enforce it on this surface. To combine more than one policy on the same surface, enforce the additional policy or policies globally instead (see Global (appliance-wide) policy assignments); a global assignment is ANDed with this surface’s own policy, deny-overrides.
• Log OPA decisions logs the full input JSON, including request headers and caller identity, which makes it a debugging aid rather than something to run in production.

VP evidence

The VP Evidence block governs per-surface verifiable-presentation evidence. When enabled, a VP the caller sends with the request, in a request header or a JSON body field, is verified first and its holder/issuer/claims are passed to policy as identity-binding data (input.identity_binding, above). That lets a Rego rule check input.identity_binding for a VP from a specific issuer (for example, “allow only if a VP from a known issuer is present”) without having to verify the presentation itself.

• Deny when no VP is presented denies the request outright, before the policy even runs, whenever a VP is mandatory for the surface: a belt-and-braces gate on top of whatever the policy decides.
• If a VP is only optional context that some callers provide, leave that toggle off and let your Rego decide what to do when input.identity_binding is absent.
• VP carried in defaults to Request header; switch it to JSON body field only for callers that send the presentation there instead.

Versioning and immutability

Every save of a policy definition that changes its Rego body appends a new, immutable, monotonically numbered version. Prior versions are kept unchanged for as long as the policy exists. A metadata-only edit (name, description, enabled) updates the current version’s record without appending.

Every policy decision is recorded in audit evidence against the exact policy definition ID, resolved version, and content hash that was enforced, so a past decision can be proven against the precise policy bytes that produced it. The content hash binds both the policy’s type and its Rego body, so identical Rego stored under a different scope hashes differently.

A policy also keeps its Test (dry-run) sample input, so an operator can re-run it against an edited policy before saving.

Related

• OPA policies concept: The embedded policy engine, why in-process evaluation adds no network hop, and how policy types are enforced.
• Core configuration: Where OPA Policy and VP Evidence sit among a surface’s other optional blocks.
• Control surface access with an OPA policy: Write a policy definition and attach it to a surface’s OPA Policy block.
• Roll out an OPA policy globally: Turn on a global assignment and watch it in monitor-only mode before letting it enforce.
• Verify caller credentials with VP evidence: Gate a policy on a cryptographically verified issuer and claims via the VP Evidence block.