Security, Compliance, and Governance for AI Solutions
What this domain tests
Securing AI workloads and governing them: identity, encryption, network isolation, logging, compliance evidence, and the threats specific to generative AI.
Core rules
- Identity: IAM roles with least privilege, scoped per model and per action; separate roles for training, inference, and data access. Use resource policies to control access to Bedrock models and knowledge bases.
- Encryption: KMS customer-managed keys at rest; TLS in transit. Bedrock encrypts stored data and does not use customer prompts to train base models.
- Network: VPC endpoints (PrivateLink) keep traffic off the public internet; private subnets and security groups isolate SageMaker resources.
- Audit: CloudTrail for API activity, Config for configuration drift, Audit Manager for evidence, Artifact for compliance reports, Macie for sensitive-data discovery.
- Governance: cataloging and lineage (Lake Formation, Glue), model registry approvals, documented risk assessments, and retention rules.
- AI-specific threats: prompt injection via retrieved documents, jailbreaks, data poisoning, model exfiltration, and insecure handling of model output.
Worked example
A regulated insurer must run Bedrock on private data. Reasoning: isolate traffic with VPC endpoints and no public egress; encrypt with customer-managed keys; allow invocation only through a scoped role logged to CloudTrail; treat retrieved documents as untrusted so embedded instructions cannot hijack the prompt; retain logs per policy and map each control to the compliance framework.
Traps
- Granting bedrock:* to a broad role.
- Assuming encryption alone satisfies governance.
- Trusting retrieved content as instructions rather than data.
- Forgetting that training-data lineage is part of audit evidence.