Because Amazon Bedrock authenticates with standard AWS credentials, there are no Claude API keys to manage — but there is also no separate gate. Any identity in your account with broad permissions can invoke models and generate spend. The good news: everything your organization already knows about IAM applies directly. This article describes the shape of a sane setup; your platform team can translate it into exact policy documents using AWS's current documentation.
Start from what "least privilege" means here
For Bedrock, least privilege has three dimensions. Which models: grant invoke access to the specific Claude models a team actually uses (for example, only anthropic.claude-sonnet-5 for a team that has no Opus workload), rather than wildcard access to every model in the catalog. Which identities: production workloads should invoke Bedrock through IAM roles attached to their compute, never through long-lived access keys copied into config. Which environments: dev, staging, and production get separate roles with separately auditable policies, so an experiment gone wrong in dev cannot touch production quota or spend.
Separate a fourth concern from all of these: the permission to administer model access (enabling models for the account) is an occasional platform-team action and should not be bundled into the policies application workloads use daily.
A three-environment pattern
A setup that scales from pilot to production without redesign looks like this:
Dev: a role that developers and dev workloads can assume, permitted to invoke a small allow-list of Claude models in one region. Keep it slightly generous on models (experimentation is the point) but capped by the account's modest dev quotas so mistakes are cheap.
Staging: a role assumable only by the staging deployment identity, scoped to exactly the models and region production will use. Staging exists to rehearse production, including its permissions — if staging runs with broader access than production, it is not rehearsing anything.
Production: the narrowest policy of the three: the specific models, the specific region(s), attached to the specific compute roles that serve the application. Nothing human-assumable in the normal path. Changes to this policy go through code review like any other production change.
If multiple teams share an account, add a team dimension: per-team roles with per-team model allow-lists. This is also what makes cost attribution and the audit story legible later.
Verify by trying to break it
A policy you have not tested is a hope, not a control. After setup, verify both directions: the application role can invoke the intended model in the intended region, and a deliberately out-of-scope call — a different model, a different region, an invoke attempt from the dev role against production resources — fails. Five minutes with a test script turns "we believe access is scoped" into "we demonstrated access is scoped," which is exactly the sentence your security review wants to hear.
Pair the policies with your audit trail from day one. Bedrock usage appears in your AWS account's audit logging like other service activity, so decide early which log events answer the question "who invoked what, when" — Audit Logging Claude Usage covers building that record.
Keep it boring over time
Review the allow-lists whenever a model generation changes: when a team upgrades from one Claude model to another, add the new ID deliberately and remove the old one after migration, rather than accumulating a fossil record of every model ever tried. Resist the recurring temptation to widen a policy "temporarily" during an incident; widen it with an expiry note and a ticket, or the temporary becomes permanent. None of this is Claude-specific — it is ordinary IAM hygiene, which is precisely why Bedrock is an easy sell to AWS-native security teams.
Where to go next
For the broader platform picture around these policies, read the Bedrock enterprise primer. The same least-privilege thinking generalizes across clouds in Least-Privilege Access for Claude, and the launch checklist shows where access control sits among the other go-live gates.