Policies#

Open Policies & Guardrails → Policies to create and manage policies that determine when and for which AI Gateway traffic linked guardrails run. Configure Conditions, Evaluation scope, Sampling rate, Timeout, and Linked Guardrails for each policy.

At least one guardrail must exist before you can create a policy.

Use this page to:

• Create and enable policies that apply one or more guardrails to traffic.
• Define which traffic a policy applies to using Conditions and Evaluation scope.
• Control how matching requests are processed using Sampling rate and Timeout settings.
• Review violation, bypass, and match rates on the policy detail page.
• Troubleshoot policies that do not match the expected traffic or produce unexpected results.

Policies tab#

Go to Policies & Guardrails. The Policies tab opens by default.

Use this tab to create, review, and manage policies that determine when linked guardrails run on AI Gateway traffic. The table provides an overview of configured policies and their key settings, including evaluation stage, request type, sampling, timeout behavior, and linked guardrails.

Policy detail page#

Click a policy name in the Policies table to open the policy detail page. Use EDIT to modify the policy configuration.

Summary cards at the top of the page provide a 24-hour activity snapshot, including the number of requests evaluated by the policy, violation rate, bypass rate, match rate, average evaluation latency, and the number of linked guardrails. Metrics may display 0 or - when little or no traffic has been evaluated during the selected period.

Policy overview#

The OVERVIEW tab displays the policy definition and evaluation settings. General information includes the policy description, policy identifier, organization identifier, policy name, current state, and creation date.

The Summary section contains general policy metadata, including the policy identifier, organization identifier, policy name, current state, and creation date. Copy controls are available for the identifiers.

The Evaluation Scope shows when and how the policy is applied, including the evaluation stage, sampling rate, timeout, request type, timeout behavior, and the number of linked guardrails.

The Conditions section defines when the policy applies. Conditions may be displayed as expressions or as rules configured through the policy editor and determine which requests are evaluated by the policy.

Linked Guardrails#

The LINKED GUARDRAILS tab displays all guardrails attached to the policy. For each guardrail, the table shows its name, type, execution stage, and configuration details.

The Name column links to the guardrail definition. The Type column identifies the guardrail engine; see Guardrail types for the full list. The Stage column indicates when the guardrail runs during request processing. The Configuration column summarizes guardrail-specific settings such as threshold values, actions, PII fields, and custom patterns.

Usage Statistics#

The Usage Statistics tab provides visibility into policy activity, evaluation latency, violation trends, and guardrail results for requests evaluated by the policy.

The Aggregated Metrics section summarizes policy performance and coverage, including the total number of evaluations, requests evaluated during the last 24 hours, match rates, violation rates, latency measurements, and bypass rates. Metrics are displayed for both the last 24 hours and the overall policy lifetime where applicable.

Additional panels provide detailed breakdowns of policy activity:

• Violations by Day — Time-series chart showing the number of violations over time.
• Top Scopes — Distribution of evaluated requests across common dimensions such as Request type, Provider, Model, User, or other available scope values.
• Violations by Type — Breakdown of evaluation outcomes grouped by violation category, such as Score, Timeout, or Skipped.
• Guardrail Invocations — Statistics for linked guardrails, including evaluation and violation counts. Guardrail names link to the corresponding guardrail definitions.

Use the Usage Statistics tab to verify that policy conditions match the intended requests, monitor evaluation latency, and analyze violation patterns and guardrail effectiveness.

Edit a policy#

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

• On the Policies tab, click Edit in the policy row.
• On the policy detail page, click EDIT.

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

• Name, Description, Enabled
• Conditions and CEL expression preview
• Evaluation scope (Stage, Sampling rate, Timeout, Request type, Pass on timeout)
• Linked guardrails

3. Click SAVE to apply changes.

Optional actions:

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

Delete a policy#

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

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

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

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

3. Confirm the deletion when prompted.

Linked guardrails remain on the Guardrails tab; only the policy and its enforcement linkage are removed.

Policy lifecycle#

Before you begin#

Complete these steps before you create a policy:

1. An organization is selected in the header.
2. At least one guardrail exists on the Guardrails tab. See Add a guardrail.
3. Providers are Active with models enabled if you plan to test through Chat or API.
4. You know which Request type your traffic uses (for example, Chat Completion Stream for Chat requests).
5. For first tests, plan to use Sampling rate 100% so every matching request is evaluated.

Next: Add a policy, then verify policy and complete the policy checklist.

Add a policy#

Complete the prerequisites first. At least one linked guardrail is required.

1. Open Policies & Guardrails in the Admin UI. The Policies tab opens by default.

2. Click + ADD to open the Add Policy form.

3. Set Name and optional Description.

4. Turn Enabled on to apply the policy to matching traffic; turn off to keep the definition without enforcement.

5. Under Conditions, define which AI Gateway requests the policy applies to. Add conditions to filter requests by request type, provider, model, and team attributes. Conditions use the same pattern as routing rule conditions. See Common policy conditions to get examples.

• Understand the logic

  • AND — every rule in the group must match.
  • OR — at least one rule in the group must match.
  • Use + Add rule group for nested logic.

• Build the condition

  1. Choose AND or OR for the current group.
  2. (Optional) Click + Add rule group to create a nested condition group.
  3. Click + Add rule, then select the field, operator, and value.
  4. Repeat until the policy matches only the traffic you intend.

