Guide · Keys
Your API key leaked. Do this in the first 10 minutes.
This covers an OpenAI, Anthropic, or OpenRouter key. The only action that stops a copied key is the provider turning it off. Do that before you look for the leak.
Published . The longer checklist is the leaked-key guide.
1. Revoke it at the provider
Deleting the variable in your app, your host, or a chat transcript does not kill the key. Whoever copied it can keep calling the API until the provider deletes or disables that key.
OpenAI
Delete the project API key in the OpenAI dashboard, or with an organization admin key call DELETE /v1/organization/projects/{project_id}/api_keys/{api_key_id}. Deletion is permanent. A service-account key can be rejected by that endpoint. [1]
Anthropic
Disable the key in the Claude Console. Disable sets it inactive and can be turned back on. Delete archives it and is permanent. An organization Admin API key can call POST /v1/organizations/api_keys/{id} with {"status": "inactive"}. Individual console accounts cannot use that Admin API. [2] [3]
OpenRouter
Disable the key. Disabling is reversible. Archiving is permanent. A management key can call PATCH /api/v1/keys/{hash} with {"disabled": true}. [4]
In October 2026 a hosting breach went after AI provider keys stored in customer environment variables. If a key lived on a host like that, revoke it at OpenAI, Anthropic, or OpenRouter. Removing it from the host is not enough. The dated checklist is the Railway breach guide. [5]
2. Rotate
Create a new key after the old one is off. Put that new key only in the service that needs it. One key per app means the next leak names the app. Do not paste the new secret into the same ticket, repo, or chat where the old one appeared.
3. Check usage
Look at usage grouped by key for the days you think the key was exposed. You want to know whether the key was called, not just whether it was copied. The leaked-key guide has the provider-by-provider review. This page does not add a click-path the provider docs do not spell out.
4. Set a limit on the replacement
Revoking stops the copied key. A limit is what keeps the next key from running all night. OpenAI and Anthropic limits are monthly and sit on a project, organization, or workspace. OpenRouter can set a daily limit on the key itself. The daily budget guide and the Anthropic spend limit guide cover those controls. A limit that only emails you does not stop traffic.
Then put a daily cap on it
BillCurfew watches spend per key and emails you when a daily cap or a spike rule trips. A manual kill works on every plan, including Free. On OpenAI that kill deletes the key and cannot be undone. On Anthropic and OpenRouter it disables the key and can be turned back on. Auto-kill is paid-only and stays off until you turn it on. The check runs about every five minutes, so it does not replace the revoke you just did, and it is not a proxy.
Start free with one key, no card.
FAQ
Does deleting the key from my app stop the charges?
No. A copied key keeps working at the provider until that provider deletes or disables it. Removing it from a repo, a host, or a .env file only stops new deploys from using that copy.
Can I turn an OpenAI key back on after I delete it?
No. Deleting an OpenAI project API key is permanent. Create a new key. Anthropic disable and OpenRouter disable can be turned back on.
Does a spend limit replace revoking the key?
No. A limit can reduce further spend. It does not prove the copied key is dead. Revoke first, then set the limit on the replacement.
Sources
- OpenAI, Delete a project API key. https://developers.openai.com/api/reference/resources/admin/subresources/organization/subresources/projects/subresources/api_keys/methods/delete
- Anthropic, Authentication. https://platform.claude.com/docs/en/manage-claude/authentication
- Anthropic, Update an API key. https://platform.claude.com/docs/en/api/organization/api_keys/update
- OpenRouter, Update an API key. https://openrouter.ai/docs/api/api-reference/api-keys/update-an-api-key
- Railway, Preliminary Report: Oct 21st Security Incident. https://blog.railway.com/p/preliminary-report-october-security-incident