AWSAWS Certified Generative AI Developer - Professional2026-103.1 Implement input and output safety controls

Match guardrail policies to safety boundaries

Completed by the knowledge check

Learning objective

Configure Bedrock Guardrails for denied topics, content, words, sensitive data, and contextual grounding policies.

Core idea

Amazon Bedrock Guardrails combines several policy families, but each answers a different question. A denied topic asks whether a conversation enters a prohibited subject. A content filter detects harmful categories. A word filter matches specified terms. Sensitive information filters detect personal data or configured patterns. Contextual grounding checks compare an answer with supplied evidence and a question.

Choose the policy from the violation you need to detect, then configure its action. Detection without intervention is useful for evaluation, but it does not enforce a production boundary. Conversely, blocking every detected signal can make legitimate requests unusable. The architecture decision is which information may cross each boundary, with what transformation, and under whose risk policy.

Keep factual support separate from acceptable content. An answer can be polite, contain no personal data, and still invent a refund policy. It can also accurately quote a source while containing content your application must withhold. Independent policies let you test these cases separately.

How it works

Define topics and harmful categories

The CreateGuardrail operation accepts topicPolicyConfig.topicsConfig. Each denied topic has a name, a definition, and type: DENY; optional examples illustrate the prohibited subject. Define the theme positively, such as personalized investment recommendations. AWS advises against negative definitions such as everything except product support and against using topics to detect individual names or words.

The definition can contain up to 200 characters. You can provide up to five example phrases, each up to 100 characters. These constraints favor precise boundaries over a long policy document. Include examples near the intended boundary, then evaluate legitimate adjacent subjects to detect excessive blocking.

Harmful categories belong in contentPolicyConfig.filtersConfig. The documented categories include HATE, INSULTS, SEXUAL, VIOLENCE, and MISCONDUCT. The same list also accepts PROMPT_ATTACK; prompt-injection and jailbreak detection is covered in 3.1.8. Configure inputStrength and outputStrength independently with NONE, LOW, MEDIUM, or HIGH. Stronger filtering changes which inputs or outputs trigger detection; it is not a promise that every violation is detected.

Select the evaluated modalities through inputModalities and outputModalities, whose documented values are TEXT and IMAGE. Scope the evaluation to the content the integration actually checks. AWS documents that content filters do not evaluate tool definitions, tool results, or model-generated tool arguments. A protected text response therefore does not certify a proposed tool invocation. Validate tools at their own boundary; see 2.1.10.

For content and denied-topic policies, inputAction and outputAction distinguish BLOCK from NONE. The latter returns detection information without taking action. Both content and denied-topic policies provide inputEnabled and outputEnabled to control whether prompts and responses are evaluated. Do not confuse an enabled detector with a blocking action.

Match words and sensitive information

wordPolicyConfig.wordsConfig holds custom terms, while managedWordListsConfig supports the managed PROFANITY list. Custom entries can contain up to three words, with up to 10,000 entries. Matching is case-insensitive and uses whole words or phrases; consecutive whitespace is normalized. A rule for competitor does not also match competitors. This is a lexical boundary, not semantic topic detection.

Use sensitiveInformationPolicyConfig.piiEntitiesConfig for supported personally identifiable information (PII) types and regexesConfig for your own patterns. For example, detect EMAIL as a predefined type and a company-specific case identifier through a regex. The documented actions are BLOCK, ANONYMIZE, and NONE. ANONYMIZE masks matching content rather than rejecting the whole interaction.

Select the action by the destination. A customer-support answer may retain meaning after masking an email address; a workflow that requires the exact address cannot substitute a masked value and continue silently. Maintain the original only in an authorized path that needs it. Masking a model response does not retroactively protect data already sent to the model or another service.

Configure contextual support

contextualGroundingPolicyConfig.filtersConfig configures GROUNDING and RELEVANCE checks with separate thresholds. Grounding measures support in the supplied source; relevance measures whether the response answers the supplied query. A response about the wrong product can be grounded yet irrelevant. A plausible answer to the right question can be relevant yet unsupported.

AWS permits thresholds from 0 through 0.99; 1 is invalid. With blocking configured, a score below its threshold triggers intervention. Calibrate each threshold on reviewed answers rather than choosing a midpoint. The documented input bounds are 100,000 characters for the source, 1,000 for the query, and 5,000 for the response. An application must handle oversized material explicitly rather than assume the check covers arbitrary context.

AWS documents support for summarization, paraphrasing, and question answering, and excludes conversational QA/chatbot use cases. Treat this as a capability boundary, not an invitation to call every conversation grounded. Response-to-passage verification and score interpretation are covered in 3.1.6; integration is covered in 3.1.2.

Key distinctions and trade-offs

A topic definition detects a subject; a word list detects a lexical occurrence. A product name in an otherwise permitted comparison needs a word rule if the name itself is forbidden. A paraphrased prohibited recommendation needs topic detection even when none of its example words appears.

Blocking prevents release of matching content, masking preserves a transformed result, and detection-only settings support observation. None replaces authentication or authorization. A request can satisfy all five policy families while asking for information the caller must not access.

Policy tiers also affect deployment. Content and topic configurations expose tierConfig.tierName with CLASSIC and STANDARD. AWS requires a guardrail cross-Region profile through crossRegionConfig for STANDARD. Verify the guardrail processing route separately from the foundation model’s route before adopting that tier for a residency-sensitive workload.

Architecture / decision scenario

A financial support assistant may explain account fees but must not recommend investments. The team configures a denied investment-advice topic, harmful-content categories, a managed profanity list, and custom restricted product phrases. It blocks prohibited recommendations while testing permitted fee explanations alongside them.

An email detector masks addresses in visible answers; a regex detects internal account references. For single-question fee answers, contextual grounding checks compare the generated response with approved fee passages and the actual question. Separate grounding and relevance thresholds prevent an accurate answer about a different account from passing.

The release test includes a harmless competitor-name mention, an investment recommendation without financial keywords, a valid fee answer containing an email, and an invented fee without harmful language. Each case must trigger its intended policy and action. The team records the configuration and processing route so changing a tier or detector remains a reviewable policy change.

Common exam traps

Using denied topics as an exact-name or entity detector.
Assuming a custom word entry matches morphological variants.
Treating NONE as production blocking.
Using ANONYMIZE where the downstream task requires the original value.
Assuming a grounded response necessarily answers the query.
Treating Guardrails as tool authorization or universal conversation verification.

What to remember

Match each violation to its policy family, direction, and action. Name the mechanism in your design: topic definitions, category strengths, word entries, PII types, regexes, and grounding thresholds. Test overlapping policies with legitimate boundary cases. A policy pass is evidence about configured checks, not permission to access data or execute an action.