Roll out an OPA policy globally

This guide marks a saved policy definition as a global appliance-wide assignment for a surface type, then switches it to monitor-only mode right away so you can observe what it would deny before it blocks real traffic for long. For the conceptual model, see OPA policies →.

Attaching the same policy to every surface one at a time, as in Control access to a surface with an OPA policy, does not guarantee every surface actually carries it, and a mistake in a policy that goes straight to enforcing could lock out every surface of that type at once.

Use this guide when:

• One policy, such as a baseline compliance rule, should apply to every LLM or IDE surface, not be configured per-surface.
• You are rolling out a new organisation-wide rule and want to observe its effect before it can block real traffic.
• Individual surfaces should not be able to opt out of a mandatory rule.

You do not need a global assignment if a policy only matters on one or two specific surfaces; attach it directly to those surfaces instead.

Prerequisites

• A saved policy definition of type llm or ide. See Control access to a surface with an OPA policy if you do not have one yet.
• Administrator role in the dashboard.

Steps

Open the policy in the dashboard

Select Policies in the dashboard sidebar and switch to the tab matching your policy’s type (LLM or IDE). There is no separate global-assignment screen: global enforcement is a switch on the policy’s own row in this same list.

Turn on global enforcement in monitor-only mode

On your policy’s row, turn on the Global switch. A confirmation popover appears; select Continue to enforce this policy across every surface of that type. Turning Global on always enforces for real immediately, there is no way to start it directly in monitor-only mode, so turn on Monitor only on the same row right afterward, without delay, so the policy stops blocking and instead only logs what it would have denied.

Observe what the policy would have denied

Let real traffic run for a representative period. Check the appliance’s audit log (administrator-only by default) for decisions this assignment recorded, to see what it would have blocked had it been enforcing. A logged deny looks identical whether or not Monitor only is on, the entry itself does not say which; rely on the assignment’s own Monitor only state on the Policies page, not the audit entry, to know whether a given decision actually blocked the request.

Turn off monitor-only to enforce

Once you are satisfied the policy denies only what it should, turn off Monitor only on the assignment. From this point, a deny from this policy blocks the request on every surface of the type, ANDed with each surface’s own policy set.

Confirm

Replace <YOUR_APPLIANCE_HOST> and <YOUR_SURFACE_ROUTE> with a surface of the type your assignment targets, and use a request your policy is written to deny.

Test 1: in monitor-only mode, a would-be deny still returns 200

curl -k -X POST "https://<YOUR_APPLIANCE_HOST><YOUR_SURFACE_ROUTE>/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      { "role": "user", "content": "Say hello." }
    ]
  }'

The -k flag disables TLS certificate verification. Use this for local testing only. Remove it in production.

Expected: 200 OK, since Monitor only is still on. Confirm the audit log recorded a would-be deny for this request from the global assignment.

Test 2: after disabling monitor-only, the same request returns 403

Turn off Monitor only and resend the identical request. Expected: 403 Forbidden, now enforced for real across every surface of that type.

Troubleshooting

Next steps

• Control access to a surface with an OPA policy: Add a surface-specific rule on top of this global baseline.
• Verify caller credentials with VP evidence: Extend a global policy to gate on a verified credential, not just claims.
• Limit dashboard actions with RBAC roles: Restrict who can create or edit a global policy assignment in the first place.

Related

• OPA policies reference: The global assignment fields and how they combine with a surface’s own policy set.
• RBAC reference: The policy-management and audit-log permissions this guide depends on.
• Observability: Where policy decisions surface alongside other request telemetry.