Search⌘ K
AI Features

Security and Compliance

Explore how to design and implement security and compliance strategies for generative AI production with Amazon Bedrock. Understand access control using IAM and SCPs, navigate compliance requirements like HIPAA and FedRAMP, and apply AI governance principles for responsible and secure AI systems. This lesson equips you to manage organizational risk, third-party model considerations, and regulatory obligations effectively.

Securing generative AI applications requires more than prompt engineering and model selection. When Amazon Bedrock supports enterprise workloads that process sensitive data, influence business decisions, or run across dozens of AWS accounts, security controls need to extend beyond the application layer. The previous lesson covered Amazon Bedrock Guardrails and automated reasoning checks as application-level safety controls. This lesson covers the organizational security and compliance controls used to manage Bedrock deployments at scale.

The framework rests on three pillars. Access control through IAM policies and Service Control Policies determines who can invoke which models under what conditions. Regulatory compliance through certifications like HIPAA and FedRAMP defines the shared responsibility between AWS and the customer. AI governance through use case review, change control, and incident response ensures that responsible AI principles translate into operational practice rather than remain aspirational documentation. The key AWS services involved span IAM, AWS Organizations, AWS Artifact, CloudTrail, and SageMaker Clarify, each addressing a distinct layer of the security model.

Technical controls alone are insufficient. Responsible AI at scale demands organizational practices that no IAM policy can enforce.

IAM design for Bedrock access

The principle of least privilege is particularly important in Bedrock because a single overly broad permission grant can expose both inference and administrative capabilities. Bedrock defines distinct IAM actions that map to fundamentally different operations, and conflating them creates unnecessary risk.

Bedrock-specific IAM actions

The critical Bedrock IAM actions fall into two categories that should never be combined in a single role.

  • bedrock:InvokeModel grants the ability to send inference requests to a specific foundation model and should be scoped to individual model ARNs rather than wildcards.

  • bedrock:InvokeAgent permits execution of a specific Bedrock Agent, which may chain multiple model calls and tool invocations behind a single permission.

  • bedrock:RetrieveAndGenerate allows querying a specific knowledge base, combining retrieval and inference in one action.

  • Administrative actions such as bedrock:CreateGuardrail, bedrock:CreateKnowledgeBase, and bedrock:CreateAgent control the resource life cycle and should be restricted to platform teams.

Each action should be scoped to specific resources using ARNs. For example, restricting InvokeModel to only anthropic.claude-3-sonnet prevents a developer from switching to an unapproved model. IAM condition keys add further precision. The aws:RequestedRegion key restricts model invocation to approved regions, bedrock:ModelId ...