Your OpenAI API key leaked — do these 6 things now

Revoke the key first. Everything else can wait. Deleting the commit, rewriting history, and working out how it happened are all secondary — a key stays live until you revoke it at the provider, no matter what you do to the file it was in.

Go to platform.openai.com/api-keys, find the key, and delete it. Then work through the rest of this page in order.

1. Revoke the key

At platform.openai.com/api-keys, find the key by its last four characters and delete it. If you have several and can't tell which leaked, delete all of them — reissuing is a five-minute job, and an unrevoked key is an open tap.

If the key belongs to a project rather than your personal account, it's under Settings → Project → API keys, and you'll need to be an owner of that project.

If you'd rather do it from the terminal, with an admin key:

# list every project
curl https://api.openai.com/v1/organization/projects?limit=100 \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

# list keys in a project
curl https://api.openai.com/v1/organization/projects/$PROJECT_ID/api_keys?limit=100 \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

# delete one
curl -X DELETE \
  https://api.openai.com/v1/organization/projects/$PROJECT_ID/api_keys/$KEY_ID \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

See how to create an OpenAI admin key if you don't have one.

Once the key is deleted, every service using it starts returning 401. That includes your own production app — which is the point, and why step 2 is what it is.

2. Issue a replacement and redeploy

Create a new key at the same URL. Then, in this order:

1. Put the new key in your secret store — environment variables in your host's dashboard, AWS Secrets Manager, Doppler, 1Password, whatever you use. Not in a file in the repo.
2. Deploy.
3. Confirm the app works on the new key.

If you have a running production service and can tolerate a few minutes of exposure, you can invert steps 1 and 2 of this whole page: create the new key, deploy it, verify, _then_ revoke the old one. That's the zero-downtime path. It is only correct if you're confident the leak is recent and low-traffic. If the key has been public for more than a few minutes, revoke first and take the outage.

3. Check for unauthorised usage

Now find out whether anyone used it. Go to platform.openai.com/usage and look at the daily cost chart for the period since the key was exposed.

What you're looking for:

• A spike on a day you weren't shipping. The clearest signal.
• Models you don't use. Abuse traffic frequently targets the most expensive model available, because the point is free access to a frontier model.
• Usage at hours you were asleep. Attack traffic doesn't keep your working hours.
• A project or key with usage you can't account for.

Programmatically, the Costs endpoint gives you daily buckets:

curl "https://api.openai.com/v1/organization/costs?start_time=1717200000&limit=31" \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

start_time is a Unix timestamp. Full details in the OpenAI Costs endpoint, explained.

4. Cap the damage

Whatever the usage looks like, do these now — they limit the blast radius of the _next_ leak as much as this one:

• Turn off auto-recharge. This is the single most expensive setting in an incident. With auto-recharge on, a drained balance simply tops itself up from your card and keeps going — which is how a $400 bill becomes a five-figure one. Billing → Payment settings. See how to turn off OpenAI auto-recharge.
• Set a hard spend limit on the organisation, below what you'd be willing to lose. See OpenAI spend limits: hard, soft, and what they miss.
• Remove any saved payment method you don't need on the account.

5. Purge the key from wherever it leaked

Only now is it worth cleaning up the source. The key is already dead, so this is about hygiene and about not training yourself to leak the next one.

If it was committed to git, deleting the file in a new commit is not enough — the key remains in history and in every clone and fork. You need to rewrite history. Full steps in how to remove an API key from git history.

Other common places to check, because a key that leaked once usually leaked twice:

• .env files committed by accident, or .env.example filled in with real values
• Jupyter notebooks — output cells persist secrets even when the source cell is edited
• Client-side JavaScript bundles, which are public by definition
• Mobile app binaries — see why you can't ship an API key in a mobile app
• Docker image layers, CI logs, and build artefacts
• Screenshots and screen recordings in issues, Slack, or a demo video
• Pastebins, Discord messages, and anything you sent to an LLM

6. Contact OpenAI — but expect little

Open a support conversation from the help centre. Give them the key ID, the window of exposure, and the usage you believe is unauthorised.

Be realistic about the outcome. OpenAI's terms hold the account owner responsible for usage on their keys, and reported outcomes for refund requests after a self-inflicted leak are poor. It's worth asking. It is not worth waiting on.

Why this happens so often

Key theft at scale has a name now: LLMjacking. Attackers scan public repositories, pastebins, and mobile app bundles for credentials, then resell access to the model — you pay, they sell. It's automated and continuous, and the volume is not small: a 2026 network-traffic study found 282 iOS apps leaking LLM API keys, and 1Password has documented scanners harvesting exposed OpenAI keys from public sources.

More on the mechanics in LLMjacking: how AI key theft works.

What would have caught this sooner

Honestly: a hard spend limit and something that looks at your daily spend without you remembering to.

Provider spend limits are a good backstop but a poor alarm — they act at a threshold, they're scoped to the organisation rather than the key, and enforcement can lag actual usage. The gap between "a key leaked" and "the invoice arrived" is where the money goes.

That gap is what TKN exists for: it reads OpenAI's billing API and shows today's spend next to your other providers, checks it against rules you set, and lets you revoke a key at the provider from your phone — which matters mostly because leaks are not considerate about whether you're at a laptop.

Sources

• OpenAI — Best practices for API key safety
• OpenAI — Keeping your account secure
• The Hacker News — 282 iOS apps found leaking LLM API keys
• 1Password — Developers: stop exposing your OpenAI API keys
• GitGuardian — Remediating OpenAI API key leaks