Who is accountable when Bedrock access crosses accounts or regions?

Why This Matters for Security Teams

Cross-account or cross-region Bedrock access is not just an IAM routing question. It is an ownership question: who can approve the action, who can prove the workload’s identity, and who is responsible when that access is abused or mis-scoped. In NHI programs, this is where governance often weakens because CloudTrail can show activity, but it does not by itself establish trustworthy ownership or intent. The operational risk is amplified by the fact that NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which broadens the blast radius when cross-boundary access is granted too freely.

The core issue is that account boundaries and region boundaries are administrative constructs, while Bedrock workloads behave like distributed identities that may invoke models, tools, and downstream services from more than one place. That means accountability must follow the verified identity and its policy envelope, not the network path alone. Current guidance from OWASP Non-Human Identity Top 10 treats weak identity lifecycle and privilege governance as primary failure modes, and that maps directly to Bedrock cross-account use. In practice, many security teams only discover the ownership gap after a cross-account invocation has already been approved and logged, rather than through intentional design.

How It Works in Practice

Accountability for cross-account or cross-region Bedrock access should be assigned across three control points: the identity owner, the platform owner, and the policy owner. The identity owner is responsible for the workload identity itself, including its registration, rotation, and revocation. The platform owner manages the AWS boundary where Bedrock is consumed, including trust relationships, service control policies, and logging. The policy owner defines the runtime rules that decide whether a request is allowed, ideally using policy-as-code rather than ad hoc approvals.

Practically, that means the Bedrock request should be mapped back to a verified directory or workload identity before access is treated as attributable. If a role assumption, federated token, or service identity cannot be tied to a named workload and owner, then the access log is operationally useful but not sufficient for governance. This is consistent with the identity-first model described in Ultimate Guide to NHIs — Key Challenges and Risks, where visibility and lifecycle control are presented as prerequisites for defensible accountability.

• Use distinct workload identities per application, environment, and business function.
• Require explicit cross-account trust with short-lived credentials and clear owner metadata.
• Log the assumed role, source identity, and policy decision together, not in separate silos.
• Review who can update the trust policy, since that is often where accountability is lost.

For implementation, align the request path with runtime authorisation concepts from the Amazon Bedrock IAM security guidance and pair that with identity governance controls from CISA Zero Trust Maturity Model so the decision is both attributable and reviewable. These controls tend to break down when organisations reuse a shared role across multiple accounts and regions because the original owner becomes impossible to distinguish from downstream operators.

Common Variations and Edge Cases

Tighter cross-account controls often increase operational overhead, requiring organisations to balance auditability against deployment speed and regional flexibility. That tradeoff is real, especially when Bedrock workloads span dev, test, and production accounts or when a model invocation in one region triggers tools in another.

One common edge case is delegated administration, where a central platform team manages the trust boundary but a product team owns the workload. In that model, accountability is shared, but it must still be explicit. Another common exception is emergency access, where temporary cross-account permissions may be granted for incident response. Best practice is evolving here, but current guidance suggests those grants should be time-bound, fully logged, and tied to a named incident owner rather than a standing privileged role.

Region hopping also creates attribution problems when logs are fragmented or when different accounts use different tag standards. The answer is not to assume the nearest CloudTrail record is sufficient. It is to enforce identity provenance end to end, then keep the policy owner separate from the platform operator so changes to trust do not silently change accountability. If Bedrock access is mediated through unmanaged service accounts or loosely governed automation, the accountability model becomes weak very quickly, especially as cross-region replication and failover increase the number of valid execution paths.

For broader NHI governance context, 52 NHI Breaches Analysis is useful for understanding how frequently identity ambiguity shows up after the fact, rather than during design.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access crosses IT, cloud and OT boundaries?
• Who is accountable when sustained infrastructure attacks disrupt access and availability?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• Who is accountable when cloud access expires on paper but persists in practice?