> ## Documentation Index > Fetch the complete documentation index at: /docs/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** (automated checks that inspect a request or response) run against requests passing through the [**AI Gateway**](/docs/ai-gateway/get-started/introduction.md). 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**](/docs/ai-gateway/mcp-portal/mcp-gateways.md); attach [Guardrails](/docs/ai-gateway/mcp-portal/mcp-gateways.md#guardrails) and [plugins](/docs/ai-gateway/mcp-portal/mcp-gateways.md#plugins) to the MCP Gateway to check tool traffic. ## Use cases Guardrail rules are most useful when the same safety or compliance check needs to apply consistently across many requests. > [accordion] Add jailbreak protection to all customer-facing banking traffic > > Runs a jailbreak detection **Evaluator** on all customer-facing requests at the gateway level, adding an extra security layer across **AI Gateway** traffic. > [accordion] Enforce GDPR PII checks across the entire workspace > > Enforces GDPR compliance by running PII detection on all matching requests workspace-wide from a single rule. > [accordion] Validate customer detail access for the sales team > > Validates customer detail access for the sales team by calling an external **Evaluator** on every matching request before it reaches the model. > [accordion] Monitor tone of voice across all company traffic > > Applies a tone of voice **Evaluator** at the gateway level so every response is checked against the company's tone guidelines. > [accordion] Apply EU AI Act compliance checks to EU-routed requests > > 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. > [accordion] Run safety and quality checks on targeted traffic using metadata > > 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 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. ### 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**](/docs/ai-gateway/configuration/guardrails.md). 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 **Toqan Router** 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**](/docs/ai-gateway/features/plugins/pii-redaction.md#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](/docs/ai-gateway/features/plugins/pii-redaction.md#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 run with the timeout set on the evaluator, or the 60 second default if it has none; see [Guardrail timeout](/docs/ai-gateway/configuration/guardrails.md#timeout). > [!WARNING] > > 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. The **Rule Builder** builds the CEL expression shown read-only in the **CEL Expression Preview**; leaving the section empty applies the rule to every request. Select **Add rule** to choose a condition type: | 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. | Each **Add rule** creates a condition group titled **Rule 1 ยท N conditions**. Inside a group, select **Condition** to add another condition, and to remove one. Drag a condition by its handle to reorder it. Conditions in a group are joined with `and` by default; select the **AND** pill between two conditions to switch the group to `or`. **Delete** removes the whole group. Rule groups are joined with `or` by default; select the pill between two groups to switch them to `and`. The generated expression triggers the guardrail only when it 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.