What you will be able to do
- Choose where a Claude API key should live in local development, cloud deployments and third-party tools
- Limit a key's blast radius with per-environment keys, rotation and creation-time expiration
- Name the signals Anthropic and your own tooling give you for monitoring authorized key use
- Respond to a suspected leak, knowing which Console actions are reversible and which are not
Key concept
An API key is a bearer credential for your account — Whoever holds a static Claude API key can act, and spend, as your account. Every practice in this lesson reduces one of three things: where the key can be read, how long it keeps working, and how long misuse goes unnoticed.
1.Where a key should live in each environment
Anthropic names the most common way keys escape: they get committed to public repositories or pasted into third-party tools. The fix is to keep the key out of source code completely and supply it at runtime. The Claude SDKs are designed for exactly this. If ANTHROPIC_API_KEY is set in the environment, you can build a client with no arguments, and the key never appears in a file you might commit.
client = Anthropic(api_key="my-anthropic-api-key")
# or, with ANTHROPIC_API_KEY set in the environment:
client = Anthropic()The value still has to come from somewhere, and where it comes from depends on the environment. On a laptop, a .env file loaded with python-dotenv works, provided the file is listed in your ignore file. In the cloud, Anthropic recommends encrypted secret storage over dotenv files: your provider's secret manager injects the key as an environment variable. A web IDE or CI/CD platform needs the same treatment, because uploading your key gives that tool's developer access to your Console account. Add it there as an encrypted secret, and only if you trust the vendor.
| Environment | Recommended source of the key | What to avoid |
|---|---|---|
| Local development | .env file loaded with python-dotenv, listed in .gitignore | Committing the .env file |
| Cloud deployment | The cloud provider's secret management, passed in as an environment variable | dotenv files in place of encrypted secret storage |
| Third-party tool (web IDE, CI/CD platform) | An encrypted secret in that tool | The key written directly into code or configuration files |
| Many keys and secrets across an organization | A Key Management System (KMS) | Secrets scattered across unrelated stores |
Once an organization holds many secrets, a KMS keeps them all in one encrypted place. It also adds fine-grained control over who can view or use each key, audit trails of access and changes, and easy rotation. Those last two features come back later in this lesson.
Sources1
2.Limiting how long a leaked key keeps working
Storing a key well makes a leak less likely. The next set of controls limits the damage when one happens anyway. First, use separate keys for development, testing and production. Usage can then be traced to each use case, and a compromised key can be disabled for that one use case while the others keep running. Second, rotate on a regular schedule, for example every 90 days: create a new key, move callers to it, and deactivate the old one.
Third, set an expiration when you create the key. The Console offers presets of 3 hours, 1 day, 7 days or 30 days, a custom duration, or Never. Never is meant for keys you keep in a secrets manager and rotate yourself. If your organization has a maximum expiration policy, the Console caps the choices at that maximum and Never is unavailable. Once a key expires, requests using it return a 401 authentication_error, and the key cannot be reactivated. You have to create a new one.
| Key lifetime at creation | Warning email |
|---|---|
| At least 14 days | 7 days before expiration |
| At least 7 days | 1 day before expiration |
| Shorter than 7 days | None: the key expires without a warning email |
3.Monitoring authorized access
Separate keys per environment also make monitoring possible. When usage looks wrong, you can tell which workload it came from. Anthropic recommends regularly reviewing each key's logs and usage patterns in the Console. It also recommends setting financial limits, so a leaked key or a runaway script cannot spend without bound. Which setting provides that limit depends on your organization's rate-limit tier.
| Control | Where it runs | What it catches or limits |
|---|---|---|
| Log and usage-pattern review | Claude Console | Unexpected activity on a specific key |
| Usage and spend limits (Custom Rate Limit orgs) | Account settings | Unexpected usage from leaked keys or errant scripts |
| Auto-reload limits (Standard Rate Limit orgs) | Account settings | Unexpected high usage from leaked keys or code mistakes |
| Secret scanning and SAST tools such as Gitleaks | Source control provider and CI/CD pipeline | Secrets committed to a repository, caught before they are pushed to the main branch |
| GitHub Secret scanning partner program | Public GitHub repositories | Exposed Claude API keys, which Anthropic then deactivates |
| KMS audit trails | Your Key Management System | Every access to and change of a stored secret |
The GitHub partnership catches leaks that your own scanning misses. When a Claude API key turns up in a public repository, GitHub notifies Anthropic, Anthropic automatically deactivates the key, and the affected user gets an email explaining what happened. To audit expiry, the Console's API keys table shows each key's expiration, and the Admin API reports an expires_at timestamp on List API Keys and Retrieve API Key. That timestamp is null for keys that never expire, so you can find and rotate keys before they lapse.
A compliance auditor asks an engineering team to produce evidence of which Claude API keys are nearing expiration across all workspaces, so stale credentials can be rotated proactively before they lapse. Which action retrieves this information programmatically?
Correct answer: A — Call the Admin API's List API Keys endpoint with an Admin API key and inspect each returned key's `expires_at` timestamp, treating a `null` value as a key with no expiration.
- A. Correct. The Admin API's List API Keys endpoint returns each key's expires_at timestamp directly (null for keys without an expiration), which is exactly the audit signal needed.
- B. Incorrect. The Compliance API's Activity Feed logs events but does not report expiration timestamps, and 30 days is not a fixed or reliable default expiration to assume.
- C. Incorrect. Usage and cost data reflects consumption, not credential lifecycle; a zero-cost line item has no relationship to key expiration.
- D. Incorrect. Rate limits are not automatically tied to a key's expiration status; the Rate Limits API has no such behavior.
4.Responding to a suspected compromise
If you think a key has leaked, the guidance is to revoke it immediately. Open the API keys page from your profile in the Claude Console, click the meatball menu next to the key, and choose Delete API Key. Then create a replacement with Create Key, store it in a secrets management system rather than version control, and contact Support if suspicious activity continues. The Console also has a softer option, and the difference between the two matters in an exam question:
| Action | Can it be undone? | Resulting status |
|---|---|---|
| Disable | Yes: Re-enable returns the key to "active" | "inactive" in the Admin API |
| Delete | No: permanent | "archived"; the key still appears in List API Keys |
| Expiration | No: expired keys cannot be reactivated and can only be deleted | Requests return 401 authentication_error |
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.When a key is about to expire, you can extend its expiration instead of rotating it.Why is that wrong?
Expiration is fixed when the key is created and cannot be changed afterward. An expired key cannot be reactivated either, so the only path is to create a new key.
Covered in Limiting how long a leaked key keeps working
2.A Claude API key pushed to a public GitHub repository stays usable until you notice and revoke it yourself.Why is that wrong?
Through GitHub's Secret scanning partner program, GitHub reports the exposed key to Anthropic, which deactivates it automatically and emails the affected user.
Covered in Monitoring authorized access
3.Deleting a key is a safe precaution because you can restore it if the leak turns out to be a false alarm.Why is that wrong?
Only Disable can be undone, with Re-enable. Delete is permanent: the key is archived and stays visible in List API Keys, but it never works again.
Covered in Responding to a suspected compromise
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://support.claude.com/en/articles/9767949-api-key-best-practices-keeping-your-keys-safe-and-secureOfficial docs
“One of the most frequent causes of API key leaks is accidental exposure in public code repositories or third-party tools.”
↩︎ Where a key should live in each environment“you must add your .env files to your source control ignore file”
↩︎ Where a key should live in each environment“always add your API key as an encrypted secret”
↩︎ Where a key should live in each environment“A KMS provides a centralized solution for storing, accessing, and managing secret keys, including API keys.”
↩︎ Where a key should live in each environment“use different API keys for development, testing, and production environments”
↩︎ Limiting how long a leaked key keeps working“Regularly rotate your API keys on a consistent schedule (for example, every 90 days) by creating new ones and deactivating old ones.”
↩︎ Limiting how long a leaked key keeps working“We recommend regularly reviewing logs and usage patterns for your API keys within the Console.”
↩︎ Monitoring authorized access“Integrate secret scanning into your CI/CD pipeline to catch any secrets before they are pushed to the main branch”
↩︎ Monitoring authorized access“Much like a credit card number, if someone obtains and uses your API key, they incur charges on your behalf.”
↩︎ Key concept“To prevent potential abuse, Anthropic automatically deactivates the exposed API key.”
↩︎ Exam trap 2 - 2.
“Expiration limits the lifetime of a leaked credential, but it is not a substitute for secret hygiene.”
↩︎ Limiting how long a leaked key keeps working“so you can audit and rotate keys before they expire”
↩︎ Monitoring authorized access“Expired keys can only be deleted.”
↩︎ Responding to a suspected compromise“expiration is set at creation time and cannot be changed afterward”
↩︎ Exam trap 1“On the API keys page, Disable is reversible”
↩︎ Exam trap 3 - 3.https://support.claude.com/en/articles/8384961-what-should-i-do-if-i-suspect-my-api-key-has-been-compromisedOfficial docs
“If you suspect that your API key may be compromised, we recommend revoking the key immediately.”
↩︎ Responding to a suspected compromise