Leaked Anthropic API key — what now? Delete the key on the API keys page of the Claude Console first. Then check what kind of key it was and which workspace it could reach, read its usage on its own, replace it with a scoped key that expires, put a spend limit on the workspace, rule out an admin credential leaking with it, and contact Anthropic Support if suspicious activity continues. Anthropic's own advice for a key you suspect is compromised is to revoke it immediately1.
Anthropic's key model has changed. A key is now a personal key, a service account key or a legacy workspace key, and each fails differently when it leaks. That is why the second step matters as much as the first.
The first hour at a glance
| When | Step | Where |
|---|---|---|
| Minute 0–5 | Delete the key | Claude Console → API keys |
| 5–15 | Identify key type, owner, workspace scope, expiry | API keys page, Admin API |
| 15–30 | Read usage for that key | Usage page, Logs, Usage and Cost API |
| 15–45 | Replace it where it was deployed | Secret manager, CI, hosts, tools |
| 30–50 | Workspace and organization spend limits | Workspaces, Billing page |
| 45–60 | Admin credentials, members, support | Admin keys page, Members, Help Center |
1. Delete the key
In the Claude Console, open the API keys page (platform.claude.com/settings/keys), click the three dots next to the key and select Delete API key1. The console also offers Disable. The difference matters:
- Disable is reversible: the Admin API reports the key as
inactive, and Re-enable returns it toactive. - Delete is permanent: the key is archived and still appears in List API Keys with
status: "archived"2.
Our reading: for a key you believe someone else holds, delete it. A disabled key can be turned back on by anyone who can manage keys, and in step 6 you may find that an admin credential was exposed too.
Anthropic may have acted already. It is a GitHub secret scanning partner: when GitHub finds a Claude key in a public repository it notifies Anthropic, Anthropic "automatically deactivates the exposed API key", and the affected user receives an email3. GitHub's pattern list covers Anthropic API keys, admin API keys, service account and user API keys and session IDs as partner patterns4, and since 13 October 2026 the two newer key types are blocked by push protection by default, including on free public repositories5. None of that covers a key that leaked from a log, a laptop or a third-party tool. In the OpenCode Console incident, OpenCode told affected users to revoke the keys they had saved there with each provider and replace them6; what OpenCode has said is covered separately.
2. Find out what kind of key it was
The key type decides what an attacker could do with it2:
| Key type | Acts as | Where it works | Stops working when |
|---|---|---|---|
| Personal key | The user who created it, with their roles | One workspace, or every workspace their role allows | The user loses access to the organization (or to that workspace) |
| Service account key | A service account | One workspace, or anything the service account can reach | The service account is archived or removed from the workspace |
| Workspace key (legacy) | No one; it belongs to the workspace | That workspace | It expires, is disabled or deleted, or the workspace is archived |
Two consequences for a leak:
- A personal or service account key that is not scoped to a workspace is accepted by the Admin API, with the same permissions as the linked account7. If the leaked key belonged to an organization admin and was not workspace-scoped, treat it as an admin credential leak and go straight to step 6.
- A multi-workspace key reaches every workspace its identity can. Write down which workspaces those are, because each one's usage is now in scope.
Also note the key's expiry. The Admin API's List API Keys returns each key's expires_at (null for a key with no expiration) and its scope, either one workspace or the organization7.
3. Read the usage for that key
Start with the Usage and Logs pages in the Console, which Anthropic recommends reviewing regularly3. For a per-key view, the Usage and Cost API's /v1/organizations/usage_report/messages endpoint filters and groups by API key, workspace, model and service tier, with 1m, 1h or 1d buckets; data typically appears within five minutes of a request. It needs an Admin API key, or a personal or service account key that is not workspace-scoped8.
curl "https://api.anthropic.com/v1/organizations/usage_report/messages?starting_at=$START&ending_at=$END&api_key_ids[]=$LEAKED_KEY_ID&group_by[]=model&bucket_width=1h" \
-H "anthropic-version: 2023-06-01" \
-H "x-api-key: $ANTHROPIC_ADMIN_KEY"Look for traffic outside the workload's hours, models it never calls, and batch or cache patterns you do not use. Two quirks: Console playground usage has a null api_key_id, and the default workspace appears as a null workspace_id8. Export what you find; you will want it for support.
4. Replace it, narrower than before
Create the new key on the same page with Create key, and store it in a secrets manager, not in version control1. Make it narrower than the one that leaked:
- Give it an expiration. The Console offers 3 hours, 1 day, 7 days, 30 days, a custom duration or Never, and an organization can set a maximum expiration policy that removes Never. Expiration is fixed at creation; an expired key returns
401 authentication_error2. - Scope it to one workspace. Keys are tied to the workspace they are created in and cannot be moved9.
- Use a service account for anything shared or automated. A shared personal key acts as one person and breaks when they leave; Anthropic prefers identity-backed keys over workspace keys for new integrations, and Workload Identity Federation over long-lived keys where the workload already has a platform identity2.
Then replace every copy of the old key: secret manager entries, CI secrets, .env files, developer machines and any third-party tool that held it.
5. Cap the workspace and the organization
A spend limit at Anthropic is the only ceiling that applies to a key used directly against Anthropic.
- Workspace spend limit. Set a monthly limit on each workspace; it must be lower than the organization's, and you can add an email notification at an amount you choose9. You cannot set a spend limit on the default workspace10, which is a reason to keep production keys out of it.
- Organization spend limit. On the Billing page, under Spend limits, set your own limit below your tier's cap. When usage reaches a limit you set, requests return
400 invalid_request_error; when the tier's cap is reached,429withenforced_spend_limit_reacheduntil 00:00 UTC on the first of the next month10. - Workspace rate limits per model, which Anthropic describes as a safeguard "against unexpected usage due to leaked keys or errant scripts"3.
6. Rule out an admin credential
Admin API keys start with sk-ant-admin01-, can be created only by members with the admin role, and carry full access to every endpoint that accepts them, with no selectable scopes11. The Admin API manages members, workspaces, invites and API keys; it cannot create new API keys, but it can read, rename and change the status of existing ones7. That is why a disabled key is not enough if an admin credential is exposed.
If the leak came from somewhere that also held an admin key, or an admin's unscoped personal key, delete that credential too, then check members, invites, workspaces and keys created during the exposure window. Least privilege for provider admin keys covers how to hold one safely.
7. Contact Anthropic Support
If suspicious activity continues after revocation, or you have other concerns, contact the support team through the link in Anthropic's compromised-key article1. Anthropic's Commercial Terms make the customer "responsible for all activity under its account" and require it to "promptly notify Anthropic" if it believes the account has been compromised12. Send the key ID, workspace, time window in UTC and the usage export. Whether any charges are adjusted is Anthropic's decision; stolen API key charges explains what the terms say.
How INFRO handles a leaked Anthropic key
If your Anthropic key is connected to INFRO, replace the credential on the connection after you rotate it at Anthropic. INFRO seals provider keys with AES-256-GCM, never shows them again, and uses the new one from the next request; replacing it in INFRO does not revoke the old key at Anthropic (see Connect a provider). Your applications use INFRO gateway keys instead of the Anthropic key, so a leaked application credential is an INFRO key you can revoke or rotate with an overlap window, limit to IP ranges, providers and one environment, and cap with budgets checked before Anthropic is called. Key changes are recorded in the audit log.
INFRO's controls govern traffic that goes through INFRO. A copy of the Anthropic key itself, leaked from anywhere, including from a platform like INFRO that holds it, can be used directly against Anthropic, and no INFRO budget or allowlist sees that request. Steps 1, 5 and 7 happen at Anthropic for that reason. On the Business plan, with usage access on, reconciliation compares Anthropic's own usage per key with the traffic that passed through INFRO, which can show use of your key that bypassed the gateway.
Summary
Delete the key, then let its type tell you how far the leak reaches: personal keys act as a person, and unscoped ones can reach the Admin API. Read usage for the key alone, replace it with a workspace-scoped key that expires, cap the workspace and the organization at Anthropic, rule out an admin credential, and report what you found.