Task 3.1: Implement input and output safety controls.

• ACreate a second guardrail with the prompt attack filter and apply it to the whole prompt, including the system instructions

  Incorrect

  Evaluating the whole prompt would also flag the developer's own instructions, which can resemble attacks, and untagged InvokeModel input is still not filtered for prompt attacks.

• BSwitch the model to a reasoning model so that it recognizes injected instructions on its own

  Incorrect

  Model behavior is not a deterministic control. The guardrail must be configured to see the user input.

• CWrap only the customer's message in the guardrail input tags so that the prompt attack filter evaluates that section

  Correct

  With InvokeModel, prompt attacks are filtered only inside the guardrail input tags. Tagging the user input makes the filter evaluate it while the developer's instructions stay out of the evaluation.

• DAdd a denied topic named prompt injection with sample phrases such as "ignore all previous instructions"

  Incorrect

  Denied topics block subject areas in conversations. They are not a substitute for the prompt attack filter, which is not applied to untagged input in this setup.

Prompt attacks often look like system instructions, so the guardrail needs to know which part of the prompt came from the user. With InvokeModel and InvokeModelWithResponseStream you mark that part with input tags; without tags, prompt attacks are not filtered. With Converse you use guardContent blocks.

• AAn Automated Reasoning policy built from the filings so that summaries are checked against formal rules

  Incorrect

  Automated Reasoning validates statements against a policy of logical rules, such as eligibility criteria. It does not score unstructured summaries for grounding in retrieved passages.

• BGuardrail content filters with every category set to HIGH for both the input and the output of the model

  Incorrect

  Content filters detect harmful categories such as hate or violence. They do not check whether a summary is supported by the source.

• CA lower temperature for the generation model so that it repeats the retrieved passages more closely

  Incorrect

  A lower temperature reduces randomness but gives no guarantee and no tolerance setting for blocking ungrounded or irrelevant answers.

• DA contextual grounding check with grounding and relevance thresholds on the retrieved passages

  Correct

  Contextual grounding scores whether a response is grounded in the source and relevant to the query, and blocks responses below the configured thresholds.

Hallucination control for RAG combines grounding with an automatic check. Contextual grounding needs the grounding source, the query and the content to guard, and uses two thresholds: grounding (supported by the source) and relevance (answers the question). It supports summarization, paraphrasing and question answering, not conversational chat.

• ADetect and mask card numbers inside the payment tool handler before its arguments are logged or used

  Correct

  Sensitive information filters do not evaluate the arguments that the model generates for tool calls, so masking must happen in the tool's own code.

• BRaise the guardrail's content filter strengths to HIGH for all categories on input and output

  Incorrect

  Content filter strength does not change what the guardrail evaluates. Tool results are still outside the prompt attack evaluation.

• CCheck each tool result with the InvokeGuardrailChecks API for prompt attacks before returning it to the model

  Correct

  The guardrail's prompt attack filter does not evaluate tool results in Converse. InvokeGuardrailChecks can run a prompt attack check on any text at any point, including after a tool returns a result.

• DAdd the word "ignore" and similar phrases to a guardrail word filter so that injected instructions are removed

  Incorrect

  Word filters match exact words and phrases, which attackers easily rephrase, and they would also block legitimate emails.

• EMove the guardrail from the Converse request to a guardContent block that contains the system prompt

  Incorrect

  guardContent limits evaluation to the marked content. Marking the system prompt would evaluate the developer's text, not the emails or the tool arguments.

Agents add new paths for content: tool results flow into the model and model-generated arguments flow into tools. Guardrails applied to Converse do not evaluate tool results for prompt attacks or tool arguments for PII, so defense in depth adds checks at those boundaries.

• ADenied topics for every leave scenario that the policy does not cover, with a custom blocked message

  Incorrect

  Denied topics block subjects. They cannot prove that an allowed answer follows from interacting rules.

• BAutomated Reasoning checks with a policy built from the leave policy document

  Correct

  Automated Reasoning checks use formal logic to show whether a response is consistent with the policy rules, explain why, and highlight unstated assumptions.

• CA contextual grounding check that compares each answer with the retrieved policy passages

  Incorrect

  Grounding checks score similarity to the source text with a threshold. They do not provide a verifiable logical explanation or flag unstated assumptions.

• DA knowledge base that returns citations to the policy sections used for each answer

  Incorrect

  Citations show where text came from, but they do not prove that the conclusion is logically consistent with the rules.

When rules interact and auditors want proof, use Automated Reasoning checks. They validate content against a formal policy, explain the result and point out unstated assumptions. They do not stream, support English only, and do not protect against prompt injection, so pair them with content filters.

• ARaise the number of retrieved results so that the model always has more passages to work from

  Incorrect

  When nothing relevant exists, more results only add more weak passages, and the model is still called for every question.

