AWS: Bedrock Guardrails and friends
Lesson 2 of 5 in Guardrails in the Cloud: Implementing Controls on AWS, Azure, and GCP.
Amazon Bedrock is AWS’s managed service for foundation models, and Amazon Bedrock Guardrails is its policy engine: you define a guardrail once — as a named, versioned resource — and attach it wherever models run. One guardrail, many applications, which is exactly the consistency property auditors like.
A Bedrock guardrail is a bundle of up to six policy types, each independently configurable, applied to inputs, outputs, or both:
Content filters — the harm categories
Configurable filter strengths across six categories: hate, insults, sexual, violence, misconduct, and prompt attacks (jailbreak and injection attempts). You tune the strength per category, separately for inputs and outputs — a medical app might allow clinical descriptions of violence a children’s app must block.
Denied topics — the scope fence
Natural-language definitions of topics your application must not engage with — investment advice in a retail-banking chatbot is the canonical example. The guardrail blocks the topic whether it appears in the user’s question or the model’s answer. This is how a legal scope decision ('our chatbot does not give financial advice') becomes a runtime behaviour.
Word filters — the blunt instrument
Exact words and phrases to block: profanity lists, competitor names, product code names. Crude but fast, and sometimes crude is correct — no classifier needed to know a codename must never leave the building.
Sensitive-information filters — PII in, PII out
Detects personally identifiable information (plus custom regex patterns for things like internal ticket IDs) and either blocks the request or masks the entities. Masking inputs before inference is a genuine data-minimisation control: the model provider never receives the raw identifier at all.
Contextual grounding checks — the hallucination filter
Scores each model response for grounding (is the claim supported by the reference source you supplied?) and relevance (does it answer the user’s question?), and blocks responses below your thresholds. This is the guardrail that turns hallucination from an accepted embarrassment into a measured, thresholded, logged quantity — the operational face of an accuracy obligation.
Automated reasoning checks — the newest layer
Verifies model claims against formal, logic-based policies you encode — mathematical verification rather than another statistical classifier. Powerful for domains with hard rules (eligibility criteria, policy documents), and young enough that you should check current docs for supported scope before building on it.
Where the guardrail attaches determines what it protects. You can attach it at direct model invocation (the InvokeModel and Converse APIs), to a Bedrock Agent (so every step of a multi-step agent conversation is screened, not just the final answer), and to Knowledge Bases (so retrieval-augmented answers are checked against the retrieved sources). And the standalone ApplyGuardrail API evaluates any text against your guardrail without invoking any model — which means the same policy bundle can screen traffic to a self-hosted model, or even a rival cloud’s model, from one place. That API is what makes Bedrock Guardrails usable as the policy engine of the gateway pattern from lesson one.
Evidence is built in if you switch it on. Guardrails emit CloudWatch metrics — total invocations, and InvocationsIntervened broken down by policy type (content, topic, word, sensitive-information, contextual grounding) and by direction (input vs output). That per-policy intervention count is governance gold: it tells you which controls are actually firing, at what rate, and when the rate changes. CloudTrail records the API calls themselves — who invoked, who reconfigured — and Bedrock’s model invocation logging can capture full request and response payloads to S3 or CloudWatch Logs for the applications where you need verbatim records.
Access control follows standard AWS discipline: least privilege IAM so that each application role may invoke only its approved models, in approved regions, with its approved guardrail — and nothing may quietly reconfigure a guardrail without that change appearing in CloudTrail.
For classical ML (and the predictive models that still make most consequential decisions), the governance tooling lives in Amazon SageMaker: Model Cards standardise model documentation into a reviewable, versioned fact sheet — intended use, training data, evaluation results, caveats; Clarify computes bias metrics before and after training and SHAP-based explanations of individual predictions; and Model Monitor watches deployed endpoints for data-quality and drift problems, with CloudWatch alerts when metrics cross thresholds.
Key terms: content filter, PII, hallucination, grounding, model card, model drift
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.