Generative AI has fully entered the enterprise mainstream and platforms like Amazon Bedrock allow organizations to build and scale AI use cases with Foundational Models such as Anthropic’s Claude, Mistral, Amazon’s Titan and more through familiar AWS APIs. While enterprises can use Bedrock to experiment, customize, and deploy generative AI tools, they also introduce new access surfaces. Model interactions frequently contain sensitive prompt content, intellectual property or customer data. Security organizations must therefore carefully consider access privileges that balance AI-enabled innovation with appropriate access.
Mismanaged Bedrock permissions can quietly bypass existing identity controls. A developer role with broad ` bedrock:* `permissions, or an automation pipeline configured with unrestricted invocation rights, can lead to exposure of internal data or spiralling AI usage costs.
Managing who can invoke, manage, and share these models is an access governance problem, not just a cloud operations issue. This post explores where risks lie, what controls security leaders should consider, and how to measure governance maturity for Bedrock adoption.
Mapping Identity Risks in AWS Bedrock
A review of permissions within Bedrock reveals several gotchas for unwary security and identity teams:
Runtime access risk: The `bedrock:InvokeModel` permission determines who can call a model and run inference, making it a critical identity checkpoint. Poorly scoped permissions can expose sensitive workloads or enable mass inference on internal data without oversight – with the corresponding data risks and cost implication.
Configuration and lifecycle risk: Permissions such as `bedrock:CreateModelCustomizationJob` or `bedrock:UpdateModel` allow teams to modify or customize models. If granted broadly, they can lead to unapproved model fine-tuning or injection of unvetted training data.
Cross-account and multi-region risk: Bedrock supports resource-based policies and cross-account access. While this enables shared inference services, it also creates new trust boundaries. Without central governance, an account in one region could invoke or share models in another, creating data residency or compliance blind spots.
Auditability and detectability risk: Model invocations generate CloudTrail events, but these events should be correlated back to human or workload identities, otherwise audit trails will require additional effort to link to identities.
Bedrock Governance Guidance
Governing Bedrock usage is an identity necessity, not nicety. Identity teams should be sure to:
Standing access vs. just-in-time invocation: Bedrock supports programmatic access through IAM roles, which can easily accumulate standing permissions if not governed correctly. Instead, require users and workloads to obtain short-lived access, scoped specifically to a model or use case, and expire them automatically. This limits the exposure if keys or roles are compromised.
Privilege scope and separation of duties: The same user or role should not both administer models and invoke them in production. Blurred privilege boundaries create insider risk and weaken accountability. Separate high-privilege model management actions (CreateModelCustomizationJob, UpdateModel) from runtime invocation (InvokeModel) and implement permission boundaries to prevent privilege escalation and enforce least privilege across the Bedrock ecosystem.
Identity provenance and trust chain: Bedrock interactions often originate from federated identities or machine roles. AWS IAM entities and corporate identities should be mapped to allow for auditable and compliant-friendly event tracking. Every invocation must trace back to a verified user, service, or workload in your authoritative identity provider (e.g., Okta, Entra ID). Federation and attribute mapping should be standardized, validated, and logged.
Cross-environment and data-governance risk: Bedrock’s cross-account and cross-region features make it easy to share inference workloads, but also to leak access or data unintentionally. Therefore, apply governance boundaries using AWS Organizations SCPs and resource-based policies. Limit model invocation to trusted accounts and approved regions. Tie these policies to your enterprise data classification and residency rules.
In a Nutshell
In a nutshell, generative AI enablers like Amazon Bedrock unlock the innovation potential of AI across the enterprises, but they also significantly expand the identity attack surface. As invocation rights become the new form of privilege, security maturity will be defined not just by how quickly teams can experiment, but how that experimentation can be enabled for the right identities, with tightly scoped permissions, at the right time.
Frequently asked questions
How do you control and govern access for AI agents built on AWS Bedrock?
Controlling access for AI agents on AWS Bedrock means applying secondary authorization that scopes each agent action to what its underlying human user is actually permitted to do.
What is secondary authorization and how does it right-size AI agent permissions in AWS Bedrock?
Secondary authorization right-sizes AI agent permissions in AWS Bedrock by checking every agent action against the human user’s own access rights, rather than granting the agent broad standing permissions.
How does P0 Security apply just-in-time access to Amazon Bedrock agent workflows?
P0 Security applies just-in-time access to Amazon Bedrock agent workflows by granting ephemeral, task-scoped permissions for each agent session and revoking them automatically once the workflow completes.
How can security teams audit what an AWS Bedrock agent accessed and which human triggered it?
Security teams audit AWS Bedrock agent activity by tracing every action back to the accountable human user through P0’s session-level, end-to-end audit logs.