• BCompare each retrieved result's relevance score with the threshold and skip the model call when none passes

  Correct

  Every retrieval result carries a score for its relevance to the query. Checking it in code before generation returns the fixed reply the same way every time and avoids paying for a model call.

• CAdd a reranker model so that the most relevant of the retrieved passages move to the top of the list

  Incorrect

  A reranker reorders what was retrieved. If no passage is relevant, the reordered list still goes to the model.

• DAdd an instruction to the generation prompt to reply "not covered by policy" when the passages are irrelevant

  Incorrect

  The reply then depends on the model following the instruction, and the model is still invoked, and paid for, on every out-of-scope question.

Retrieval confidence can gate generation. Because each retrieved result reports how relevant it is to the query, the application can decide before any model call whether the knowledge base supports an answer, which is both deterministic and cheaper than asking the model to refuse.

• AAdd a mapping template to the integration response that returns only the reply text and the stop reason

  Correct

  With a non-proxy integration, an integration response mapping template can select which parts of the backend payload go into the method response. The trace stops at API Gateway, and the function and its logs stay as they are.

• BSet the trace to disabled in the guardrailConfig of each Converse call that the function makes

  Incorrect

  The trace setting is part of the function's Converse request, which cannot change this quarter. Turning it off would also remove the trace that the other team still needs.

• CAdd a Lambda authorizer to the method that strips the guardrail fields before the response is sent

  Incorrect

  A Lambda authorizer runs when the request arrives, before the method is invoked, and returns an IAM policy that allows or denies the call. It never sees the response that the integration returns.

• DCustomize the API's gateway responses so that they return only the reply text and the stop reason

  Incorrect

  Gateway responses shape the responses that API Gateway itself generates, such as errors when it cannot process a request. A successful response from the integration does not pass through them.

Safety metadata such as guardrail assessments helps operators but also helps attackers tune their inputs. In a defense-in-depth design, the API layer filters what reaches the client, so the backend can keep detailed traces for its own logs.

• ACompare the returned text with the configured blocked message for the customer's language

  Incorrect

  The blocked message is returned as the output text, but matching on it breaks whenever a translation or the quarterly wording changes.

• BRoute the conversation when CloudTrail records a guardrail evaluation event for the request

  Incorrect

  Guardrail evaluations are CloudTrail data events, logged only when a trail is configured for them and delivered as log files for later analysis, so they cannot drive a handoff inside the request.

• CCheck whether the response's stopReason is guardrail_intervened and read the guardrail trace

  Correct

  When a guardrail blocks content, Converse sets stopReason to guardrail_intervened, and with tracing enabled the trace shows which policy acted, so the code can branch immediately.

• DLook up each request in the model invocation logs and route it when the log shows an intervention

  Incorrect

  Invocation logs are written to CloudWatch Logs or Amazon S3 for later analysis. Reading them for every request adds delay and is not part of the response the application already has.

Real-time safety workflows should branch on the structured signal in the API response, not on text matching or on logs that arrive later. The stop reason and the guardrail trace give the application both the decision and the reason in the same call.

• AA sensitive information filter that blocks names and addresses in the responses

  Incorrect

  Sensitive information filters detect personal data such as names and addresses, not hateful, insulting or violent language.

• BA prompt attack filter at HIGH strength on every player message

  Incorrect

  The prompt attack filter looks for jailbreaks and injected instructions in prompts. It does not judge hateful language, and it never sees the model's replies.

• CA contextual grounding check with a high threshold on every response

  Incorrect

  Grounding checks score whether a response is supported by a source and relevant to the query. They do not detect harmful language.

• DContent filters for hate, insults and violence on both prompts and responses

  Correct

  Content filters detect these harmful categories in user prompts and in model responses, and the same guardrail can be applied to calls to any of the three models.

Harmful content can come from users or from the model, so filters must cover both directions. Content filters judge the harmful language itself, so a player can still discuss reporting harassment without being blocked, and one guardrail keeps the rules identical across models.

• AGive each document block a neutral generated name and keep the original name in the application

  Correct

  The document name is passed to the model and can be read as an instruction, so AWS recommends a neutral name. The portal can still display the original name from its own records.

• BAdd a guardrail word filter for phrases such as "ignore the policy limits" and "approve this claim"

  Incorrect

  Word filters match the exact words or phrases listed, so an attacker only has to reword the file name to get past them.

• CEncrypt every uploaded file with a customer managed AWS KMS key before it is sent to the model

  Incorrect

  Encryption protects the stored files. The model still receives the same file name and reads it the same way.

• DMove the customer's file name from the document block into the system prompt for each request

  Incorrect

  The untrusted text would still reach the model, now in the part of the request meant for developer instructions.

Treat every user-controlled string that reaches the model as untrusted input, including metadata such as file names. Sanitizing or replacing it before the call removes the injection path without changing the prompt.