Bedrock Guardrails and responsible AI safeguards
Lesson 4 of 4 in Securing ML and AI Workloads.
Infrastructure security protects the model; Amazon Bedrock Guardrails protects everyone from what the model says. A guardrail sits between the application and the FM, evaluating both the incoming prompt and the outgoing response against policies you configure — the same guardrail attaches to models, agents, and knowledge bases, giving one consistent safety layer across applications and model swaps. Six policy types: content filters (configurable thresholds for hate, insults, sexual, violence, misconduct — plus prompt-attack detection), denied topics, word filters, sensitive information filters (PII and custom regex — block or mask), contextual grounding checks (is the response grounded in the provided source and relevant to the query — the hallucination filter for RAG), and automated reasoning checks (logic-based verification against encoded policy knowledge).
Filter content
Content filters score prompts and responses across harm categories with per-category strength settings — including prompt attack detection for jailbreak and injection attempts. Denied topics and word filters handle the app-specific list: a bank's assistant that must never give investment advice, by policy rather than by prompt engineering.
Protect PII
Sensitive information filters detect PII entities (and custom regex patterns) in inputs and outputs, then block the message or mask the entities. The masking option is the exam tell for "support summaries must not include customer account numbers" — the workflow continues, the identifier does not.
Stay grounded
Contextual grounding checks compare the response against the retrieved source passages: answers that are ungrounded (not supported by the source) or irrelevant (off the user's question) are filtered. This is the RAG-hallucination control — policy-enforced, not prompt-requested.
Apply anywhere
Guardrails apply at invocation on Bedrock models, agents, and knowledge bases — and the standalone ApplyGuardrail-style evaluation lets applications run the same policies over text from models hosted outside Bedrock. One safety configuration, versioned and auditable, instead of per-app prompt rules.
Who may call the model is its own exam topic: Bedrock credential types. Standard IAM (roles, SigV4-signed calls) is the production answer. Bedrock API keys exist for lower-friction starts and tools that expect key-style auth, in two flavors with very different risk: short-term keys are capped (up to 12 hours, bounded by the generating principal's session), inherit that principal's IAM permissions, and work only in the Region that issued them — a secure convenience. Long-term keys silently create a dedicated IAM user with the key attached, can live indefinitely, and are Bedrock-only — AWS itself recommends them only for exploration. A static, long-lived secret in an app is a leak waiting for a repository; production traffic should ride IAM roles or short-term credentials.
Guardrails and credentials are the enforcement half of responsible AI; the judgment half is covered elsewhere on this line — bias detection with Clarify during data preparation, transparency via model cards and safety testing with model evaluations, and the human-oversight patterns those feed.
Interactive flashcard deck.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.