• Verify the result

  • Check CEL Expression Preview at the bottom of Conditions. It shows the Common Expression Language (CEL) expression generated from your rules.

6. Under Evaluation scope, configure:

• Stage — Input, Output, or Both. Choose the lifecycle point where the policy evaluates matching traffic.
• Sampling rate — Percentage of matching requests to evaluate. Use 100% while testing; lower in production to reduce latency if appropriate.
• Timeout — Maximum evaluation time in milliseconds.
• Request type — Gateway request family this policy applies to.
• Pass on timeout — Enabled: request proceeds if evaluation times out. Disabled: request may fail or block on timeout.

7. Under Linked Guardrails, select one or more guardrails. Use Show configuration on each card to confirm type, stage, threshold, and action before linking.

8. Click SAVE to create the policy.

Optional actions:

• Click CANCEL to return without saving.

Common policy conditions#

Use these examples to build Conditions in the policy form. You do not need to write CEL manually; use CEL Expression Preview only to verify the generated condition.

Example: Match all Chat Completion traffic

1. In Conditions, confirm AND is selected for the top-level group.
2. Click + Add rule.

3. Fill in the fields:

   • Field = Request type
   • Operator = =
   • Value = Chat Completion

4. Check CEL Expression Preview. It should look like:

request_type == "chat_completion"

Example: Match a specific provider

1. In Conditions, confirm AND is selected for the top-level group.
2. Click + Add rule.

3. Fill in the fields:

   • Field = Provider
   • Operator = =
   • Value = openai-production

4. Check CEL Expression Preview. It should look like:

provider == "openai-production"

Example: Match Chat Completion traffic for one model

1. In Conditions, confirm AND is selected for the top-level group.
2. Click + Add rule.

3. Fill in the first rule:

   • Field = Request type
   • Operator = =
   • Value = Chat Completion

4. Click + Add rule again in the same AND group.

5. Fill in the second rule:

   • Field = Model
   • Operator = =
   • Value = gpt-4o

6. Check CEL Expression Preview. It should look like:

request_type == "chat_completion" && model == "gpt-4o"

Example: PII redaction policy#

Use this pattern to redact credit-card-like data in Chat Completion prompts. Create the matching guardrail first—see Example: PII detection guardrail or the end-to-end example.

After you save#

After you save, the policy appears on the Policies tab. If Enabled is on, new matching requests are eligible for evaluation according to the policy Conditions, Request type, Stage, Sampling rate, and linked guardrails.

Policy metrics remain empty until matching traffic flows through the AI Gateway. Continue with Verify policy to send test traffic and confirm results in Usage Statistics.

For limitations (sampling skips, timeout behavior, observability lag), see Limitations — Policies & Guardrails.

Verify policy#

Verify that the policy matches the intended traffic and runs the linked guardrails:

1. Navigate to Policies & Guardrails → Policies. Verify that the policy is Enabled and shows the expected number of linked guardrails.

2. Click the policy name. Verify that Conditions, Evaluation scope, and Linked Guardrails contain the expected configuration.

3. Send several requests through Chat or the API that match the policy configuration. For example, when testing a PII guardrail, include sample sensitive data that should trigger detection.

4. Open the Usage Statistics tab and verify that Requests evaluated, Match rate, and Guardrail invocations reflect the test traffic.

5. For a Redact action, confirm that detected sensitive content is redacted in the response or returned content. For a Block action, confirm that the matching request is blocked.

Policy checklist#

Before using a policy in production, review the settings that affect coverage, behavior, and performance:

1. Linked Guardrails — Confirm that the policy includes all guardrails required for the traffic you want to inspect.
2. Stage — Confirm that the policy and guardrail stages provide the intended inspection behavior.
3. Conditions and Request type — Make sure the policy covers the intended traffic without matching unrelated requests.
4. Sampling rate — Use 100% when all matching traffic must be evaluated. Use a lower value only when intentional sampling is acceptable.
5. Timeout behavior — Configure Timeout and Pass on timeout according to whether requests should proceed when guardrail evaluation times out.
6. Monitoring — Review Usage Statistics and Dashboards after rollout, and be aware of documented limitations.

Troubleshooting#

Policy saved but nothing evaluates

• Confirm the policy is Enabled.
• Confirm at least one guardrail is linked on the LINKED GUARDRAILS tab.
• Confirm Conditions and Request type match real traffic—compare CEL expression preview with attributes in Traces.
• Set Sampling rate to 100% during testing.
• Confirm policy Stage matches linked guardrail Stage.

Metrics stay at 0 or -

• Allow time after saving; metrics update after matching traffic flows.
• Confirm users send traffic through the AI Gateway (Chat or API), not direct vendor calls.
• See Observability lag.

Violations or redaction not as expected

• Review guardrail Threshold and Action on the guardrail detail page.
• Confirm the correct guardrail is linked and its Type matches the risk (PII, Secrets, and so on).
• Check the response or returned content for the expected Redact or Block behavior, and review Usage Statistics for guardrail activity.

Requests blocked or slow

• Increase Timeout or enable Pass on timeout for latency-sensitive Chat.
• Reduce the number of linked guardrails or lower Sampling rate in production after testing.

For additional edge cases, see Limitations — Policies & Guardrails and Use cases — Policies & Guardrails.