AWS Bedrock access governance is now an identity control problem

At a glance

What this is: This is an analysis of AWS Bedrock access governance and the identity risks created by broad model invocation and management permissions.

Why it matters: It matters because Bedrock permissions now sit in the same governance stack as NHI, workload identity, and human access control, so weak scoping can expand blast radius across AI and cloud programmes.

👉 Read P0 Security's analysis of AWS Bedrock access governance and AI identity risk

Context

AWS Bedrock turns model invocation into an access control problem. If a developer role, automation pipeline, or federated workload can call models broadly, the issue is no longer just AI adoption. It becomes a question of who can access sensitive prompts, internal data, and model management functions under existing IAM boundaries.

The core governance gap is familiar to IAM and NHI teams: standing privilege, weak separation of duties, and poor identity provenance. Bedrock adds a new runtime surface where invoke rights, customization rights, and cross-account sharing all need to be tied back to authoritative identities and policy boundaries.

Key questions

Q: How should security teams govern Bedrock access for AI workloads?

A: Security teams should govern Bedrock access as privileged access, not routine application access. That means separating model administration from runtime invocation, using task-scoped permissions, and tying every call to a verified identity. Shared inference should be allowed only where account, region, and data-classification guardrails are explicit and enforceable.

Q: Why do broad model invocation rights create governance risk?

A: Broad invocation rights allow an identity to process sensitive prompts, expose internal data, and generate uncontrolled cost or output at scale. The risk increases when the same role can also manage models or when access is inherited through automation. Least privilege has to apply to model usage, not just infrastructure.

Q: What breaks when model management and model use are granted to the same role?

A: Separation of duties breaks down. The same identity can change a model, influence training inputs, and then invoke it in production, which makes it harder to prove accountability or detect misuse. That creates insider risk and weakens forensic clarity across the AI lifecycle.

Q: Who is accountable when Bedrock access crosses accounts or regions?

A: Accountability should sit with the identity owner, the platform owner, and the policy owner, but only if cross-account access is mapped back to a verified directory identity. Without that mapping, CloudTrail shows activity but not trustworthy ownership, and governance decisions become difficult to defend in audit or incident review.

Technical breakdown

Bedrock invocation rights and runtime access

`bedrock:InvokeModel` is the runtime permission that determines whether an identity can call a foundation model. In practice, this is equivalent to a high-value access decision because every invocation may process sensitive prompts, proprietary data, or regulated content. If the permission is granted broadly, model access can become a hidden channel around conventional application controls. That makes runtime scoping and identity traceability central to governance rather than optional audit detail.

Practical implication: scope invocation rights to specific roles, use cases, and environments, then review them as privileged access.

Model customization and privilege separation

Bedrock also includes management actions such as `CreateModelCustomizationJob` and `UpdateModel`, which change how a model behaves or what data it is trained on. Those permissions are not interchangeable with inference permissions. When the same identity can both alter and invoke a model, the environment loses separation of duties and makes it harder to prove who changed what and when. That creates both insider risk and governance ambiguity.

Practical implication: split model administration from model use and place permission boundaries around customization actions.

Cross-account and cross-region trust boundaries

Bedrock supports resource-based policies and cross-account access, which can simplify shared inference but also weaken data residency and accountability controls. Once invocation spans accounts or regions, the security model depends on policy hygiene, organization-level guardrails, and reliable identity mapping across federated and workload identities. Without those controls, audit trails may show a model call but not a trustworthy owner or business justification.

Practical implication: enforce organization SCPs, approved-region controls, and standardized identity mapping before allowing shared Bedrock access.

NHI Mgmt Group analysis

Invocation rights are becoming a new class of privileged access. Bedrock changes the old cloud pattern where access meant reading data or launching infrastructure. Here, access can also mean spending compute, exposing prompts, or influencing downstream outputs at machine speed. That makes model invocation governance a privileged access issue, not a general application entitlement issue. Practitioners should treat `InvokeModel` as a high-risk control point in the identity stack.

Separation of duties breaks when the same identity can shape and consume model behaviour. Permissions such as `CreateModelCustomizationJob` and `UpdateModel` belong to a different trust tier than runtime invocation. When teams blur those tiers, they lose accountability over model state, data provenance, and production use. The practical conclusion is that Bedrock governance must preserve role separation, not just permission minimisation.

Identity provenance is the missing control plane for AI auditability. Bedrock CloudTrail events are only useful if they resolve to a verified human, service, or workload identity in the authoritative directory. That is an NHI governance problem because machine identities and federated identities often carry the actual invocation rights. Without reliable provenance mapping, security teams can see activity but cannot prove ownership or intent.

