Overview#

Open Config → Policies & Guardrails to configure AI safety, compliance, and content controls for Chat and API traffic through the AI Gateway.

The page contains two tabs:

• Policies — Define when and for which traffic guardrails are applied. See Policies.
• Guardrails — Create reusable content checks and actions. See Guardrails.

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

Overview#

Policy vs guardrail#

A guardrail defines what content to check and what action to take when a match is detected. Guardrails can detect issues such as PII, Secrets, Toxicity, and Gibberish, or use an external Webhook for a custom check.

For example, a PII guardrail can inspect input content and Redact detected personal information. If the action is Block, the request is blocked when the guardrail detects matching content.

A policy determines when linked guardrails run. It defines the matching traffic, request type, sampling rate, stage, and guardrails to apply.

For example, a policy can apply a PII guardrail to Chat requests at the Input stage.

The relationship is:

Request → Policy applies → Guardrail runs → Action is applied

The mental model is:

• Guardrail — What should be checked?
• Policy — When and for which traffic should the check run?
• Action — What happens when the guardrail detects a match?

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.

When to use 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 evaluated using Sampling rate.
• Monitor policy and guardrail activity, including invocations, violations, and bypasses.

Policies and guardrails are not required when requests should pass through the AI Gateway without content inspection. In that case, traffic is processed according to Credentials & Roles, provider limits, and routing rules only.

How policy evaluation works#

For each Chat or API request, the AI Gateway evaluates policies in this order:

1. Enabled — Disabled policies are skipped. Disabled policies retain their configuration but are never applied.
2. Conditions — The request must match the configured conditions. CEL Expression Preview shows the generated expression.
3. Stage — The policy Stage must include the current request stage (Input, Output, or Both).
4. Request type — The request type must be included in the evaluation scope.
5. Sampling rate — The request must be selected for evaluation. When Sampling rate is less than 100%, some matching requests intentionally bypass the policy.
6. Guardrail Stage — Linked guardrails are selected when their Stage matches the current request stage.
7. Guardrails — Selected guardrails inspect the content and apply their configured actions.
8. Timeout behavior — If guardrail evaluation exceeds Timeout, each matching policy applies its own Pass on timeout setting. A policy with Pass on timeout enabled allows the request to continue when that policy times out. A policy with Pass on timeout disabled blocks or fails the request on timeout. If several policies match the same request, the request is blocked when at least one of those policies requires a block.

A guardrail runs only when it is linked to an Enabled policy that matches the request. See When a guardrail runs.

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.

Policy and guardrail workflow#

To apply a guardrail to traffic:

1. Add a guardrail — Configure the check, stage, threshold, and action.
2. Add a policy — Define the matching traffic and link the guardrail.
3. Enable the policy — Turn on Enabled.
4. Verify — Send matching Chat or API traffic and review the results in Usage Statistics. See also Verify guardrail.

See also#

• Guardrails — Create, manage, and troubleshoot reusable guardrails.
• Policies — Create, configure, and troubleshoot enforcement policies.
• Policy checklist — Review the configuration before relying on policy enforcement in production.
• Policy and Guardrail Limits — Learn about sampling behavior, timeout handling, and observability limitations.
• Use Cases — Apply policies and guardrails — Explore common AI governance scenarios.
• End-to-end examples — PII redaction — Walk through a complete PII redaction example.