Skip to main content
Guardrail Rules define conditions under which Evaluators (automated checks that inspect a request or response) run against requests passing through the AI Gateway. Conditions are written as CEL expressions, built visually with the Rule Builder covered below. A guardrail is only triggered when its rule conditions are matched, not on every request.

​
Use cases

Guardrail rules are most useful when the same safety or compliance check needs to apply consistently across many requests.
Runs a jailbreak detection Evaluator on all customer-facing requests at the gateway level, adding an extra security layer across AI Gateway traffic.
Enforces GDPR compliance by running PII detection on all matching requests workspace-wide from a single rule.
Validates customer detail access for the sales team by calling an external Evaluator on every matching request before it reaches the model.
Applies a tone of voice Evaluator at the gateway level so every response is checked against the company’s tone guidelines.
Runs a compliance Evaluator on EU-routed requests only, scoped using the Rule Builder so the guardrail applies exactly where it is needed without affecting other traffic.
Runs jailbreak detection and response relevance Evaluators at 50% sample rate each, scoped to specific traffic using a metadata condition in the Rule Builder.

​
Visibility

  • Visible to workspace administrators only.

​
Creating a guardrail rule

From the Guardrail Rules list, click Add New Rule. A panel opens on the right with the following fields.
Create Guardrail Rule

Create Guardrail Rule panel in the AI Gateway.

​
General

​
Evaluators

Select the Evaluators to run when this rule is triggered. Click Add to attach one or more evaluators from the scoped project. The Add menu groups options into System and Workspace: Workspace evaluators are the project’s custom evaluators; System guardrails are covered below.

​
System Guardrails

System Guardrails are the pre-built checks Orq.ai maintains in the Evaluators list’s System group. Attach one and it runs immediately as a pass/fail check that can block a request; it never rewrites content. Toggle the icon next to a System Guardrail in the Evaluators list to switch it to monitoring-only mode. The same check still runs and its result is still recorded, but a match no longer blocks the request. The detectable entity catalog for PII Detection is shared with the PII Redaction plugin, and is region-scoped rather than language-scoped. GET /v2/pii/capabilities is the live source of truth for the supported regions, base and regional entity types, and the region_entities mapping. A few entity type names changed when the catalog moved to regions; the old keys are rejected at write time. Each guardrail runs on the request Input, the model Output, or both. Click the icon next to a guardrail in the Evaluators list to cycle through Input, Output, and Both, set independently per guardrail.
System Guardrails always fail closed: if the underlying check errors (for example the detection service is unavailable or the call itself fails), the guardrail blocks the request instead of letting it through unchecked.

​
Rule Builder

The Rule Builder constructs the match conditions that determine when the guardrail is triggered. Clicking Add opens a dropdown with the following condition types: You can also click Add group to nest conditions into a logical group. Multiple conditions within a group are joined with and. Groups themselves can be joined with either and or or. Select the operator between groups to control how they combine. Each condition can be removed with . The builder generates a CEL (Common Expression Language) expression shown read-only in the CEL Expression Preview below. The guardrail is only triggered when the expression evaluates to true.