Guardrails

A guardrail is one check AskRAI runs over one payload of a turn. Every guardrail is three decisions made independently of each other: a kind that decides how the check is performed, a stage that decides which payload it reads, and an action that decides what happens when it fires.

Those three are what the rest of this page is about. One more setting does change behaviour: priority is the order guardrails are evaluated in, and it decides which blocker is reported as the reason. The category is a label for the people reading the console.

Kind — how the check is made

Six kinds ship today. Five of them are evaluated in code: they cost no model call, add no provider latency, and give the same answer every time.

The last column matters because Redact is an action a kind has to be able to perform. A judge returns a verdict rather than the position of what it objected to, and a link-domain check has nothing to substitute, so neither can redact. The console refuses that combination when you save it rather than at runtime.

Stage — which payload it reads

A rule phrased as a constraint on the response is enforceable: set its stage to Output. Set that same rule on Input and it fires on nothing and reports compliance on every turn.

Redact means something different at each stage. On Input it rewrites the question, and what continues into retrieval — and what the audit record stores as the question — is the rewritten text. On Output it rewrites what is delivered. On Tool call it refuses the call entirely: a redacted argument is a different call to the far side, and sending one the model never wrote would be worse than not sending it at all.

Action — what happens when it fires

There is no majority rule and no scoring: one blocking guardrail is enough. A Warn does not stop the turn — its effect is the record it leaves, which is why it is worth reviewing the audit trail for warnings rather than waiting for something to break.

How an evaluation runs

The deterministic kinds are evaluated first, one after another in priority order. The LLM judges run afterwards, concurrently — at most three at a time. If something has already blocked, only the judges that would Block are skipped; a Warn judge still runs. (A judge cannot be set to Redact — see the table above.)

Three consequences follow from that order:

• A regex settles what a judge would be billed to decide. This one is free: the deterministic kinds always run before any judge, whatever priority you give them, so a cheap check that blocks keeps the turn off a model. Priority does not control it.
• Priority orders the deterministic checks among themselves, lowest number first, and when several would block, the first is the one reported as the reason. Note that the console's bands run the other way — it labels 8–10 High and 1–4 Low — so a guardrail in the Low band is evaluated before one in the High band, and is the one an administrator is told about. Set the number you want evaluated first to the lowest value, not the highest.
• A redaction earlier in the order changes what every later guardrail reads. A PII guardrail that redacts at priority 1 means the judge at priority 9 sees the redacted text, not the original.

Once a deterministic check has blocked the turn, blocking judges are skipped — their verdict cannot change the outcome and the tenant should not be billed for it. Judges set to Warn still run, because they were attached to observe exactly these turns and a skipped one would report "never fired" on the population it exists to watch.

When a guardrail cannot be evaluated

AskRAI stops the turn instead of allowing it. A control that quietly stops checking while still reporting compliance is the failure this whole plane exists to prevent, so it is the one outcome the evaluator will not produce. A turn fails closed when:

• an LLM judge names a model that no longer resolves, or the tenant has no model configured for the guardrail stage;
• a pattern runs long enough to be abandoned;
• a Block or Redact guardrail is handed a payload longer than 100,000 characters — neither "I refused all of this" nor "I handled every span in this" can be said honestly about a prefix. A Warn guardrail scans the first 100,000 characters and says so in its record;
• a guardrail was written by a newer build than the one evaluating it. Only the subjects that attached it fail; everyone else in the tenant is unaffected.

Where a guardrail comes from

A guardrail governs a subject, never the tenant at large.

• For a person asking a question, the subject is their groups — the union of every guardrail listed by every group they resolve into.
• For a team agent, the subject is the agent itself.

Either can also carry policies, and a policy brings its own guardrails. All of those sources compose into one effective set, under a single rule: every merge is a narrowing. Guardrails union together, ceilings take the lower value, and a host must be admitted by every allowlist in force. Attaching a second policy can tighten what a subject may do and can never loosen it — so there is no "bypass" group, and no way to exempt one population by adding something to it.

Only guardrails whose status is Active take part. A draft governs nothing, however carefully it is written.

What is recorded

Every evaluation — pass or fail — is written to the audit trail and counted in the analytics. There is no setting that reduces this. A redaction records how many spans it replaced and never the values, which would put the content back into the record the redaction exists to keep it out of.

Administrators can mark a guardrail trigger as a false positive in the conversation logs. Those marks drive the per-guardrail false-positive rate on the guardrail analytics, which is how you find a rule that fires too eagerly without weakening it blind.

Next steps

• Settings → Guardrails — author a guardrail's kind, stage, action and status
• Guardrails — review how each one is performing
• Policies — attach a set of guardrails, and ceilings, to a group or an agent
• Governance & Audit — how evaluations feed the audit trail
• Sandbox — test guardrail behaviour before it reaches production