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

Assign each safety layer one gate

Completed by the knowledge check

Learning objective

Layer input sanitization, safety classifiers, model guardrails, output validation, and API response filtering.

Core idea

A layered safety pipeline works when each layer owns a different acceptance question. Sanitization asks whether input is represented safely. A classifier supplies evidence about content risk. Model guardrails apply configured content policy around inference. Output validation checks the application contract. API response filtering decides which accepted fields can leave the server.

For an architect, the design task is to place each decision before the behavior it protects. Five checks after a secret reaches the caller do not constitute five protective layers. Equally, a successful early check must not bypass a later one. Track processing success, policy approval, and authorization separately; they are different conditions for release.

How it works

Sanitize the application envelope

Start with deterministic rules: allowed media types, required fields, expected types, acceptable sizes, and a projection of task-relevant content. Preserve the semantic content needed for the task and the source identity needed for later checks. Do not label arbitrary string replacement as complete prompt-injection prevention. An instruction can remain hostile after you remove markup or punctuation.

For an API Gateway REST API, a request validator can check the payload against a configured JSON Schema and check that required URI, query, and header parameters exist and are not blank. The parameter check does not validate their type or format. Body validation depends on a matching content type; a $default model applies the same schema regardless of content type. API Gateway returns a 400 response when validation fails instead of invoking the integration.

This is a useful early contract gate, but your backend still checks app-specific values and permissions. See 2.4.3 for the request-validation boundary. Your sanitization policy should reject an invalid envelope before a safety classifier spends work assessing a body the application cannot use.

Convert classifier signals into application decisions

A safety classifier returns evidence; it does not define your product’s risk tolerance. Amazon Comprehend DetectToxicContent supplies per-label Labels[].Score and aggregate Toxicity signals; see 3.1.3 for its language and size limits and moderation adapters. Route unsupported input to an explicit application outcome rather than treating an incomplete assessment as approval.

Define your threshold and routing as application policy, then calibrate it on labeled cases. Toxicity and prompt injection ask different questions: an instruction to reveal a secret can be polite and non-toxic. A toxicity score therefore complements the prompt attack path; it does not replace it. See 3.1.3 for moderation adapters and 3.1.10 for calibration.

Enforce model policy on the covered fields

Bedrock content filters let you configure input and output strengths independently. GuardrailContentFilterConfig.inputAction and outputAction distinguish BLOCK from NONE, which detects without taking action. A detection-only policy requires your application to consume the assessment if you intend it to control release.

Use inline Converse guardrailConfig for its documented coverage and ApplyGuardrail for independent checks before processing or publication. In the independent API, source: INPUT and source: OUTPUT select the policy direction. Interpret action: GUARDRAIL_INTERVENED and the returned assessments and outputs according to the configured intervention, rather than treating a successful HTTP response as a safety approval. See 3.1.1 and 3.1.2 for policy selection and enforcement details.

Inline guardrails do not evaluate toolResult, tool definitions, or generated toolUse.input. The tool path therefore needs explicit validation and assessment before context admission or execution. See 3.1.7 and 3.1.8. A diagram that places one guardrail box around the entire agent conceals this field-level coverage gap.

Validate the result before selecting public fields

After generation, validate the expected output structure and business constraints in application code. A field can be well-formed but contain an unauthorized account identifier. A syntactically valid answer can make unsupported claims. Use the response-contract and evidence checks from 3.1.4 and 3.1.6 rather than treating content moderation as proof of correctness.

Then build the public API response from an allowlist of approved fields. A guardrail does not choose which API-envelope fields reach the caller. For a REST API using mapping template transformations, an API Gateway integration-response mapping template in Velocity Template Language (VTL) can project the backend payload into the approved public response. Configure that projection explicitly; it is not a substitute for the preceding safety or authorization decisions. Keep internal diagnostics, raw tool bodies, and policy assessment details out of the public envelope unless the product explicitly requires and authorizes them. Derive caller-visible errors from controlled application outcomes instead of serializing an upstream exception object.

Hold the content you intend to validate until the required gates finish. If your product streams output, define the unit that can be released and assessed before exposing it. A final validation pass cannot retract bytes already sent. The same rule applies to side effects: validate tool arguments and permissions before execution, not after the model describes the result.

Key distinctions and trade-offs

Assign an acceptance question to every layer:

Layer	Acceptance question	Failure decision
Sanitization and envelope validation	Can this input be processed under the contract?	Reject invalid input
Safety classifier	Does the risk signal pass application policy?	Block, review, or handle unsupported coverage
Model guardrails	Does assessed content pass the configured policy?	Handle intervention or assessment failure
Output validation	Is the result usable, authorized, and supported?	Reject or use a bounded approved recovery
API response filtering	Are these fields approved for this caller?	Withhold fields or return a controlled outcome

Additional calls add latency and more failure modes. Keep cheap deterministic checks early and avoid repeating the same assessment without a purpose. Nevertheless, do not remove the output gate because the input was safe: generation and tool results introduce content that the input check never examined.

Architecture / decision scenario

A public support API accepts a question, retrieves evidence, generates a structured answer, and returns a customer-facing response. The request validator rejects a missing question. Backend sanitization projects approved request fields and verifies the customer context. A toxicity classifier routes high-risk English text according to calibrated policy; unsupported language follows a separate path.

Bedrock Guardrails assess the covered model input and output. The application separately checks retrieved or tool-owned content before context admission. It then validates answer structure, evidence, and caller permissions and constructs only the approved response fields. An unavailable required assessment produces a controlled unavailable response, not a clean pass.

A release test inserts one defect at each boundary and verifies that it cannot reach the next protected behavior. Another test confirms that a valid answer still reaches the caller, so adding layers does not silently turn the API into universal refusal.

Common exam traps

Treating sanitization as semantic attack detection.
Using toxicity as the sole prompt-injection signal.
Assuming every Guardrails policy blocks when it detects.
Expecting inline guardrails to cover tool arguments and tool results.
Releasing a response before validation completes.
Assuming a guardrail automatically filters the application’s API envelope.

What to remember

Each layer answers a distinct question and needs a concrete failure route. API Gateway validates the request contract, classifiers supply risk evidence, and Guardrails enforce configured content policy within their coverage. Application code owns business validation and public-field selection. Approve content before release and tool operations before execution.