Skip to main content
Guardrails are an admin-configurable safety layer: a place to author tenant policies that block dangerous inputs, redact sensitive output, and gate high-risk tool calls, without writing any code. You pick a built-in guardrail, name it, and tune its mode and priority.
Preview — authored policies do not enforce at runtime yet. In v1 you can create, edit, toggle, and dry-run-test policies, but the policies you save in this console are not yet wired into the live turn pipeline. The runtime enforces a separate, fixed set of built-ins today. The dry-run tester is the way to observe exactly what a policy would do. See How guardrails enforce today for what is and isn’t live.

​
The three built-in guardrail types

Every policy wraps one of three built-in guardrails. There are no custom or template policies in v1, and none are pre-installed — a new tenant starts with zero policies. Each built-in has a fixed action and stage. There are no tunable thresholds, sensitivity levels, or extra-pattern controls — you choose the built-in, then set only its mode and priority.

​
Stages: when a guardrail runs

A policy belongs to exactly one of three stages:

​
Modes: Enforce, Monitor, Disabled

Every policy runs in one of three modes. New policies are always created in Monitor. A typical rollout: create in Monitor, dry-run-test against representative samples, then switch to Enforce.

​
Actions a guardrail can take

When a guardrail evaluates, it returns one of four actions:
There is no separate “Redact” or “Warn” action. Redaction is a Modify; there is no Warn — a would-be warning is a Monitor-mode observation.

​
Priority and order

Within a stage, guardrails are grouped by priority and higher priority runs first. Guardrails in the same priority group run concurrently. A Block short-circuits the rest of the stage.

​
Pages in this section

1

Policies

Create, edit, toggle, and delete the guardrail policies in your tenant. See Policies.
2

Testing a policy

Dry-run a policy against sample input and read the aggregate plus per-guardrail observations — the only way to see a policy’s behavior today. See Testing a policy.
3

How guardrails enforce today

What actually runs in the live turn pipeline right now, and how it differs from the authoring console. See How guardrails enforce today.

​
Things to know up front

  • Authored policies are a preview. They are stored and testable, but the runtime does not read them yet.
  • Guardrails are tenant-scoped. Policies apply only to your tenant. Super admins switch tenants from the top of the Admin Console.
  • The tab is capability-gated. Viewing requires guardrail.read; creating, editing, and deleting require guardrail.update; dry-run requires guardrail.test.