Skip to content

Guardrails#

Open Policies & Guardrails → Guardrails to create and manage reusable guardrails, such as PII, secrets, toxicity, and other content checks. Guardrails define what to inspect. To apply a guardrail to Chat or API traffic, link it to an enabled policy.

Use this page to:

  • Create reusable guardrails by configuring the Stage, Type, Threshold, and Action.
  • Review guardrail activity, including invocations and the policies that use each guardrail.
  • Edit or delete existing guardrails.
  • Troubleshoot guardrails that are not applied or produce too many or too few detections.

Guardrails tab#

Use the Guardrails tab to create and manage reusable checks. Each row shows the guardrail name, type, execution stage, description, usage statistics, creation date, and actions. Click a name to open the detail page.

Next: Add a guardrailAdd a policyVerify guardrail.

Guardrail detail page#

Click a guardrail name in the Guardrails table to open the guardrail detail page. Use EDIT to modify the guardrail configuration.

Summary cards at the top of the page show how many policies use the guardrail, the total number of guardrail invocations, and the violation rate. The violation rate is displayed as - until evaluation data becomes available.

The Description section provides a human-readable summary of the guardrail purpose and intended behavior.

The Overview section contains general guardrail metadata, including the guardrail name, type, execution stage, and creation date. The Type field identifies the guardrail engine; see Guardrail types for the full list of supported guardrails. The Stage field indicates when the guardrail runs during request processing.

The Configuration section displays guardrail-specific settings. Depending on the guardrail type, these settings can include the threshold value, action, selected PII fields, and custom patterns. Threshold values determine when a violation is triggered; see Guardrail thresholds for additional information. Fields that are not configured display None.

Link the guardrail from a policy to enforce it on traffic. Use Policies using it to see where the guardrail is attached, and Verify guardrail after you enable linked policies.

Edit a guardrail#

1. Open the guardrail for editing using one of the following options:

  • On the Guardrails tab, click Edit in the guardrail row.
  • On the guardrail detail page, click EDIT.

2. Review the pre-populated configuration and update fields described in Add a guardrail.

3. Click SAVE to apply changes.

Changes apply to every linked policy on the next matching request. Review linked policies on the detail page (Policies using it) before saving breaking changes to Stage or Type.

Optional actions:

  • Click CANCEL to return without saving changes.
  • Use DELETE to remove the guardrail. See Delete a guardrail for step-by-step instructions.

Delete a guardrail#

1. Open Policies & Guardrails and select the Guardrails tab.

2. Remove the guardrail using one of the following options:

  • Use the Delete row action on the guardrail in the table, or

  • Click the guardrail name to open the detail page, click EDIT, then click DELETE on the edit form.

3. Confirm the deletion when prompted.

You cannot delete a guardrail that is still required by an active policy configuration—remove it from Linked Guardrails on affected policies first.

Guardrail lifecycle#

Before you begin#

Complete these checks before you create a guardrail:

  1. An organization is selected in the header.
  2. Providers are Active and the required models are enabled if you plan to test the guardrail after linking it to a policy.
  3. You know which Type and Stage to use. See Guardrail types.
  4. You have chosen an appropriate Threshold and Action. See Guardrail thresholds.

Next: Add a guardrail, then Add a policy and Verify guardrail.

Add a guardrail#

Complete the prerequisites first.

1. Open Policies & Guardrails in the Admin UI and select the Guardrails tab.

2. Click + ADD to open the guardrail form.

3. Complete the fields that are always shown on the form:

  • Name — A unique name for this guardrail (for example, pii-redact-input).
  • Description — Optional notes for administrators.
  • Stage — Select when the guardrail runs in the request lifecycle: Input or Output. For typical input or output checks, use the same Stage on the policy that links to this guardrail. See Add a policy.
  • Type — Select the guardrail engine that matches the content you want to inspect. See Guardrail types for the full list of supported guardrails.

After you select a Type, complete any type-specific fields that appear.

Type-specific optional fields:

  • PII fields / Secret types — Limit detection to selected categories. Leave empty to use the default behavior for the selected guardrail type.
  • Custom regexp patterns — Optional custom PII patterns. If you add a pattern with + ADD PATTERN, provide the entity label, score, and at least one regexp. Context keywords are optional.

