In IAM terms, an identity-based policy is attached to a user or role and says what that identity may do. A resource-based policy is attached to the resource itself and says who may use it — including principals from other AWS accounts. S3 bucket policies are the familiar example: the bucket owner writes a policy naming an outside account, and that account's identities can access the bucket directly, no role assumption required. The question for this article is how far that pattern extends to Claude on Bedrock.
The key fact: foundation models aren't your resources
The Claude foundation models on Bedrock are AWS-operated resources with account-less ARNs — arn:aws:bedrock:*::foundation-model/{model-id} (note the empty account field). You don't own them, so you cannot attach a resource-based policy to anthropic.claude-sonnet-5 and share "the model" with another account the way you'd share a bucket. Access to invoke a foundation model is granted through identity-based policies (and bounded by SCPs) in the account where the call is made, using actions like bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:Converse, and bedrock:ConverseStream.
What you do own are the Bedrock resources created in your account — inference profiles (arn:aws:bedrock:{region}:{account-id}:inference-profile/*), provisioned models (arn:aws:bedrock:{region}:{account-id}:provisioned-model/{name}), and similar. Resource-based policy support varies by Bedrock resource type and changes over time, so before designing around it, check the current Amazon Bedrock user guide and the IAM documentation for the specific resource you want to share. Where a resource type doesn't support attached policies, cross-account sharing simply isn't available on that axis.
Comparing the two cross-account mechanisms
| Aspect | Resource-based policy | Role assumption |
|---|---|---|
| Where policy lives | Attached to the shared resource | Trust + permissions policy on a role in the target account |
| Caller identity | Caller keeps its own identity | Caller becomes the assumed role |
| Works for Bedrock foundation models | No — models are AWS-owned; use identity policies | Yes — assume a role where invocation is permitted |
| Audit trail | Calls logged under the caller's account identity | CloudTrail shows the assumed-role session |
If you do use resource-based policies, keep them defensive
Where a Bedrock-adjacent resource supports an attached policy, the same hygiene applies as for any cross-account grant: name specific principal ARNs rather than whole accounts where possible; grant only the actions the consumer needs (for inference-adjacent resources that means the narrow invoke actions, never bedrock:*); and add conditions to constrain context. Pair the grant with monitoring — CloudTrail captures Bedrock API calls including caller identity and source IP, so cross-account usage of your resources is visible in the resource-owning account's logs. And remember SCPs in either organization still apply on top: a grant in your policy can be nullified by a deny in the caller's org, which is a feature, not a bug.
One more boundary worth stating: VPC endpoint policies (covered in Bedrock VPC endpoint policies) look similar — a policy document attached to a thing that isn't an identity — but they constrain what traffic may transit a network endpoint, not who owns access to a resource. Use them together, not interchangeably.
Where to go next
For the pattern most enterprises actually deploy, read cross-account role assumption, then multi-account Bedrock setup for where each mechanism fits in an AWS Organization.