Hardcoded credentials remain one of the most common and most preventable security failures in software. The pattern is always the same: a key is pasted into code "just for testing," committed, copied into a fork, cached by a scanner, and discovered by someone unfriendly long after everyone forgot it was there. For Claude on third-party platforms, the fix comes in two tiers: eliminate the secret entirely where the platform allows it, and manage it properly where it doesn't.
Tier one: no secret at all (workload identity)
Three of the four platforms authenticate with your cloud's native identity machinery rather than a standalone API key. On Amazon Bedrock, the client uses standard AWS credentials — which in production means an IAM role your compute assumes at runtime, delivering short-lived credentials automatically. On Google Vertex AI, the client uses Application Default Credentials (ADC): a service account identity that your workload picks up from its environment. On Claude Platform on AWS, requests are signed with AWS SigV4 using the same ambient AWS credentials, plus two configuration values (AWS_REGION and ANTHROPIC_AWS_WORKSPACE_ID) that are settings, not secrets. In all three cases there is no long-lived key for a developer to paste anywhere:
from anthropic import AnthropicBedrockMantle
# No key in code: the client picks up ambient AWS credentials
# (an IAM role in production, your AWS profile in development).
client = AnthropicBedrockMantle(aws_region="us-east-1")
response = client.messages.create(
model="anthropic.claude-haiku-4-5-20251001-v1:0",
max_tokens=256,
messages=[{"role": "user", "content": "Tag this email by department."}],
)This is worth saying plainly: workload identity is not just more convenient, it is structurally safer. Credentials are short-lived, issued to the machine rather than typed by a person, rotated by the platform, and revoked by deleting a role binding rather than by hunting down every copy of a string.
Tier two: managing keys you can't avoid
Microsoft Foundry authenticates with an API key tied to your Foundry resource, so there is a real secret to protect. The rules are standard and non-negotiable. Store it in a secret manager — every major cloud has one — and grant read access only to the identities that run the workload. Deliver it to the application at runtime, via the environment or a direct secret-manager fetch; never bake it into an image or a config file in the repository. Use different keys for different environments, so revoking a compromised dev key cannot take down production. The same rules apply to any other secrets in your Claude stack: database credentials your tools use, tokens for systems your tool-use integrations call, and keys for the first-party Claude API if you use it alongside a 3P platform.
Rotation, and rehearsing it
Rotation means replacing a credential on a schedule so that a silent leak has an expiry date. With workload identity you get this for free. For API keys, set a calendar-driven rotation cadence and — more important — make rotation boring: if replacing a key requires code changes or a deployment freeze, it will not happen. The test of a healthy setup is that you can rotate the Foundry key in minutes, without a code change, because the application reads it from the secret manager at startup. Rehearse it once before you need it under pressure.
The developer-laptop question
Local development is where discipline usually slips. Keep it safe with the same pattern at lower stakes: developers authenticate as themselves through the cloud CLI (which supplies ambient credentials to the SDK), dev-only keys live in untracked local env files, and nothing production-scoped ever exists on a laptop. If a developer cannot tell you where their Claude credential came from, that is the finding.
Where to go next
Credentials decide who can call Claude; scoping decides what they can do — continue with Least-Privilege Access for Claude. For the details of ADC on Google Cloud, see Application Default Credentials for Claude on Vertex AI, or start from the quickstart.