Policies & Guardrails#

Open Policies & Guardrails to configure AI safety, compliance, and content controls for Chat and API traffic through the AI Gateway. Create reusable guardrails (for example, PII detection) and assign them to policies that determine when and how those checks are applied.

Use this page to:

Understand how policies and guardrails work together.
Decide whether gateway-side content controls are appropriate for your Chat and API traffic.
Configure reusable guardrails and policies in the recommended order.

The page contains two tabs:

Policies — Define the evaluation scope, matching conditions, and linked guardrails. See Policies.
Guardrails — Create reusable guardrail definitions. See Guardrails.

For architecture, limitations, and recommended usage patterns, see Architecture Overview — Policies and guardrails.

Next: Policy vs guardrail → How policy evaluation works → Add a guardrail → Add a policy.

For a complete workflow, see the End-to-end example. After deployment, monitor policy activity on Dashboards and on the policy Usage Statistics tab.

Policies & Guardrails overview#

Policy vs guardrail#

The easiest way to understand policies and guardrails is to separate what to check from when to check it.

A guardrail is a reusable content check. For example, if a user sends:

My name is John and my SSN is 123-45-6789. Please summarize this document.

you might want to detect personal information before the request reaches the model. A guardrail performs this check. Guardrails can detect issues such as PII, Secrets, Toxicity, and Gibberish, or use an external Webhook to perform a custom check.

A guardrail also defines the Action to take when content is detected, such as Redact or Block.

For example, create the following guardrail:

Setting	Value
Name	`PII detection`
Type	PII
Stage	Input
Action	Redact

At this point, the guardrail exists, but it is not applied to traffic.

A policy connects traffic to one or more guardrails. It determines which requests are processed by the linked guardrails using settings such as Conditions, Request type, Sampling rate, and Stage.

For example, create and enable a policy that applies the PII guardrail to Chat traffic:

Setting	Value
Name	`PII protection for Chat`
Enabled	On
Request type	Chat Completion Stream
Sampling rate	`100%`
Stage	Input
Linked Guardrails	`PII detection`

Now, when a matching user sends:

My name is John and my SSN is 123-45-6789. Please summarize this document.

the AI Gateway processes the request as follows:

The request matches the enabled PII protection for Chat policy.
The policy invokes the linked PII detection guardrail.
The guardrail detects the SSN as PII.
The configured Redact action is applied.
The request continues with the detected sensitive content redacted.

If the guardrail uses Block instead of Redact, the request is blocked when the guardrail detects matching content.

The relationship can be summarized as:

Request → Policy matches → Linked guardrail runs → Content is checked → Action is applied

The mental model is:

Guardrail — What should be checked?
Policy — When and for which traffic should the check run?
Action — What should happen when the guardrail detects something?

A guardrail can exist without a policy, but it is not applied to Chat or API traffic until it is linked to an Enabled policy. One guardrail can be reused by several policies, and one policy can link several guardrails.

Stage is configured separately for policies and guardrails. The policy Stage controls when the policy evaluates traffic, while the guardrail Stage defines which direction of content the guardrail inspects: Input, Output, or Both.

To apply guardrails to traffic, complete the policy and guardrail workflow: create a guardrail, link it to an enabled policy, send matching traffic, and verify the results.

When you need policies and guardrails#

Create a policy with one or more linked guardrails when you need to:

Detect sensitive or unwanted content (for example, PII, secrets, or toxicity) and Redact or Block it when detected.
Apply the same guardrail to different traffic by creating policies with different conditions.
Control how much matching traffic is checked using the policy Sampling rate.
Monitor policy and guardrail activity, including invocations, violations, and bypasses.

You do not need policies or guardrails when requests should pass through the AI Gateway without content inspection. In that case, traffic is processed according to AI Access, provider limits, and routing rules only.

How policy evaluation works#

Policies and guardrails are configured on the Policies & Guardrails page. When a policy is Enabled and linked to one or more guardrails, the AI Gateway checks each matching Chat and API request according to the policy configuration. Field meanings correspond to the Add a policy form.

The policy workflow is:

Request reaches the AI Gateway
    ↓
Skip if the policy is Disabled
    ↓
Evaluate Conditions
    ↓
Check Request type
    ↓
Apply Sampling rate
    (requests outside the sample bypass the policy)
    ↓
Run the policy at the configured Stage
    (Input, Output, or Both)
    ↓
Run linked guardrails
    ↓
Apply each guardrail action
    (for example, Redact or Block)
    ↓
If a guardrail times out,
Pass on timeout determines whether the request continues
or fails

For consistent behavior, review both policy and guardrail Stage values when linking guardrails to policies. For simple prompt-inspection setups, use Input on both the policy and the guardrail so the check runs before content is sent to the provider.

Evaluation order#

The AI Gateway applies a policy only when all of the following conditions are met:

Enabled — The policy is Enabled. Disabled policies are stored but never applied.
Conditions — The request matches the configured rules. CEL Expression Preview shows the generated expression.
Stage — The policy runs at the configured Input, Output, or Both stage.
Sampling rate — The request is selected for evaluation. When Sampling rate is less than 100%, some matching requests intentionally bypass the policy.
Timeout — If a guardrail exceeds Timeout, Pass on timeout determines whether the request continues or fails.
Request type — The request type is included in Evaluation scope → Request type (for example, Chat Completion).
Guardrails — One or more guardrails are linked to the policy. Each linked guardrail performs its configured checks and applies the configured action (for example, Redact or Block).

A guardrail is applied only when it is linked to an Enabled policy whose Conditions, Request type, and Stage match the request. See When a guardrail runs.

Policy and guardrail workflow#

Use this workflow to take a guardrail from definition to live enforcement.

Add a guardrail — On the Policies & Guardrails → Guardrails tab, create a reusable guardrail by selecting its type and configuring the required settings, such as Stage, Threshold, and Action. See Add a guardrail.
Add a policy — On the Policies & Guardrails → Policies tab, configure the policy Conditions, Evaluation scope, and Linked Guardrails. Turn Enabled on to activate the policy. See Add a policy.
Verify — Generate requests that match the policy conditions. You can:
- Send one or more prompts in Chat that match the configured conditions.
- Send API requests that match the configured Request type, Conditions, and Stage.
Verify the policy activity on the Usage Statistics tab. See Verify policy and Verify guardrail.

Configure policies and guardrails#

Use the following procedures to configure, verify, and troubleshoot AI Gateway governance:

Add a guardrail — Create a reusable guardrail definition.
Verify guardrail — Verify that the guardrail is applied through a linked policy.
Add a policy — Configure the policy conditions, evaluation scope, and linked guardrails.
Verify policy — Verify that matching requests are evaluated in policy usage statistics.
Policy checklist — Review the configuration before relying on policy enforcement in production.