Leaked OpenAI or Anthropic API credentials: what to do in the first hour

What should you do first when an AI API key leaks?

Disable the key straight away, before you investigate anything. A leaked API credential works for anyone who holds it until you switch it off, and every minute it stays live is a minute someone else can run requests on your account.

Anthropic’s Console offers two options on the API keys page: Disable, which can be reversed, and Delete, which is permanent. Anthropic advises disabling or deleting any key you suspect has leaked. OpenAI’s guidance covers the same ground: create a replacement, update your applications, then revoke the old key. When the old key is already public, do the revoking first and accept a short outage.

What is the first-hour checklist?

Work through these steps in order. Most take a few minutes each.

1. Disable or revoke the leaked key. Do this on the vendor’s key page, not in your code. Write down the key’s name and its last-used time first if the dashboard shows them.
2. Create a replacement key. Give it a new name, scope it to one project or workspace, and set an expiry date if the platform offers one. Anthropic lets you choose expiry presets from 3 hours to 30 days when you create a key.
3. Load the new key where your software reads it. That is usually an environment variable or a secrets manager entry. Do not paste it into code, chat or a shared document.
4. Check usage for the leaked key. See the table below for where.
5. Set or lower a hard spend cap. This limits the damage if a second key is also exposed.
6. Find where the key escaped. Search repositories, shared documents, chat channels and build logs.
7. Remove other secrets stored in the same place. One leak often means the whole folder, file or channel was exposed.
8. Write down what happened. Note the time, the key, the cause and the fix, so the next person knows.

Where do you check usage and spend?

Each vendor shows usage per key or per workspace, and each has a limit setting. The table lists where to look.

Task	OpenAI	Anthropic
See usage	Usage page, per key once tracking is on	Usage page in the Console, plus the Usage and Cost API by workspace
Alert on spend	Spend alerts on the limits page (alerts do not stop traffic)	Alerts at set thresholds in each workspace’s spend limits
Hard cap	Hard spend limit per organisation or per project	Spend limit on the Billing page, plus per-workspace limits
Revoke a key	Revoke on the API keys dashboard	Disable (reversible) or Delete (permanent) on the API keys page

OpenAI notes that keys created before 20 December 2023 are not tracked by default, so older keys can show usage as “Untracked” until tracking is switched on. Check that setting if the leaked key is an old one. The details are in OpenAI’s production best practices.

How do you cap spend after a leak?

Set a hard limit on each account so one leaked key cannot run up an unlimited bill. OpenAI’s spend limits guide describes a monthly hard limit for the whole organisation or for a single project. Once tracked spend reaches the limit, affected requests return a 429 error. Enforcement is not instant, so spend can finish slightly above the figure you set.

Anthropic applies a monthly cap by usage tier: $500 on the Start tier, $1,000 on Build and $200,000 on Scale. You can set your own lower limit on the Billing page, and per-workspace limits in the Workspaces page. When a limit you set is reached, requests return an HTTP 400 error until access resumes or you raise the limit.

A hard cap can interrupt real customer traffic, so choose a figure with headroom above your normal month.

How do you find where the key leaked?

Start with the code repository, because that is where most exposed keys turn up. GitHub’s secret scanning checks the full Git history on all branches, plus issues, pull requests, discussions and wikis. It reports secrets from partner providers directly to that provider, which can then revoke them. GitHub’s supported-pattern list includes OpenAI and Anthropic key formats.

Check these places next:

• Config files, .env files and notebooks committed by mistake.
• Chat tools, support tickets and shared documents where someone pasted a key to get help.
• Build and deployment logs that print environment variables.
• Browser code or mobile apps that contain the key directly.
• Laptops and shared servers where a former staff member kept a copy.

Do you need to clean the Git history?

Usually not, once the key is revoked. GitHub says that after you revoke or rotate a secret, the old secret stops working, and rewriting history may not be warranted. GitHub also warns that old commits can stay reachable through clones, forks, cached views and pull requests, and that you cannot remove data from other people’s copies.

The OWASP Secrets Management Cheat Sheet sets out the same order for incidents: revoke the exposed secret, rotate it, then delete it from code, logs and other systems. It also recommends keeping a record of who accessed each secret and when it was last rotated, which makes the next incident faster to work through.

What should change so it does not happen again?

Move keys out of code and into a secrets manager, give each project its own key, and keep spend caps switched on. The companion guide, How to store AI API credentials safely, covers each of these. If someone used the leaked key to pull large volumes of answers from a model, what a distillation attack is explains why that can happen and what it costs.