> ## Documentation Index > Fetch the complete documentation index at: https://docs.orq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Guardrail Rules > Configure guardrail rules in the AI Gateway to validate and control LLM requests and responses with evaluators triggered by CEL conditions. Guardrail Rules define conditions under which [**Evaluators**](/ai-studio/optimize/evaluators) (automated checks that inspect a request or response) run against requests passing through the [**AI Gateway**](/ai-gateway/get-started/introduction). Conditions are written as CEL expressions, built visually with the Rule Builder in the Conditions section covered below. A guardrail is only triggered when its rule conditions are matched, not on every request. Guardrail Rules run on LLM requests and responses only. They do not run on tool calls served through an [**MCP Gateway**](/ai-gateway/mcp-portal/mcp-gateways); the [plugins attached to an MCP Gateway](/ai-gateway/mcp-portal/mcp-gateways#plugins) are the control for MCP tool traffic. ## 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**](/ai-studio/optimize/evaluators) 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**](/ai-studio/optimize/evaluators) on every matching request before it reaches the model. Applies a tone of voice [**Evaluator**](/ai-studio/optimize/evaluators) at the gateway level so every response is checked against the company's tone guidelines. Runs a compliance [**Evaluator**](/ai-studio/optimize/evaluators) 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**](/ai-studio/optimize/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 Guardrail Rule. The form opens as a full page with a back control and three sections: General, Guardrails, and Conditions. Leaving the page with unsaved changes asks for confirmation. Create Guardrail Rule form showing the General fields, a Guardrails section with PII Detection attached and its row controls, and a Conditions section with a Model condition and the generated CEL expression. ### General | Field | Description | | - | - | | **Rule name** | A descriptive name for the guardrail rule. | | **Description** | Optional context for administrators. | | **Enable rule** | Disabled rules remain saved but are not evaluated for requests. | ### Guardrails Select the checks to run and configure where and how often they execute. Click Guardrail to attach one. The menu groups options into **System** and **Workspace**: System guardrails are the pre-built checks covered below; Workspace guardrails are the ones created in the workspace as [**Guardrails**](/ai-gateway/configuration/guardrails). Each attached guardrail is a row with the controls below. | Control | Description | | - | - | | **Execute on** | Cycles through **Input**, **Output**, and **Both**, set independently per guardrail. | | **Blocking** | Shown on guardrails configured to block traffic. Switches the guardrail between blocking and monitor-only: a filled shield blocks requests that fail the check, and in the shield-off state the check still runs and its result is still recorded, but a match no longer blocks the request. | | **Sample Rate** | The share of matching requests the guardrail runs on, adjustable from 1%. | | **Configure** | Opens the guardrail's own settings, on the guardrails that have them. See **PII Detection** below. | | **Actions** | **Go to guardrail** opens the guardrail's own page, on Workspace guardrails. **Remove** detaches the guardrail from the rule, and is the only action on System guardrails. | #### System Guardrails System Guardrails are the pre-built checks **Orq.ai** maintains in the **Guardrail** menu's System group. Attach one and it runs immediately as a pass/fail check that can block a request; it never rewrites content. | System Guardrail | What it checks | Configurable | | - | - | - | | **PII Detection** | Detects personally identifiable information in requests or responses and blocks the request by default, instead of redacting it. | Yes. Once added, a button appears on its row. Click it to set `language`, `regions`, `entities`, `threshold`, and `entity_thresholds`. | | **Secret Detection** | Detects API keys, tokens, credentials, and other secrets in requests or responses and blocks the request by default. | No configurable options. | The detectable entity catalog for **PII Detection** is shared with the [**PII Redaction**](/ai-gateway/features/plugins/pii-redaction#supported-entity-types) 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](/ai-gateway/features/plugins/pii-redaction#entity-type-names-that-changed) when the catalog moved to regions; the old keys are rejected at write time. A rule cannot set a per-guardrail `timeout`. Guardrails injected by a rule always run with the 60 second default. To bound a Guardrail explicitly, attach it inline on the request instead; see [Guardrail timeout](/ai-gateway/configuration/guardrails#timeout). 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. ### Conditions The Conditions section builds the match conditions that determine when the guardrail is triggered. Clicking Condition opens a dropdown with the following condition types: | Condition | Description | | - | - | | **Header** | Match on a request header name and value. | | **Model** | Match on the model being called. | | **Identity** | Match on the identity making the request. | | **Metadata** | Match on metadata attached to the request. | | **Project** | Match on the project scope of the request. | Click **Add group** to nest conditions into a logical group. Conditions added directly to the rule are joined with `and`, and conditions inside a group are joined with `or`; click either operator to toggle it. Each condition can be removed with . The Rule 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. ## Editing and deleting a guardrail rule Click a rule's name in the **Guardrail Rules** list to open it in the same form. An existing rule exposes **Delete Rule** in the form footer, next to **Save Changes**. Deleting asks for confirmation first. The list's row actions menu offers **Edit**, **Enable** or **Disable**, and **Delete**. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.