Anthropic's authentication documentation is blunt about first-party API keys: they are long-lived sk-ant-api... secrets with no expiry, and the guidance is to store them in a secrets manager, rotate them periodically, and revoke them on suspected leak. A .env file on a server satisfies none of that — it has no access audit trail, no rotation story, and a tendency to get copied into backups, images, and repos. This article covers the three patterns that do satisfy it, in ascending order of maturity.
Pattern 1: env vars injected by the platform (good)
The SDKs read ANTHROPIC_API_KEY from the environment automatically, so the minimum-change improvement over an env file is to have your platform populate that variable from its secret store at start time: Kubernetes Secrets, an ECS task definition referencing AWS Secrets Manager, or your CI system's encrypted variables (see CI/CD secret injection). Application code stays a one-liner — Anthropic() — and the secret's storage, access control, and audit live in the manager. One sharp edge to know: in the SDK's documented credential-resolution order, an environment variable set to an empty string still occupies its slot, so ANTHROPIC_API_KEY="" means "authenticate with an empty key," not "fall through to the next method." Unset unused variables; don't blank them.
Pattern 2: fetch from the manager in code (better for some estates)
Some organizations prefer the application to pull its own secrets — it avoids secrets sitting in process environments (visible to anything that can read /proc or crash dumps) and lets the app re-fetch after a rotation without a restart. All three major managers — AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault — expose a straightforward "get secret value" call through their own SDKs, authenticated by the workload's cloud identity (an IAM role, service account, or managed identity), so no bootstrap secret is needed to fetch the Claude key.
The Claude SDK side is a documented constructor argument, which sits first in the credential precedence order:
from anthropic import Anthropic
def fetch_claude_key() -> str:
"""Read the key from your secrets manager using its own SDK
(AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault),
authenticated by the workload's cloud identity."""
...
client = Anthropic(api_key=fetch_claude_key())
Fetch once at startup (or on a cache-with-TTL), not per request — secrets managers are control-plane services with their own quotas and latency. Never log the value, never include it in error messages, and treat any exception text from the fetch path as potentially sensitive.
Pattern 3: no static secret at all (best)
The strongest pattern removes the long-lived key from the picture entirely.
First-party API: Workload Identity Federation (WIF) exchanges your workload's IdP-issued identity token for a short-lived Claude API access token, refreshed automatically by the SDK. Anthropic recommends it for production workloads on cloud platforms, CI/CD, and Kubernetes, and it works with AWS IAM, Google Cloud, and any standards-compliant OIDC issuer.
Third-party platforms: identity-based auth is the default. Amazon Bedrock (AnthropicBedrockMantle) and Claude Platform on AWS (AnthropicAWS) sign requests with standard AWS credentials from the default provider chain; Vertex AI (AnthropicVertex) uses Google Application Default Credentials. In these setups "secrets handling" collapses into IAM policy — there is no Claude key to store, fetch, or rotate. Microsoft Foundry is the exception in this list: AnthropicFoundry takes a resource-scoped API key, which should live in Key Vault under patterns 1 or 2.
| Pattern | Secret at rest? | Rotation effort | Best for |
|---|---|---|---|
| Platform-injected env var | In the manager | Redeploy or restart | Most teams, fastest path |
| In-code fetch from manager | In the manager | Re-fetch, no restart | Long-running fleets, strict env hygiene |
| WIF / cloud identity | None | None (auto-expiring) | Production on any major cloud |
Where to go next
Plan the rotation mechanics in rotating API keys without downtime, see the keyless flow in detail in Workload Identity Federation, and keep container images clean with the containerization guide.