What's changed: Added figure aws-genai-security (OWASP LLM risks → AWS mitigations) to the gen-AI security section s4. The cloned base chapters inherit SCS-C02 figures; s4 was the only section lacking one, now filled.
3.4Securing generative AI applications
Learn generative AI security, newly added in SCS-C03: mitigations for the OWASP Top 10 for LLM Applications (prompt injection, sensitive information disclosure, insecure output handling, etc.), Amazon Bedrock Guardrails (content filters, denied topics, PII masking, grounding), access control to Bedrock (IAM), data protection for prompts/outputs, and auditing/logging of model invocations.
SCS-C03 (Dec 2025 revision) adds generative AI application security as part of infrastructure security. LLM-based apps have a new attack surface, and AWS services are used to mitigate malicious input, unsafe output, data leakage, and over-broad permissions. The OWASP Top 10 for LLM Applications is the reference guidance.
3.4.1Key risks from the OWASP Top 10 for LLM
- Prompt injection: malicious input hijacks the model’s instructions; mitigate with input validation, system-prompt protection, and guardrails.
- Sensitive information disclosure: sensitive data leaks via prompts or training; mitigate with PII masking and data minimization.
- Insecure output handling: using model output downstream without validation invites XSS/injection; mitigate by sanitizing output.
- Excessive agency: granting agents too much permission/too many tools causes harm; mitigate with least privilege and human approval.
3.4.2Amazon Bedrock Guardrails
Amazon Bedrock Guardrails applies safety controls centrally to generative AI apps: content filters (block violence, hate, sexual, misconduct by strength setting), denied topics (refuse specific subjects), sensitive information filters (PII masking) (detect and redact/block personal data), contextual grounding/relevance checks (suppress responses not grounded in retrieved context = hallucinations), and prompt attack filters (detect prompt injection). They apply to both input and output.
3.4.3Access control, data protection, and auditing
Control model access with IAM (grant bedrock:InvokeModel etc. least-privilege, scoped to specific models). For data protection, make Bedrock traffic private with a VPC endpoint (PrivateLink), encrypt data at rest with KMS, and protect sensitive prompts/outputs with Guardrails. Bedrock does not use customer prompts/outputs to retrain foundation models. Audit with CloudTrail (records Bedrock API calls) and model invocation logging (logs inputs/outputs to S3/CloudWatch Logs) to track who used which model and how.
| Goal | AWS control | Key point |
|---|---|---|
| Block unsafe input/output | Bedrock Guardrails (content filters/denied topics) | Applies to input and output |
| Prevent PII leakage | Guardrails sensitive info filter (PII masking) | Detect and redact/block |
| Reduce hallucination | Guardrails contextual grounding | Suppress ungrounded responses |
| Counter prompt injection | Prompt attack filters + input validation | Detect instruction hijacking |
| Least-privilege model access | IAM (scope InvokeModel) | Scope to specific models |
| Private traffic and audit | VPC endpoint/KMS + CloudTrail/invocation logging | Make private; track who did what |
Watch the mix-ups: (1) Bedrock Guardrails (safety on GenAI input/output) vs IAM (access to the model) are separate layers—both needed. (2) content filters (block harmful categories), sensitive info filters (PII masking), and contextual grounding (reduce hallucination) are distinct Guardrails features. (3) Bedrock does not use customer data to retrain foundation models. (4) Audit = CloudTrail (API calls) + model invocation logging (input/output content).
Map requirement → control: "redact PII from LLM responses" = Guardrails sensitive info filter; "refuse specific subjects" = denied topics; "reduce made-up answers" = contextual grounding; "detect prompt injection" = prompt attack filters + input validation; "allow only specific models to be invoked" = IAM InvokeModel scoping; "make Bedrock traffic private" = VPC endpoint; "record who invoked which model" = CloudTrail / model invocation logging.
3.4.4Section summary
- OWASP LLM Top 10 (prompt injection / sensitive info disclosure / insecure output handling / excessive agency) is the guidance
- Bedrock Guardrails = content filters / denied topics / PII masking / contextual grounding / prompt attack filters (on input and output)
- Least-privilege via IAM, private via VPC endpoint, encrypt with KMS, audit with CloudTrail + model invocation logging; Bedrock does not retrain on customer data
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which Amazon Bedrock feature centrally applies safety controls—harmful-content blocking, denied topics, PII masking, contextual grounding—to generative AI apps?
Q2. Which OWASP LLM risk involves malicious input hijacking the model’s system instructions?
Q3. To detect and redact/block PII in LLM responses, which Bedrock Guardrails feature do you use?
Q4. How do you control access with least privilege so only specific foundation models can be invoked?
Q5. To audit who invoked which Bedrock model and how, which do you use?
Q6. Which is correct about how Amazon Bedrock handles customer data?