Reference Architecture · AWS-Native AI Deployment
Govern AI on AWS with secure defaults.
A practical mapping of the AI IAM reference architecture to AWS managed services. Bedrock and Knowledge Bases for model and retrieval; IAM Identity Center, Verified Permissions, and Cedar for identity and policy; DynamoDB for the agent registry; CloudWatch, CloudTrail, and Security Lake for audit. Plus the secure defaults that make a governed deployment achievable rather than aspirational.
Operating principle
Business authorization lives in Cedar and Verified Permissions. Infrastructure authorization lives in IAM. They are separate concerns and should never collapse into one policy surface.
Seven layers, mapped to AWS
Each layer of the AI IAM reference architecture maps to specific AWS services with explicit secure defaults.
IAM Identity Center / Amazon Cognito
Intent: Establish the identity that travels through the chain
Workforce identity flows through IAM Identity Center; external application users flow through Cognito. The authenticated identity, group membership, and role context become inputs to every downstream authorization decision. Authentication is the start of the chain, not the end.
Secure defaults
- Enforce MFA for all human identity providers
- Map IdP groups to Identity Center permission sets, not raw IAM
- Propagate identity claims (sub, groups, attributes) into every downstream call
- Set short access-token lifetimes; rely on refresh for long sessions
Amazon Verified Permissions + Cedar
Intent: Evaluate business authorization separately from infrastructure
Cedar policies evaluate whether a requested AI action is allowed: can this user invoke this agent, can this agent use this tool, is this user entitled to this data, is the full runtime intersection acceptable. Verified Permissions manages the policy store; the orchestrator submits structured authorization requests with identity, agent, action, resource, purpose, and risk context.
Secure defaults
- Keep Cedar policies under version control; never edit in console
- Separate Cedar policy stores per AI surface area (agent, RAG, tool)
- Include purpose and risk as required context attributes
- Default to deny; require explicit permit policies
API Gateway · Lambda · Step Functions
Intent: Coordinate execution and enforce policy decisions
API Gateway terminates the request and validates basic access patterns. Lambda functions enrich the request with identity claims, agent registry metadata, declared purpose, resource attributes, and risk signals before submitting to Verified Permissions. Step Functions coordinate longer-running or multi-step workflows, ensuring each tool call, retrieval step, model invocation, or approval checkpoint is explicitly evaluated.
Secure defaults
- API Gateway uses IAM auth or JWT authorizers tied to Identity Center / Cognito
- Lambda execution roles are minimum-necessary; no wildcard policies
- Step Functions Express for sub-second flows, Standard for long-running auditable chains
- Every transition writes a structured event to CloudWatch with the correlation ID
DynamoDB
Intent: Treat agents and capabilities as governed metadata
DynamoDB holds the agent registry: agent records, owners, sensitivity tiers, allowed capabilities, approved tools, permitted purposes, delegation rules, expiration times, revocation status, and agent-to-agent trust relationships. The orchestrator loads this metadata at runtime and passes relevant attributes into the policy decision. Agents become first-class identities, not anonymous application logic.
Secure defaults
- Single-table design with strict access patterns documented
- Point-in-time recovery enabled on production tables
- Stream changes to a security event topic for audit
- Tier 4 agent records require dual-control approval for capability changes
S3 · Bedrock Knowledge Bases · OpenSearch · Lake Formation
Intent: Control which information can become model context
S3 stores source documents with metadata such as classification, owner, business domain, tenant, and retention category. Bedrock Knowledge Bases or OpenSearch support semantic retrieval, but retrieval must be constrained by authorization. Metadata filters and policy decisions narrow the searchable corpus before search occurs. Retrieved chunks are revalidated before insertion into the prompt context. Lake Formation enforces row and column-level controls for structured data.
Secure defaults
- All S3 buckets default-encrypted with KMS, no public access at account level
- Object metadata mirrors classification used in Cedar policies
- Knowledge Base data sources are tagged by sensitivity and tenant
- Implement pre-retrieval policy check and post-retrieval validation (see Secure RAG)
Amazon Bedrock + Guardrails
Intent: Invoke models with approved instructions and authorized context
Bedrock provides access to managed foundation models; Guardrails apply model-level controls for topics, safety, and response behavior. The model never decides whether data access was allowed; that decision happens before context reaches the model. The model plane applies guardrails, prompt constraints, and invocation controls, but it operates downstream of identity, policy, and retrieval enforcement.
Secure defaults
- Pin model versions explicitly; do not use 'latest' aliases in production
- Apply Bedrock Guardrails for topic, content, and word filters
- Restrict allowed models per Cedar policy; enforce via Verified Permissions
- Enable Bedrock model invocation logging to S3 or CloudWatch
CloudWatch · CloudTrail · Security Lake · GuardDuty · Macie
Intent: Preserve a traceable identity chain
CloudWatch captures application logs, policy decisions, orchestration events, retrieval metadata, and model invocation details. CloudTrail records AWS API activity. Security Lake centralizes security telemetry in OCSF format. GuardDuty contributes threat signals; Macie identifies sensitive data risk. The goal is a reconstructable execution path showing who initiated the request, which agent acted, what policies were evaluated, what data was retrieved, which model was invoked, and how the output was controlled.
Secure defaults
- Single correlation ID propagated through every transition
- CloudTrail organization trail with log file validation enabled
- Security Lake aggregating CloudTrail, VPC Flow, Route 53, and custom AI events
- Macie scans on all S3 buckets feeding Knowledge Bases
Account topology
Four account roles cover the typical enterprise deployment. The number of accounts scales with the number of AI workloads and environments; the roles do not.
Account role
Identity / Shared Services
Identity Center, central CloudTrail organization trail, central Security Lake, central audit S3 buckets. Cross-account access via permission sets, never cross-account IAM roles managed by hand.
Account role
AI Platform
Agent registry, Verified Permissions policy stores, orchestration Lambda functions, Step Functions workflows, shared knowledge bases for cross-tenant content.
Account role
AI Workload (per environment)
Per-environment Bedrock invocations, per-tenant S3 buckets for source documents, per-tenant Knowledge Bases. Production and non-production are separate accounts.
Account role
Logging
Centralized log aggregation. CloudWatch logs ship to Security Lake. Model invocation logs go to a write-once S3 bucket with Object Lock for Tier 4 systems.
Organization-level security defaults
Applied via SCPs at the AWS Organizations root or AI-workload OU. These should be in place before the first AI workload deploys.
- SCPs prevent disabling CloudTrail, GuardDuty, Security Lake, or Config at the account level
- All S3 buckets default to BlockPublicAccess; account-level controls enforce it
- KMS keys for AI data have rotation enabled; access is logged via CloudTrail
- IAM Access Analyzer enabled across the organization; external access reviewed weekly
- Bedrock model invocation logging enabled at the account level, not per-application
- Cross-account access only via Identity Center permission sets, never long-lived IAM users
- VPC endpoints for Bedrock, S3, DynamoDB to keep AI traffic off the public internet
Runtime flow
A single authenticated request traverses every layer. Each transition is a policy decision point, an enforcement boundary, and an audit event.
Mapping to governance
AWS services do not exempt a deployment from governance; they make the governance enforceable.
Risk Tiering (Section 2)
The Third-Party Model Dependency dimension is reduced for native Bedrock model invocation versus external vendor APIs. Tier reductions are still earned, not assumed.
SDLC (Section 4)
Control inheritance is real here. SCPs, central CloudTrail, and Security Lake satisfy multiple governance controls at the platform level. Product teams inherit them.
Monitoring (Section 5)
Bedrock invocation logs, GuardDuty findings, and Macie results feed the four-layer monitoring model. The executive dashboard pulls exposure metrics from Security Lake.
Incident Response (Section 6)
Containment uses Cedar policy updates (revoke agent capability), Bedrock model swaps (roll back to prior version), and IAM Identity Center (revoke human access). Speed comes from having the levers identified before the incident.