Type-specific required fields:

  • Threshold — Required for types that use confidence scoring. Most thresholds use 01; Sentiment uses -11. See Guardrail thresholds.
  • Action — What happens when the guardrail triggers, independent of the governance policy object that links the guardrail.
  • Topics — Prohibited topics for ban-topic guardrails.
  • Token limit and Encoding — Required for token-limit guardrails.
  • Languages — Required for code guardrails.
  • Match type — Required for gibberish guardrails.

4. Click SAVE to create the guardrail.

Optional actions:

  • Click CANCEL to return without saving.

Example: PII detection guardrail#

Use this guardrail with the PII redaction policy example or the end-to-end example.

Table 1: Example guardrail — PII on input
Field Example value
Name test-PII
Description Detect and redact credit-card-like data on input
Stage Input
Type PII detection and redaction
Threshold 0.7
Action Redact
PII fields CREDIT_CARD
Custom regexp patterns Leave empty for first test

Keep guardrail Stage aligned with the linked policy Stage.

Example: Secrets guardrail#

Use this pattern to block prompts that contain private-key-like secrets before they reach a provider. The Secrets guardrail shows Action and Secret types after you select Type = Secrets.

Table 2: Example guardrail — secrets
Field Example value
Name secrets-input
Description Block private key leaks in user prompts
Stage Input
Type Secrets
Action Block
Secret types PRIVATE_KEY

To make this guardrail run, add a policy and link the guardrail from that policy. Configure the policy settings to match the traffic you want to scan.

Table 3: Example policy settings for the secrets guardrail
Policy field Example value
Name chat-secrets-check
Description Block private keys in chat prompts
Enabled On
Conditions Rule Builder: Request type = chat_completion
Stage Input
Sampling rate 100% during testing
Timeout 1500 ms
Request type Chat Completion
Pass on timeout Off for strict blocking tests
Linked guardrails secrets-input

Send a matching Chat or API request that contains private-key-like content. If the policy conditions match and the guardrail detects a PRIVATE_KEY, the request is blocked.

After you save#

Creating a guardrail does not apply it to traffic by itself. To use the guardrail, you must link it to an enabled policy:

  1. Confirm that the guardrail appears on the Guardrails tab.
  2. Link the guardrail to a policy:
  3. Turn the policy Enabled on.
  4. Send traffic that matches the policy conditions.
  5. Verify guardrail invocations on the guardrail detail page and through the linked policy's Usage Statistics.

Until the guardrail is linked to a policy, Policies using it on the guardrail detail page remains 0, and the guardrail is not applied to traffic.

When a guardrail runs#

A saved guardrail does not enforce traffic by itself. It runs only when all of the following are true:

  1. The guardrail is linked to an Enabled policy.
  2. The policy Conditions and Request type match the request.
  3. The request is selected according to the policy Sampling rate.
  4. The linked guardrail is invoked according to its configured Stage.

See Policy vs guardrail for the complete setup workflow.

Verify guardrail#

Verify that the guardrail is configured correctly and runs when applied through a policy:

1. Navigate to Policies & GuardrailsGuardrails, then click the guardrail. On the guardrail detail page, verify:

  • Type — matches the check you configured (for example, PII, secrets, or toxicity detection).
  • Stage — matches where the guardrail should inspect content (Input or Output).
  • Policies using it — shows at least one policy if the guardrail is expected to run on traffic. Verify that the expected policy is linked and Enabled.

2. Send requests that match the linked policy Conditions and Request type. Run several test requests through Chat or the API. If the policy Sampling rate is below 100%, you may need to send more requests for the guardrail to be invoked.

3. Return to the guardrail detail page and verify that Total invocations increases. If the test traffic triggers the guardrail, verify the corresponding change in Violation rate.

4. Go to Policies & GuardrailsPolicies, open the linked policy and review the Usage Statistics tab to confirm policy and guardrail activity.

For a complete PII redaction walkthrough, see the end-to-end example.

Troubleshooting#

Guardrail saved but never runs

  • Confirm it is linked from an Enabled policy.
  • Confirm policy Conditions and Request type match your traffic.
  • Set policy Sampling rate to 100% during testing.

Policies using it stays at 0

  • Add or edit a policy, fill in or update the required fields, and select this guardrail under Linked Guardrails.
  • Save the policy after selecting the guardrail.

Invocations stay at 0

Too many or too few detections

  • Adjust Threshold; see Guardrail thresholds.
  • Narrow policy Conditions so the guardrail runs only on intended traffic.

For policy-side issues (sampling, timeout, bypass), see Policies troubleshooting.