Policies

A policy is a named group of one or more rules, stored in your Opik workspace. Your application references the policy by name rather than spelling out the checks itself.

That splits the work cleanly in two. Policies are created and edited in the Opik UI, and the SDK’s job is to fetch them and run the checks. Changing what a guardrail enforces — adding a category of personal data, restricting another topic — is something a teammate does in the UI, with no code change and no redeploy.

This is how we recommend running guardrails. It keeps the checks visible to everyone on the team, lets you tighten them in response to something you saw in production without waiting on a release, and applies the same protection consistently across every application that references the policy.

Create a policy

Open Guardrails in the sidebar, then choose Create policy.

A policy has a name, an optional description, an execution scope, and the rules it runs.

1

Name it

The name is what your application passes to the SDK, so pick something that reads well in code — no-contact-information, support-tone. Names are unique within a workspace.

Applications reference a policy by name. Renaming a policy that is already in use breaks every application still asking for the old name, so treat the name as part of your public interface.

2

Choose an execution scope

• On request — the policy applies only to applications that name it. This is the default.
• Global — the policy applies to every application in the workspace, whether or not it names the policy. Use this for baseline protection you want enforced everywhere, such as blocking personal data.

3

Switch on the rules it runs

Turn on the checks you want and configure each one. A policy holds at most one rule of each type, so a policy is a set of distinct checks rather than a list that can repeat.

A policy can hold the PII, Topic, and Prompt injection rules. PII asks which categories of personal data to block, Topic takes lists of allowed and restricted topics, and prompt injection has nothing to configure.

The rule types are described in full on the Rules page. The LLM judge and custom classifier rules are not stored in policies: define them in code.

Use a policy in your application

Build a guardrail from stored policies with Guardrail.from_stored_policies, then call validate exactly as you would with a guardrail defined in code:

from opik.guardrails import Guardrail
from opik import exceptions
guardrail = Guardrail.from_stored_policies(names=["no-contact-information"])
try:
    guardrail.validate("Call me at 555-0123")
except exceptions.GuardrailValidationFailed as e:
    print("Guardrail failed:", e)

Pass several names to combine policies. Their rules are checked together as one set, and the guardrail fails if any single rule fails:

guardrail = Guardrail.from_stored_policies(
    names=["no-contact-information", "support-tone"],
)

Global policies are included automatically, so a workspace-wide rule applies even to an application that names nothing:

# Runs every global policy in the workspace
guardrail = Guardrail.from_stored_policies()

A few things worth knowing about the call:

• Policies are read once, when you build the guardrail. Build it at startup rather than on every request, and restart (or rebuild the guardrail) to pick up a change made in the UI.
• Every name you pass must exist. A name that does not is an error, rather than a check quietly not running.

Manage policies

The Guardrails page lists every policy in the workspace with the rules it holds, its execution scope, and who created it and when it last changed. Selecting a row opens the policy for editing, and the row menu offers Duplicate — a quick way to build a variant without retyping the rules.

Saved changes apply to every application that references the policy the next time it builds its guardrail.

Next steps