Create and Manage GuardrailsEnterprise
Create a guardrail, choose its filters, and target it at agents, AI Gateway traffic, MCP Gateway traffic, Claude, Claude Inference Hooks, or the browser extension.
A guardrail is a set of filters (data leakage prevention, responsible AI, and security) applied to one or more targets. The target decides which traffic the guardrail inspects, and the scope decides which agents, gateways, or users it covers.
Before you start: you need permission to manage guardrails, for example the Platform Admin role.
- Go to Secure and select Runtime Security → Guardrails in the left navigation. Your existing guardrails (if any) are listed here.
- Click Create Guardrail.
- On Guardrail Details, enter a Name and Description.
- Under Filters, open DLP, Responsible AI, and Security and turn on the filters you need.
- For each filter that offers actions, choose Audit, Block, or Redact & Replace. See Filters for what each filter detects and which actions it supports.
- Click Save Draft to keep the guardrail without enforcing it, or Apply Guardrail to activate it.
The guardrail appears in the Guardrails list. Once it is applied, its detections appear under Audit → Security Events in the DLP Violations and Security Violations feeds.
Targets
Each target on the Target and Scope step is a separate surface. A guardrail inspects only the targets you select, so a guardrail targeted at agents does not inspect browser prompts, and a browser guardrail does not inspect gateway traffic. Select every surface you want the guardrail to cover.
| Target | What it inspects | Direction options |
|---|---|---|
| Apply to Model in Agent | Messages sent to and returned from models inside your agents | Both Input and Output, Input only, Output only, None |
| Apply to AI Gateway traffic | Requests and responses that pass through your AI Gateway configurations, such as coding assistants and applications that call the gateway | Both Input and Output, Input only, Output only, None |
| Apply to MCP Gateway traffic | Tool responses returned through your MCP Gateway configurations | Tool Response, None |
| Apply to Claude | Claude activity reported to Airia through the Claude connection. For Claude Code and Cowork telemetry, turn on prompt logging in your OpenTelemetry collector configuration so prompts can be inspected. | Both Input and Output, Input only, Output only, None |
| Apply to Inference Hooks | Prompts that Claude sends to Airia for an allow or deny decision before the model runs, through Claude Inference Hooks. Inference Hooks returns only allow or deny, so on this target a filter set to Redact & Replace, and HTML Sanitization or URL Sanitization, block the prompt instead of changing it. | Input only, None |
| Apply to Browser Extension | Prompts users send to third-party AI apps, such as ChatGPT, Gemini, and Claude, through the Airia browser extension | Select the checkbox to turn it on |
Input inspects what is sent to the model (the prompt). Output inspects what the model returns.
For Apply to Claude, the guardrail evaluates Claude activity after it is reported. To inspect Claude requests before the model answers, either route Claude traffic through an AI Gateway and select Apply to AI Gateway traffic, or connect Claude Inference Hooks and select Apply to Inference Hooks. See Securing Claude with Airia.
The targets on this step reflect the surfaces enabled for your organization.
Additional inspection options
These checkboxes appear below the targets:
- Apply to retrieved data chunks: inspects content retrieved from data sources.
- Apply to tool responses triggered by a Model: inspects the results tools return to the model. Shown when Apply to Model in Agent or Apply to AI Gateway traffic includes Input.
- Apply to tool calls made by a Model: inspects the arguments the model sends when it calls a tool. Shown when Apply to Model in Agent or Apply to AI Gateway traffic includes Output.
Scope
Scope narrows each target to specific agents, gateways, or people.
| Target | Scope options |
|---|---|
| Apply to Model in Agent | All Agents, Specific Agents (choose a project, then all of its agents or selected agents), or Except Specific Agents (every agent except the ones you select) |
| Apply to AI Gateway traffic | All Gateway configurations or Specific Gateway configurations |
| Apply to MCP Gateway traffic | All MCP Gateway configurations or Specific MCP Gateway configurations |
| Apply to Browser Extension | Under Browser Extension User Scope: All Users, Specific Users, or Except Specific Users. Select groups on the Groups tab and individuals on the Users tab. |
| Apply to Claude | Applies to your organization's Claude activity |
| Apply to Inference Hooks | Applies to every prompt Claude sends to your organization's Inference Hooks endpoint |
Roll out with Audit first
Start a new guardrail with its filters set to Audit. Audit records every detection in the violation feeds without changing what users see, so you can review what the guardrail catches before it affects anyone.
- Create the guardrail with Audit actions and scope it to one project, one gateway configuration, or a pilot group of users.
- Review the detections in Audit → Security Events (DLP Violations and Security Violations).
- Tune the filters: remove entity types you don't need, adjust sensitivity, and add Exceptions for values that are expected in your traffic.
- Switch the filters that are catching the right content to Block or Redact & Replace.
- Widen the scope to more agents, gateways, or users.
What users see when a guardrail acts
The action you choose for a filter decides what happens when it detects something.
| Action | What happens |
|---|---|
| Audit | The detection is recorded in the violation feeds. The request continues unchanged. |
| Redact & Replace | The sensitive value is replaced with a placeholder before it reaches the model. |
| Block | The request or response is stopped, and the user receives the Message for blocked requests/responses you set on the filter. |
Inside an agent
- Input checks run on the prompt before the model is called. When an input filter blocks, the model is not called.
- Output checks run on the model's complete response. While an output check is active on a model step, the response is delivered after it has been inspected rather than streamed as it is generated.
- When a filter blocks, the agent stops at that model step. The steps after it do not run, and the block message becomes the agent's response to the user. Steps that were already running in a parallel branch finish, and the user still receives the block message.
- When a filter redacts, the model works with the placeholder. The final model step before the agent's output restores values that were redacted from the input, so the user sees the original value in the response while the model works only with the placeholder.
Set a clear Message for blocked requests/responses on each filter that uses Block, so users know why their request stopped and what to do next.