Least privilege is the old, boring, correct idea that every identity should be able to do exactly what its job requires and nothing more. Applied to Claude on a third-party platform, it means model invocation is a permission you grant deliberately — to specific applications, in specific environments, for specific models — rather than a side effect of broad cloud access. This matters for three practical reasons: model calls cost real money per token, prompts and responses often carry sensitive data, and when something goes wrong you want the set of possible callers to be short.
The three-axis pattern
Scope every grant along three axes. By team or workload: each application or team gets its own identity (a service account, role, or resource), so usage, cost, and incidents attribute cleanly. Shared credentials are the enemy of every later question you will ask. By environment: development, staging, and production live in separate accounts or projects with separate identities. Production identities are held by deployed services, not people; developers get generous access in dev and none in prod. By model: where the platform allows it, grant invocation for the specific model IDs a workload uses. A ticket-classification service that runs on Claude Haiku 4.5 has no reason to be able to invoke Claude Opus 4.8 at five times the input price; a scoped grant turns a costly misconfiguration into a visible permission error.
How the pattern maps to each platform
The vocabulary differs; the pattern does not. On Amazon Bedrock, access is standard AWS IAM: policies attached to roles grant model invocation, and you scope them to the actions and model resources a workload needs. On Google Vertex AI, access rides on IAM roles granted to service accounts within a project, which makes per-environment projects the natural isolation boundary. On Claude Platform on AWS, calls are signed with AWS SigV4 and associated with a workspace via ANTHROPIC_AWS_WORKSPACE_ID, so the same AWS identity discipline applies, with workspaces as an additional grouping lever. On Microsoft Foundry, access is mediated by the Foundry resource and its API keys — which shifts the burden toward key handling: separate resources per environment, keys stored in a secret manager, and rotation on a schedule.
In every case, prefer workload identity (roles, service accounts, ambient cloud credentials) over long-lived secrets wherever the platform supports it. An identity that a machine assumes at runtime cannot be committed to a repository.
The failure modes this prevents
Concretely: an engineer's experiment running against production quota and starving the customer-facing app (separate identities and environments prevent it); a leaked credential that can invoke any model in any account (scoping caps the blast radius); an internal tool quietly upgraded to an expensive model without review (the permission error forces the conversation); and the unanswerable audit question "which system sent this data to the model?" (per-workload identities answer it by construction). None of these are exotic — they are the default outcomes of shared, broad access.
Keeping it least-privilege over time
Access control decays without maintenance. Three habits keep it honest. Review grants on a schedule — quarterly is plenty — and remove identities for retired workloads. Watch your audit logs for identities that never call the model (dead grants to prune) and for identities calling models outside their expected pattern (either a policy gap or a problem). And make new-workload onboarding a paved road: a template that stamps out a scoped identity per team, per environment, per model takes an afternoon to build and removes the temptation to share credentials because it is Friday and the demo is Monday.
Where to go next
For concrete AWS policy construction, continue with Setting Up IAM Permissions for Claude on Bedrock. Scoped identities only pay off if usage is recorded — pair this article with Audit Logging Claude Usage, and see the full launch checklist.