Skip to main content
The Policies tab (under Settings → Workspace → Guardrails) is the working list of every guardrail policy in your tenant. From here you create policies, change a policy’s mode and priority inline, dry-run-test it, and delete it.
Preview — policies do not enforce at runtime yet. Anything you create, toggle, or delete here is stored and testable, but is not wired into the live turn pipeline in v1. Use Testing a policy to observe behavior, and see How guardrails enforce today for what is live.
A new tenant starts with zero policies — nothing is pre-installed. The tab shows an empty state with a New policy button until you create your first one.

​
Reading a row

The table condenses each policy into a small set of columns:
  • Policy. The display name, with the underlying built-in shown beneath it as a built_in/<id> reference.
  • Stage. input, tool, or output — fixed by the built-in you chose.
  • Mode. An inline dropdown: enforce, monitor, or disabled. Changing it saves immediately, no separate edit screen.
  • Priority. An inline number field. Higher runs first. Saves on change.
  • Actions. An overflow menu with Test (dry-run) and Delete.
A count above the table (N policies) reflects the total. A Mode filter in the toolbar narrows the list to enforce, monitor, or disabled.
There is no Type column, no per-agent scope column, and no editable action or config controls. Each built-in’s action and stage are fixed; you tune only mode and priority per policy.

​
Creating a policy

Click New policy. The dialog has exactly three fields:
1

Built-in

A dropdown of the three built-in guardrail types, each labelled with its stage — Prompt Injection Defense (input), PII Redaction (output), and High-Risk Tool Approval (tool). Selecting one shows its description.
2

Name

A display name for the policy. Required.
3

Description

An optional note for other admins.
There is no stage, action, scope, regex, or template field — those are pinned by the built-in. New policies are always created in Monitor mode and inherit the built-in’s default priority, regardless of which built-in you pick. Adjust mode and priority from the row afterward.

​
Editing a policy

Editing is inline, from the row:
  • Mode — switch between enforce, monitor, and disabled in the dropdown.
  • Priority — type a new number.
Both save on change. The policy’s built-in, stage, and action cannot be changed after creation — to switch built-ins, delete the policy and create a new one.

​
Deleting a policy

Open the row’s overflow menu and choose Delete. Any policy can be deleted, including built-in-backed ones — there is no “cannot be deleted” restriction in v1. Deletion is immediate.

​
Priority and order of evaluation

Within a stage, policies are grouped by priority and the highest priority group runs first. Guardrails in the same priority group run concurrently. A Block short-circuits the rest of that stage.
Because authored policies don’t enforce yet, priority ordering matters for dry-run reasoning and for when the runtime wire-in ships — not for live traffic today.