Amazon Bedrock Guardrails: what each filter does and how to set it up.
Bedrock Guardrails is a policy layer that checks prompts and model answers against rules you set: content filters, denied topics, word filters, sensitive information (PII) filters, contextual grounding checks and Automated Reasoning checks. One guardrail works with any Bedrock model, and the ApplyGuardrail API lets you use it with models outside Bedrock.
- A guardrail is a named, versioned set of rules. Bedrock checks the user prompt and the model answer against it, then blocks or masks anything that breaks a rule. The guardrail is separate from the model, so you can switch models and keep the same rules.
- There are six safeguards: content filters (hate, insults, sexual, violence, misconduct and prompt attacks), denied topics, word filters, sensitive information filters (block or mask PII, plus your own regex), contextual grounding checks for RAG answers, and Automated Reasoning checks against logical rules.
- On 10 October 2026 the AWS pricing page listed content filters and denied topics at $0.15 per 1,000 text units, sensitive information filters and grounding checks at $0.10, and word filters and regex filters as free. If a partner builds a guarded Bedrock workload for you, the partner can file POC funding for it when the work qualifies and AWS approves.
IWhat Amazon Bedrock Guardrails are
A foundation model will answer questions you do not want answered, repeat sensitive data and sometimes make things up. A guardrail is the set of rules that stops that before it reaches a user.
A guardrail is a resource you create once in Bedrock. You decide what to block, which topics are out of scope, which words to filter, which personal data to mask, and how closely answers must match your source documents. Bedrock then checks both the prompt and the response. A violation is blocked and replaced with a message you write, or, for personal data, masked.
The guardrail does not belong to any one model. The same guardrail applies the same rules to Claude, Amazon Nova, Llama or any other Bedrock model. That makes it one place where your AI policy lives, which is what a security reviewer wants to see.
You can also attach a guardrail to a Bedrock Agent and use it with Knowledge Bases, so an agent that reads untrusted documents, or a RAG answer built from retrieved passages, is screened the same way. See the Knowledge Bases guide for the RAG side.
A Bedrock guardrail is a model-independent, versioned policy. Define the rules once and Bedrock enforces them on every prompt and answer, for any Bedrock model, for Agents, and for outside models through the ApplyGuardrail API.
IIThe six safeguards and what each one catches
A guardrail is built from separate policies. Turn on the ones you need and set how strict each one is. All of them can run together on the same request.
Content filters, including prompt attacks
Content filters catch harmful text or images in six categories: hate, insults, sexual, violence, misconduct and prompt attack. You set a strength for each category. A higher strength blocks more, and also blocks more legitimate content by mistake. The prompt attack category targets jailbreaks and injected instructions such as "ignore your previous instructions". It matters most for public apps and for agents that read tool output. Content filters come in a Classic tier and a Standard tier; the Standard tier also checks code elements such as comments, variable names and string literals.
Denied topics
A denied topic is a subject you describe in plain language, with optional example phrases. A banking assistant can deny investment advice. An HR bot can deny legal advice. When a prompt or answer touches the topic, the guardrail blocks it and returns your message. Content filters deal with harm; denied topics deal with scope.
Word filters
Word filters block exact words and phrases: a managed profanity list you can switch on, plus your own list (competitor names, internal code names). Matching is literal, case-insensitive and whole-word, so it is predictable and cheap, but it only catches terms you can list in advance.
Sensitive information (PII) filters
This policy detects personal data such as names, email addresses, phone numbers, addresses, national ID numbers and card numbers, in prompts and answers. For each type you choose to block the request or mask the value (for example, replace it with {PHONE}). You can add regular expressions for your own identifiers, such as account or medical record numbers. Our PII redaction page goes deeper on this filter.
Contextual grounding checks
Grounding checks score whether an answer is supported by the source text you supplied (for example, the passages a Knowledge Base retrieved) and whether it is relevant to the question. You set a threshold for each score. Answers below it are blocked or flagged. This turns "the model made it up" from a hidden failure into a rule you can enforce.
Automated Reasoning checks
Automated Reasoning checks test an answer against a set of logical rules you define, such as an eligibility or policy document turned into rules. AWS says they can detect hallucinations, suggest corrections and point out unstated assumptions. They are the newest safeguard and are priced per policy; check the pricing page before you plan on them.
| Safeguard | What it catches | Action | How it decides |
|---|---|---|---|
| Content filters | Hate, insults, sexual, violence, misconduct, prompt attacks | Block | Model judgment, strength per category |
| Denied topics | Subjects you describe as out of scope | Block | Model judgment against your descriptions |
| Word filters | Exact words, plus a managed profanity list | Block | Literal matching |
| Sensitive information | PII types, plus your regex patterns | Block or mask | Detection plus regex |
| Contextual grounding | Answers not supported by the source, or off the question | Block or flag | Grounding and relevance scores |
| Automated Reasoning | Answers that break your logical rules | Flag, suggest corrections | Checks against a rules policy |
IIIHow to configure a guardrail and how versions work
You describe the policy; Bedrock enforces it. Treat the guardrail like code.
You can create a guardrail in the console, through the API or SDK, or with infrastructure as code (CloudFormation, CDK or Terraform). For production, infrastructure as code is the better choice, because the guardrail is a compliance record that belongs in version control. In the configuration you turn on the policies you need, set their strengths and thresholds, and write the blocked messages users see for a blocked prompt and a blocked answer.
While you edit, you work on a draft. When the policy is right, you publish a numbered version. Versions never change. Your application calls a specific guardrail ID and version, so changing policy is a deliberate step (publish a new version, point the app at it) and rolling back means pointing at the old one. That history also shows an auditor which policy was live on a given date.
IVThree ways to apply a guardrail
One policy can protect direct model calls, agents, and models that do not run on Bedrock.
- Inline on a model call: Pass the guardrail ID and version on a Converse or InvokeModel call. Bedrock checks the prompt before the model sees it and the answer before you get it back. The same guardrail works for every Bedrock model.
- Attached to a Bedrock Agent: The guardrail screens the user input and the model output at each step of the agent. Agents take actions and read untrusted content, so this is the control to turn on first for any production agent.
- Standalone with the ApplyGuardrail API: Send any text to ApplyGuardrail and get back whether it was blocked, what was masked and which policy fired, without calling a model. Use it to screen text anywhere in your pipeline, or to apply the same policy to a self-hosted model, a SageMaker endpoint or another vendor's API by checking text before and after that call.
For RAG and chat apps you often want to check only the user's input, not your system prompt or retrieved passages. The SDK lets you tag the part of the prompt to evaluate; the console and playground do not.
VTesting a guardrail, and what it means for HIPAA, PCI DSS and SOC 2
A guardrail is a control. Controls need tests and evidence.
Test before you ship
The console has a test window where you send sample prompts and answers to a draft guardrail and see which policies fire. Build a test set: normal requests that must pass, harmful ones that must be blocked, jailbreak attempts, prompts full of personal data and off-topic questions. Run it every time you change a threshold, and keep it as a regression suite through the API. You are looking for the balance between letting violations through and blocking real users.
The compliance angle
Guardrails often make a generative AI feature possible in a regulated setting. Masking personal data supports privacy duties under HIPAA, and masking card numbers before they are stored or logged helps with PCI DSS work. Denied topics and content filters support acceptable-use rules. Versioning gives a SOC 2 assessor change-control evidence.
Two limits. A guardrail is one technical control, not a certification; HIPAA, PCI DSS and SOC 2 are whole programs (agreements, scoping, access control, logging, audits). And on the AWS side, the Bedrock security page says Bedrock is HIPAA eligible and in scope for ISO, SOC and CSA STAR Level 2; check AWS's compliance pages for anything else you need.
VIWhat Guardrails cost, and what they do not do
Guardrails cost little next to model tokens, but they are not free and not perfect.
Guardrails are billed on the text they check, on top of the model tokens. A text unit holds up to 1,000 characters. On 10 October 2026 the Bedrock pricing page listed: content filters (text) and denied topics at $0.15 per 1,000 text units; sensitive information filters and contextual grounding checks at $0.10 per 1,000 text units; regex-based sensitive information filters and word filters free; image content filters per image; Automated Reasoning checks per policy. For most apps the model tokens are the bigger line, but guardrail cost grows with traffic and with each policy you turn on, so measure it at high volume.
- Mistakes happen both ways: Judgment-based filters can block legitimate content and miss cleverly worded violations. Tuning narrows the gap; it does not close it. Keep a human path for high-stakes decisions.
- Prompt injection keeps changing: The prompt attack filter raises the bar but new jailbreaks keep appearing. Pair it with least-privilege design and treat tool output and retrieved text as untrusted.
- It adds latency and cost per call: Checking input and output is extra work on every request. Measure it on latency-sensitive paths.
- Coverage varies by language: Filter quality can differ across languages and specialist domains. Test with your own content and languages, and lean on word lists and regex where judgment is weaker.
- Your definitions set the quality: A vague denied-topic description or an incomplete regex leaves gaps. This is configuration work, not a switch.
VIIWhen you need a guardrail, and a starting configuration
Most apps that face users or touch regulated data need one. Internal prototypes with trusted users often do not.
Add a guardrail when the app is public or customer-facing, when it handles personal or regulated data, when it is an agent, or when you need auditable controls. Even for internal tools, grounding checks can be worth it for answer quality.
A starting point for a customer-facing assistant: content filters at medium with prompt attack on; denied topics for clearly out-of-scope subjects; sensitive information set to mask, not block, for common identifiers, plus regex for your own IDs; and grounding and relevance checks for any RAG answer. Run your test set, watch real traffic for false positives, and adjust. Start a little strict and loosen with evidence.
VIIIWho can file AWS funding for a guarded Bedrock build
There are two kinds of AWS money for a Bedrock build. A partner files one. You apply for the other yourself.
Partner-filed funding. An AWS consulting partner can file POC (proof of concept) funding to test a Bedrock workload, whether or not you run on AWS today. If you already run on AWS and are adding new AI work, the partner can file incremental workload (IW) funding instead. For startups this is often $50K to $150K. Depends on the workload; AWS approves. The work has to be real, and the partner has to be the one doing it.
AWS Activate, which you apply for yourself. Activate Founders gives $1,000 to start, up to $5,000, with no investor needed. Activate Portfolio gives up to $200,000 if your VC, accelerator or angel group is an Activate Provider and gives you its Org ID. A consulting partner cannot apply for Activate on your behalf. AWS made Activate credits usable for third-party models on Bedrock in April 2024.
For most startups without a VC, the partner route is the larger of the two. CloudRoute matches you with one vetted AWS partner for free. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
| Funding | Who files it | Amount | When it fits |
|---|---|---|---|
| Proof of concept (POC) funding | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You want to test something, whether or not you are on AWS today. |
| Incremental workload (IW) funding | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You are already on AWS and are launching new work: a new AI feature, a new customer or a new contract. |
| AWS Activate Founders | Founder applies | $1,000 to start, up to $5,000 | Self-funded startups with no investor or accelerator behind them. |
| AWS Activate Portfolio | Founder applies | up to $200,000 | Startups backed by a VC firm, accelerator or angel investor that is an AWS Activate Provider. |
| AWS Credits for AI Startups | Invite only (AWS account manager) | $200,000 or more, by invitation | AI startups ready to scale after Activate Portfolio, invited by AWS. |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks POC funding
Your matched partner scopes the test with you. Then it checks whether the test qualifies for POC (proof of concept) funding. A POC can fit whether or not you run on AWS today.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What are Amazon Bedrock Guardrails?
Can Bedrock Guardrails detect and mask PII?
How do Guardrails reduce hallucinations?
Do Guardrails work with models that are not on Bedrock?
Do Guardrails make a Bedrock app HIPAA, PCI DSS or SOC 2 compliant?
How much do Bedrock Guardrails cost?
Can AWS funding pay for a Guardrails build?
Get a partner who can build it and file the funding
Tell us what you are building on Bedrock. We match you with one vetted AWS partner. If the work qualifies, the partner files POC funding for a test, or incremental workload (IW) funding for new work on AWS: often $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.