5.4.7. Safeguards and Sensitive Data Protection with Amazon Bedrock Guardrails
💡 First Principle: Access control decides who may call a model. It says nothing about what the model is allowed to hear or say. A guardrail is a policy evaluated on the content itself — the user's prompt on the way in and the model's response on the way out — so that responsible-AI rules and data-protection rules hold regardless of which model or prompt template produced the text.
Guardrail policies.
| Policy | What it detects | Typical requirement |
|---|---|---|
| Content filters | Hate, Insults, Sexual, Violence, Misconduct, with adjustable strength per category, for text and images | "Block harmful content" |
| Prompt attacks (a content filter category) | Jailbreaks, prompt injection, and prompt leakage (Standard tier) | "Stop users overriding the system prompt" |
| Denied topics | Topics you define in natural language | "Never give investment advice" |
| Word filters | Exact custom words and phrases, plus a managed profanity list | "Block competitor names" |
| Sensitive information filters | Built-in PII types and custom regex patterns, with Block, Mask (ANONYMIZE, replaced by tags like {NAME}) or detect-only (NONE) per type, and separately for input and output | "Redact customer names and card numbers" |
| Contextual grounding checks | Responses not grounded in the supplied source, or not relevant to the query, below a threshold you set (0 to 0.99) | "Filter hallucinations in RAG answers" |
| Automated Reasoning checks | Whether responses comply with logical rules you define as a policy | "Verify answers follow the eligibility rules" |
Where guardrails apply.
- With inference — pass
guardrailConfigon Converse, ConverseStream, InvokeModel or InvokeModelWithResponseStream; Knowledge Bases and Agents can also attach a guardrail. - Without inference — the
ApplyGuardrailAPI evaluates any text against a guardrail without invoking an FM. SetsourcetoINPUTfor user text orOUTPUTfor model text. This is how you protect models hosted outside Amazon Bedrock (for example on SageMaker AI), or check a user's question before spending tokens on retrieval. - Enforced by policy — an IAM condition on
bedrock:GuardrailIdentifierdenies inference calls that do not name the approved guardrail (and version). This turns "please use the guardrail" into "you cannot call the model without it".
Streaming. In the default synchronous mode, guardrails buffer and scan response chunks before they reach the user, adding some latency. In asynchronous mode chunks go out immediately and are scanned in the background, so inappropriate content can reach the user before the guardrail blocks later chunks — and masking of sensitive information is not supported in asynchronous mode. If a requirement says PII must never reach the user, use synchronous mode.
Sensitive data beyond the guardrail. Three gaps catch teams out:
- Invocation logs keep the original text. PII masking applies to what goes to the model and what comes back; the invocation log's input field still holds the original request. Protect logs with CloudWatch Logs data protection policies and KMS encryption.
- The guardrail trace reveals matches. The trace returned to your application contains the original matched PII value by design, so do not forward traces to end users or unprotected logs.
- Tool-use fields are not inspected. The sensitive information filter evaluates text content only. PII in tool-call arguments, tool results or tool definitions is neither blocked nor masked, so agent tools need their own data handling.
Monitoring guardrails. Guardrail metrics are published in the AWS/Bedrock/Guardrails namespace. InvocationsIntervened (dimensioned by GuardrailPolicyType — ContentPolicy, TopicPolicy, WordPolicy, SensitiveInformationPolicy, ContextualGroundingPolicy — and by GuardrailContentSource of Input or Output) shows how often each policy acts; prompt attacks count under ContentPolicy, because they are a content filter category. TextUnitCount shows consumption, which is what guardrail pricing is based on. A sudden rise in prompt-attack interventions on input is an attack signal; a rise in grounding interventions on output after a knowledge base change is a quality signal.
⚠️ Exam Trap: "Mask PII in the response" and "keep the logs free of PII" are two different requirements. A guardrail with ANONYMIZE handles the first. The second needs CloudWatch Logs data protection (or logging disabled for that data), because invocation logs record the original request.
⚠️ Exam Trap: Contextual grounding checks need three things — a grounding source, the query and the response — and are evaluated on the response only. They support summarisation, paraphrasing and question answering, not open conversational chatbots. A question that offers grounding checks for a free-form chat assistant with no reference source is offering the wrong tool.
