IAM for generative AI applications is the boundary between \u201cthe model can reason about this operation\u201d and \u201cthe AWS account actually permits this operation.\u201d Amazon Bedrock, Knowledge Bases, AgentCore, Lambda tools, vector stores, S3 sources, KMS keys, Secrets Manager, and application services can each require different identities and permissions. Collapsing them into one broad execution role makes agent behavior hard to contain and harder to audit.<\/p>\n
The durable principle is least privilege with separate identities for humans, deployment automation, application runtime, retrieval, and high-impact tools. AWS Identity and Access Management policies should express what each actor may do, at which resource scope, and under which conditions; prompts and agent instructions should never serve as substitutes for authorization.<\/p>\n
IAM design is a foundational layer of Generative AI on AWS<\/a>.<\/p>\n Developers need access to build and test, deployment pipelines need permission to change controlled resources, and runtime applications need only the calls required to serve users.<\/p>\n Least privilege<\/a> becomes easier when those roles are different instead of one administrator role being reused everywhere.<\/p>\n Production applications should obtain short-lived role credentials rather than embed developer access keys.<\/p>\n Runtime roles should be allowed to invoke only the foundation models, inference profiles, guardrails, prompts, or other resources needed by the product where the service supports resource-level scoping.<\/p>\n Model selection<\/a> should therefore produce an IAM allowlist as well as a product choice.<\/p>\n Do not leave every future model automatically invokable merely to avoid updating deployment policy later.<\/p>\n Applications can invoke models through in-Region IDs or inference profiles.<\/p>\n IAM should reflect which routing mechanisms are approved, especially where geographic data processing matters.<\/p>\n Changing from an approved geography profile to a global profile should require a controlled configuration and permission change rather than an arbitrary client parameter.<\/p>\n Knowledge Base service roles and application roles should be scoped to approved S3 data, vector stores, KMS keys, and supporting resources.<\/p>\n Knowledge Bases<\/a> should not gain account-wide data access simply because the model can theoretically answer many kinds of questions.<\/p>\n Data eligibility and tenant isolation should remain enforced outside the prompt.<\/p>\n A read-only catalog lookup, ticket creation function, and payment action do not need the same role.<\/p>\n Agent tools<\/a> should invoke narrow Lambda or service roles that match the operation and resource set.<\/p>\n Where a tool can create irreversible external effects, add server-side business authorization and approval instead of relying only on IAM action permission.<\/p>\n AWS global and service-specific condition keys can reduce permission scope by Region, VPC endpoint, resource tag, principal tag, or other supported context.<\/p>\n Conditions are useful when one policy must remain reusable across environments or tenants without granting every resource equally.<\/p>\n Test policy conditions with the actual runtime path because service-to-service calls can fail if a condition assumes request context that is not propagated.<\/p>\n For new agent architectures, AgentCore Identity provides workload identities and integrations for inbound user authentication and outbound credentials to tools or third-party services.<\/p>\n Agent identity<\/a> should distinguish the end user, the agent workload, and the downstream credential used to perform an action.<\/p>\n This separation improves auditability and reduces the need for one shared credential behind every agent.<\/p>\n Adding a Knowledge Base, MCP tool, model, S3 source, or external API can silently expand what the application may reach.<\/p>\n IAM review should be part of the same release that adds the capability.<\/p>\n Access Analyzer, CloudTrail, policy simulation, and application telemetry can help teams identify unused or unexpectedly broad permissions over time.<\/p>\n Assume the runtime can eventually be manipulated or exploited.<\/p>\nSeparate human and workload identities<\/h3>\n
Scope Bedrock model invocation<\/h3>\n
Protect inference profiles and routing choices<\/h3>\n
Give retrieval only the data it needs<\/h3>\n
Give every tool its own boundary<\/h3>\n
Use condition keys for context<\/h3>\n
Use AgentCore Identity for agent-specific identity<\/h3>\n
Review permissions after capability changes<\/h3>\n
Design IAM for compromise<\/h3>\n