A travel company launches a Bedrock chatbot that summarizes bookings and calls booking APIs, facing prompt injection and excessive agency risks from OWASP LLM Top 10. Which guardrail implementation should the security engineer apply to constrain the generative AI application behavior?
Select an answer to reveal the explanation.
Short Explanation
You're giving the helpful assistant firm house rules. Guardrails filter sneaky prompts, and least-privilege roles leash risky tool calls before damage happens.
Full Explanation
The correct implementation is right because it combines two controls that map to the two named OWASP risks. Bedrock Guardrails denied topics keep the chatbot to approved booking tasks, and the prompt attack filter detects jailbreak and injection attempts in user input. Excessive agency is not something Guardrails itself limits; it is constrained by scoping the agent's action groups and the IAM roles behind the booking APIs to least privilege, so even a steered model cannot perform out-of-scope actions. Enabling content filters for toxicity and PII redaction with CloudWatch logging fails by concept because it addresses harmful content and auditability without constraining which actions the application may take. Restricting knowledge base retrieval to authorized documents with IAM and encrypted storage fails by concept because it protects grounding data confidentiality but provides no runtime prompt inspection and no constraint on agent-invoked actions. Configuring action groups with Lambda validation and least-privilege roles alone scopes agency correctly yet omits prompt attack screening, leaving the model steerable by crafted inputs. An exam caveat is that logging, encryption, and IAM controls alone often look complete but do not satisfy a prompt injection plus excessive agency stem. A practical check is to run injection probes and out-of-scope booking actions in a test environment and confirm Guardrails intervenes and IAM denies the API call in CloudTrail.