Cross-account model sharing creates governance debt unless policy boundaries are explicit. Shared inference services can be efficient, but they also widen the blast radius across accounts, regions, and data classifications. This is where organisational guardrails become mandatory: the model may be technically reachable, but not every reachable path should be authorised. Practitioners should align Bedrock access with residency, classification, and trust-boundary policy.

Model invocation blast radius: The most useful concept in this topic is not raw AI usage but the blast radius created when a role can invoke models at scale without task-scoped limits. That single permission can trigger data exposure, cost abuse, and unreviewed inference across sensitive workflows. Teams should evaluate Bedrock permissions as an identity containment problem, not just a cloud enablement feature.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap makes governance the first control to fix, as shown in Analysis of Claude Code Security, which maps how agentic access expands the identity surface.

What this signals

Model invocation is converging with privileged access governance. As AI platforms become normal enterprise infrastructure, the control question shifts from whether a model can be used to which identity is allowed to use it, under what scope, and with what audit trail. Teams that already manage NHI sprawl should treat Bedrock as another place where access can outgrow review processes, especially when automation pipelines hold persistent permissions.

Invocation telemetry only helps if identity provenance is reliable. The governance gap is not the absence of logs, but the absence of a dependable identity chain behind each call. A useful reference point is the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, which frames provisioning, rotation, and offboarding as lifecycle controls that must extend to machine and workload identities.

Access blast radius will become the practical metric for Bedrock maturity. Teams should measure how far a single role can reach across models, accounts, regions, and data sets before it becomes visible to governance. That aligns with the OWASP Non-Human Identity Top 10, especially where standing access and overprivilege turn AI usage into an identity exposure problem.

For practitioners

• Separate invocation from administration Create distinct roles for runtime model use and model configuration changes. Keep `InvokeModel` away from `CreateModelCustomizationJob` and `UpdateModel`, then apply permission boundaries so no single identity can both change and consume production models.
• Replace standing Bedrock access with short-lived access Issue temporary, task-scoped permissions for model invocation and expire them automatically. This reduces the impact if keys, roles, or federated sessions are misused and makes access reviews meaningful instead of ceremonial.
• Map every invocation to a verified identity Correlate CloudTrail records to the authoritative human, service, or workload identity in your directory. Standardize federation claims and attribute mapping so investigators can trace each call back to an owner and business context.
• Apply organisation-wide guardrails to shared model access Use AWS Organizations SCPs and resource-based policies to restrict invocation to approved accounts and regions. Tie those controls to data classification and residency rules so shared inference does not bypass governance.
• Review Bedrock as a privileged access surface Add Bedrock permissions to privileged access reviews, especially where automation pipelines or developer roles can invoke models at scale. Treat high-volume inference rights as a governance item with measurable ownership, not an incidental technical setting.

Key takeaways

• AWS Bedrock turns AI usage into an identity governance problem because broad invocation rights can expose data, break accountability, and drive uncontrolled cost.
• The critical control failures are separation of duties, identity provenance, and cross-account policy boundaries, not just application-level authorisation.
• Practitioners should treat model invocation as privileged access, with task-scoped permissions and lifecycle governance for every human, workload, and federated identity involved.

Key terms

• Bedrock invocation rights: The permissions that allow an identity to call a foundation model and generate outputs. In identity governance terms, this is a privileged access decision because a single invocation can process sensitive data, create cost exposure, or influence downstream workflows at scale.
• Model customization permissions: The rights that allow an identity to modify or retrain a model through actions such as customization jobs or updates. These permissions affect model state, data provenance, and accountability, so they must be treated separately from ordinary runtime access and governed as high-risk administrative actions.
• Identity provenance: The ability to trace a model interaction back to a verified human, service, or workload identity. Strong provenance links telemetry to an authoritative directory source, which is essential for auditability, incident response, and proving who had access to what in AI-enabled environments.
• Cross-account trust boundary: The policy and identity boundary that controls whether one account can invoke or share resources in another. In AI platforms, this boundary matters because shared inference can widen blast radius, weaken residency controls, and make accountability dependent on policy hygiene rather than technical convenience.

What's in the full article

P0 Security's full post covers the operational detail this post intentionally leaves for the source:

• Permission examples for Bedrock runtime, customization, and management actions that teams can map to their own IAM model
• AWS-specific governance patterns for cross-account invocation and resource-based policies in shared environments
• Practical guidance for linking model invocations back to federated users, service accounts, and workloads in CloudTrail
• Control scoping examples for aligning Bedrock usage with data classification and residency rules

👉 The full P0 Security post covers Bedrock permissions, identity provenance, and cross-account governance in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.