Skip to main content
The dry-run tester runs a single policy against a sample you supply and shows exactly what it would decide — the aggregate action plus each guardrail’s observation. It writes no audit entry and has no runtime side effects.
This is the way to observe a policy’s behavior in v1. Because authored policies do not yet enforce at runtime (see How guardrails enforce today), the dry-run is the only place you’ll see a policy fire. Requires the guardrail.test capability.

​
Running a dry-run

1

Open the tester

From the Policies table, open a row’s overflow menu and choose Test. A dry-run panel opens beneath the table for that policy.
2

Enter sample input

Type a sample input — the user message, response text, or tool-argument payload the policy should evaluate. The tester infers the stage from the policy and builds a synthetic context around your text.
3

Optionally override the mode

Leave mode override on Use policy mode, or pick enforce, monitor, or disabled to answer “what would happen if I flipped this policy to that mode?” without changing the saved policy. A policy evaluated as disabled returns Allow without invoking the rule.
4

Run the test

Click Run test. The result renders in place.

​
Reading the result

The response has two levels:
  • Aggregate — the single action the stage would produce (allow, block, confirm, or modify) and a reason. This is what the caller would see.
  • Observations — one line per guardrail that ran, showing its name, the mode it ran in, its action, and its reason. This is where you see why the aggregate came out the way it did.
Every result ends with the note “DRY RUN — no audit emitted, no runtime side effects.” as a reminder that nothing was recorded or enforced.
A good tuning loop: create the policy in Monitor, dry-run it against a handful of representative real and adversarial samples, override the mode to enforce to confirm the aggregate flips as expected, then switch the saved policy to Enforce once the runtime wire-in ships.

​
Behind the scenes

The tester calls POST /api/admin/guardrails/policies/{id}/test. It constructs a synthetic context from your sample and evaluates just that one policy — it does not run the rest of your policy set, does not touch the real turn pipeline, and does not persist anything.
The API also accepts an optional structured context (actor roles, capabilities, tool name) for tool- and input-stage tests. The console form exposes sample input and mode override; richer context can be supplied through the API directly. Verify field names against your deployment before relying on them.