Bedrock Guardrails, filters and formal verification

Bedrock Guardrails, filters and formal verification

Bedrock Guardrails is a safeguard layer inside Amazon Bedrock that you configure once and attach to model calls. It checks input and output against six policy types, from classic moderation through to formal verification that an answer satisfies rules you wrote yourself.

That last point separates this from typical content filters. Most competitors judge whether text is harmful. This service can additionally check whether an answer contradicts your company's rules, and do it by proving rather than guessing.

Six policy types

Worth knowing them separately, since they differ in purpose, price, and quality, and switching everything on at once is the most common mistake.

Content filters detect harmful material across categories covering hate, insults, sexual content, violence, misconduct, and prompt attacks. You set filter strength for each category independently.

Prompt attacks form a subcategory of content filters and cover jailbreaks, instruction injections, and system prompt leakage.

Denied topics let you list areas the application should avoid, described in natural language. A banking assistant can refuse conversation about investment advice this way, even though such a conversation is not harmful in the moderation sense.

Word filters work on exact matches and exist to cut specific expressions: profanity from a ready list or your own entries, competitor names for instance.

Sensitive information filters detect personal data in standard formats plus custom patterns, and can block or mask it. They run on a learned model, so they account for context rather than the shape of a string alone.

Contextual grounding checks detect answers that do not follow from the supplied sources or do not answer the question. That check targets applications built on document search.

Formal verification, the most interesting part

Automated reasoning checks form a separate category, and their advantage deserves understanding.

You write a policy in natural language: which rules must hold, what is permitted, what is mutually exclusive. The service translates that into a formal representation, then for each model answer checks whether it can be reconciled with those rules.

The difference from a classifier is fundamental. A classifier returns a probability, so the answer reads "this probably breaks the rules". Formal verification returns a determination with a justification, so the answer reads "this contradicts rule three". The vendor quotes accuracy in detecting correct answers reaching ninety nine percent, and that figure deserves treating as a claim to verify against your own rules.

The applications are narrower than the description suggests. It works where rules can be expressed logically: product availability, pricing conditions, terms of service compliance, eligibility criteria. It does not work where judgement depends on social context or tone.

The feature became generally available in August 2025, following a preview announced in December 2024.

Processing tiers and code support

The service distinguishes two processing tiers, and that distinction carries consequences easy to miss.

The higher tier extends detection into code elements: comments, variable and function names, and string literals. On the basic tier those places go unexamined.

That matters for coding assistants and anywhere a model generates code. An instruction hidden in a comment, or unwanted content typed as a variable name, passes a filter looking only at prose.

System prompt leakage detection runs at the same tier and is absent from the basic one. If your system prompt holds anything a user should not see, that is the deciding argument.

The logging trap

This is a detail that can undo the whole point of a deployment, and it does not appear in sales material.

Content blocked by any policy lands in model invocation logs as plain text, provided you have those logs enabled. That means personal data the filter detected and masked in the response to the user sits in full in the log.

Two consequences follow. Under personal data processing requirements, the log becomes another place needing retention, access control, and encryption. And: if you deployed the filter precisely so data would not be stored somewhere, enabling logs undermines the goal.

Two answers exist, both awkward. You can disable invocation logs, losing diagnostic material. You can keep them and place them under the same regime as production data. There is no third route, and the decision deserves taking deliberately, before somebody outside asks about it.

Pricing and how to compute it

Billing follows text units, where one unit is up to a thousand characters, and the rate is quoted per thousand units.

Content filters and denied topics cost fifteen cents per thousand units each, the same on both processing tiers, while image filtering bills separately at $0.00075 per image. Word filters and regular expression based sensitive information patterns are free. Model based sensitive information filters cost ten cents per thousand units, the same as contextual grounding checks. Formal verification costs seventeen cents per thousand units per policy.

That last sentence hides an arithmetic trap. The rate applies per policy, so three formal verification policies cost three times that amount for the same text. With several business rules described separately, the bill grows faster than the request count suggests.

Each filter type bills independently, and you pay only for those you enabled. That is an invitation to discipline: switching everything on because it feels safer multiplies cost by the number of mechanisms, most of which do not apply to your case.

Price one call against your own data before writing this into a budget. Take ten real interactions, count the characters entering each enabled filter, divide by a thousand, and multiply by daily volume. Grounding checks add the size of the sources, which usually exceeds the size of the answer itself.

Versioning and team practice

A guardrail configuration is a separate resource with its own versions, and that is a property worth using deliberately rather than discovering by accident.

The draft version exists for experiments, and numbered versions are immutable. The application points at a specific version, so somebody changing thresholds in the console does not immediately reach production. That is the only sensible arrangement, since a filter changed without warning can block traffic that previously passed, and nobody will connect that to a change they never saw.

