API Key and Secret Security

An Anthropic API key is a bearer credential: anyone who holds it can spend your money and act as your organisation. Treating it like a password is the minimum; treating it like a production secret with scoping, rotation and monitoring is the expectation. The exam tests both the hygiene rules and the Console features that limit blast radius.

Where a key must never be

• Client-side code. Browser bundles, mobile apps, desktop apps and anything a user can inspect. Every call from a user device must go through a backend you control (lesson 2-6).
• Source control. Not in code, not in committed .env files, not in example configs with a "real" value, not in notebooks.
• Logs and error messages. Redact headers before logging requests; the SDKs do not print keys, but your own middleware might.
• Chat messages, tickets and screenshots. Keys shared "temporarily" live forever in search indexes.
• URLs or query strings. The API expects the key in the x-api-key header; never put secrets in URLs, where proxies and access logs capture them.

Where a key should live

Load it from the environment at runtime, and let the SDK pick it up with a zero-argument client:

client = anthropic.Anthropic()   # ANTHROPIC_API_KEY from the environment

In production, the environment is populated from a secret manager (cloud provider secret stores, Vault, or your platform's encrypted secrets) rather than from a file on disk. For local development, keep .env files git-ignored and distinct from production values. Add a secret scanner to CI and pre-commit hooks so an accidental commit is caught before it is pushed.

Scoping with workspaces

Workspaces are sub-divisions of an organisation in the Console. Each workspace has its own API keys, its own usage reporting, optional rate-limit allocation and its own spend limit. Use them to separate:

• environments: development, staging, production;
• products or teams that should be billed and limited independently;
• a customer-facing feature from an internal batch job, so a runaway script cannot starve the live service.

Keys are shown once at creation, can be named for traceability, and can be disabled or deleted individually without touching others. Prompt caches are also scoped per workspace, which is a side effect worth knowing.

Limits as a safety net

Set a monthly spend limit per workspace so a leaked or misbehaving key cannot run up an open-ended bill. Combine it with rate-limit allocation so one workspace cannot consume the organisation's full quota. Review usage dashboards by key; an unfamiliar spike on a key is the earliest signal of compromise.

Admin API keys are different

Keys prefixed sk-ant-admin are organisation management credentials for the Admin API: creating workspaces, inviting members, managing keys and reading usage and cost reports. They cannot call the Messages API and ordinary keys cannot call the Admin API. Keep admin keys in a separate, more restricted secret store with fewer readers.

Rotation

Rotate on a schedule and immediately on any suspicion. Because keys can be created and disabled independently, rotation is zero-downtime:

1. Create the new key in the same workspace.
2. Deploy it to the secret manager; roll services.
3. Confirm traffic on the new key in the usage dashboard.
4. Disable, then delete, the old key.

Automate it where you can; a quarterly manual chore is forgotten, a pipeline is not.

When a key leaks

Act in this order: disable the key in the Console (seconds), create and deploy a replacement, review usage on the compromised key for the exposure window, purge the secret from git history if it was committed (rewriting history is required; deleting the file in a new commit is not enough), and record the incident. If the key was in a public repository, assume it was harvested within minutes.

Identity beyond static keys

For workloads on cloud platforms, prefer the platform's identity system: Bedrock, Vertex AI and Foundry authenticate with IAM roles or service accounts rather than an Anthropic key. The Claude Developer Platform also supports workload identity federation, exchanging a short-lived cloud identity token for API access so no long-lived secret exists at all. Where available, short-lived credentials beat static keys.

Exam focus

• API keys belong only on servers you control, loaded from the environment or a secret manager; never in client code, repositories, logs or URLs.
• Workspaces isolate keys, usage, spend limits and rate limits per environment or team.
• Spend limits and per-key usage monitoring cap the damage from a leaked or runaway key.
• Admin API keys (sk-ant-admin...) manage the organisation and cannot call the Messages API; ordinary keys cannot call the Admin API.
• Rotation is zero-downtime: create new, deploy, verify, disable old; on a leak, disable first and rewrite git history if committed.
• Cloud platforms and workload identity federation replace static keys with platform identity or short-lived tokens.