How Guardrails Work
A guardrail is a set of safety and policy filters that inspect and control how agents and gateways use models. A guardrail can block prompt injection, deny off-topic content, redact or block personally identifiable information (PII), and check responses for factual grounding. You attach a guardrail to an LLM provider, and Agentic Data Plane applies it to every request and response that flows through that provider.
Agentic Data Plane guardrails run on AWS Bedrock Guardrails. Each guardrail syncs its policy configuration to the Bedrock control plane, so it needs an AWS region and Bedrock credentials. A guardrail can attach to any LLM provider type, not only Bedrock. On a Bedrock provider, Bedrock enforces the guardrail as part of the model call. On other provider types, such as OpenAI, Anthropic, and Google AI, the AI Gateway evaluates each request and response against the guardrail itself. The Agentic Data Plane UI shows the guardrail setting on Bedrock providers only. To attach a guardrail to another provider type, use the API or the --guardrail flag on rpk ai llm-provider create and rpk ai llm-provider update.
After reading this page, you will be able to:
-
Describe what a guardrail does and how you attach one to an LLM provider
-
Identify the available policy types and the situations each fits
-
Recognize how a blocked request surfaces and which page to read next
Policy types
A guardrail bundles a set of policies. Each is optional, but a guardrail must enforce at least one. Turn on the ones you need.
| Policy | What it does |
|---|---|
Content filters |
Classify prompts and responses against harmful-content categories: hate, insults, sexual, violence, misconduct, and prompt attacks. Prompt-attack detection applies to input only. |
Word filters |
Block or detect exact words and phrases, using your own lists and platform-managed lists such as profanity. |
Denied topics |
Block content by meaning rather than exact words, so it catches paraphrases and misspellings. |
Sensitive information |
Detect PII using built-in entity types and your own regex patterns, then detect, block, or anonymize it. |
Contextual grounding |
For RAG-style applications, check model output for factual grounding against a source and relevance to the query. Output only. |
Automated reasoning |
Mathematically verify model output against formal Bedrock Automated Reasoning policies. Detect only: it never blocks, and findings appear in the trace. |
For each policy’s full configuration, see Guardrail policy reference.
Where a guardrail runs
A guardrail evaluates both sides of an LLM call:
-
Input: Agentic Data Plane evaluates the prompt before forwarding it upstream. Use input evaluation to stop sensitive or malicious content from reaching the model.
-
Output: Agentic Data Plane evaluates the model’s response before returning it to the caller. Use output evaluation to control what the model generates.
Some policies are direction-specific. Content-filter prompt-attack detection runs on input only, contextual grounding runs on output only, and automated reasoning runs on output and only reports findings.
How the guardrail is enforced depends on the provider type. On a Bedrock provider, Bedrock evaluates both directions as part of the model call. On other provider types, the AI Gateway evaluates the prompt before it forwards the request and evaluates the response before it delivers it.
For streaming responses from a provider other than Bedrock, the AI Gateway evaluates output as the stream arrives, in batches of text. It holds each batch until the guardrail allows it, then releases the batch to the caller. If the guardrail blocks a batch, the caller receives your configured blocked output message in place of that batch and the stream ends. Text from earlier batches has already been delivered and is not recalled. On a Bedrock provider, Bedrock evaluates streamed output as part of the model call. In both cases, output evaluation acts only through policies that apply to output, so a guardrail with input-only policies does not evaluate responses.
Where you attach a guardrail
You attach a guardrail by setting an LLM provider’s guardrail field. In the Agentic Data Plane UI, the setting appears in a Bedrock provider’s settings. For any provider type, set the field through the API or with rpk ai llm-provider update <provider-name> --guardrail <guardrail-name>. Each provider references at most one guardrail, and a single guardrail can be reused across many providers. The guardrail’s detail page lists the providers that use it. You create and configure the guardrail first, then attach it from the provider. See Create a guardrail.
Agentic Data Plane enforces this reference in both directions. A provider can only point at a guardrail that exists, and you cannot delete a guardrail while a provider still references it. To remove a guardrail that is in use, detach it from each provider first.
What happens when a guardrail blocks
When a policy blocks an input, Agentic Data Plane stops the request and returns your configured blocked input message to the caller. When a policy blocks an output, Agentic Data Plane returns your configured blocked output message instead of the model’s response.
The sensitive-information policy can also anonymize matched PII in place rather than block, replacing each match with its entity type, such as {EMAIL}. The two directions differ: on output, Agentic Data Plane delivers the redacted response to the caller. On input, Agentic Data Plane does not forward the redacted prompt to the model. Agentic Data Plane short-circuits the request like a block and returns your configured blocked input message.
Agentic Data Plane records guardrail activity as attributes on the request’s OpenTelemetry trace, which you read in transcripts. This release does not include a separate violations dashboard. See Review blocked requests for how a blocked request surfaces.