The practical setup looks like this: a separate configuration for staging, another for production, with the version number kept in application environment variables rather than in code. Raising the version then becomes a deployment that can be rolled back.

Decide who owns that configuration as well. Filter thresholds are a product decision rather than a technical one, since they determine what share of genuine users gets stopped. A team where nobody owns that number sooner or later runs settings chosen by whoever happened to have access.

The last item is observing events. The response states which policy fired, so recording that alongside a session identifier gives material for judging whether the filter works and whether it blocks the right things. Without that data, changing thresholds is guessing.

Latency and how it feels to a user

Every check adds time, and with streamed responses that becomes a design problem rather than merely a performance one.

Checking input is simple: you add it before the model call and the user waits slightly longer for the first character. Checking output is harder, since you either withhold everything until generation finishes, losing the entire benefit of streaming, or check in fragments and risk retracting text the user already read.

A third route checks in fragments while delaying display by one fragment. The user sees a smooth stream while you always hold one chunk in reserve for stopping. It costs a small startup delay and is usually the best compromise.

Grounding checks do not fit that arrangement, since they need the whole answer together with the sources. In an application built on document search you therefore choose: streaming without that check, or that check without streaming.

Bedrock Guardrails against the alternatives

Two things distinguish the first row that the others do not match: denied topics described in natural language, and formal verification of rules. If your problem reads "the model must not promise things our terms forbid", that is the only entry on this list answering it directly.

The argument against is familiar and the same as for any cloud native service: a layer that is easy to keep independent gets tied to one vendor. There is a way around it, though, worth knowing.

Use outside a model call

The guardrails can be invoked on their own, without going through a model call in this service. You supply text and a configuration identifier and receive a verdict.

That changes the picture, since it lets you apply these policies to a model running elsewhere: at another vendor, in your own infrastructure, or locally. The safeguard layer stops dictating the model choice.

In practice that means three calls per interaction if you check input, externally fetched content, and output. Each bills separately and each adds latency, so decide up front which checks are necessary rather than enabling all of them out of caution.

Plan the failure behaviour too. An external call will eventually answer slowly or not at all, and the decision to pass or block traffic must be taken deliberately and written into the code alongside a timeout.

Deployment and choosing filter strength

Filter strength is set per category, and that is the right approach provided you use it.

Start in observation mode. Record the verdicts, block nothing, collect a few thousand real interactions. Only on that data will you see how much ordinary work each category would stop at each setting.

Match thresholds to the domain. A medical service must let symptom descriptions through, a legal one quotes from case files, and a tool for security teams vulnerability write ups. All three get blocked at general settings, and all three are substantive content.

Describe denied topics narrowly. A topic phrased broadly, "finance" for instance, kills half the conversations you want to serve. A topic phrased specifically, "recommending particular investment instruments", does exactly what it was meant to.

Write block messages generically. Telling a user which rule they broke and exactly how turns the filter into an experimentation tool and makes finding a phrasing that passes easier.

Common mistakes

The first is enabling every policy at once. Cost multiplies by the number of mechanisms, latency climbs, and most of them do not apply to your case.

The second is ignoring the logging question. Blocked content lands in the log in full, so a filter protecting personal data fails to protect it in that one place.

The third is costing formal verification without accounting for the policy count. The rate is per policy, so three rules described separately cost three times over.

The fourth is checking only what the user typed. Indirect injection arrives through documents and content fetched from the web.

The fifth is denied topics that are too broad. One word in a description can disable an entire category of conversations the application existed to serve.

The sixth is relying on the basic tier with an assistant that generates code. Without extension into code elements, content in comments and variable names passes unchecked.

FAQ

Which policies does Bedrock Guardrails offer?

Six types: content filters with harm categories and prompt attacks, denied topics described in natural language, exact match word filters, sensitive information filters, grounding checks against supplied sources, and formal verification of rules you write yourself.

What are automated reasoning checks?

Checking whether a model's answer can be reconciled with rules you wrote in natural language, performed formally rather than by classification. It returns a determination with a justification rather than a probability, and became generally available in August 2025.

What does it cost?

Billing follows text units of a thousand characters, quoted per thousand units. Word filters and regular expression patterns are free, content filters and denied topics cost fifteen cents each, sensitive information filters and grounding checks ten cents each, and formal verification seventeen cents per policy separately.

Can these guardrails run with a model outside this service?

Yes, the guardrails can be invoked on their own by supplying the text and a configuration identifier. That lets you filter content for a model running at another vendor or in your own infrastructure, at the cost of an extra network call.

Is this enough to protect personal data?

The filters detect and mask personal data in content, while blocked material lands in invocation logs in full. Under serious requirements it is worth adding something that runs locally, Presidio for instance, and placing the logs under the same regime as production data.

The policy descriptions sit in the service documentation, and the formal verification release in the AWS announcement.