Your OpenAI API key leaked: what to do in the first 10 minutes

The key went out in a public repo, in logs, or in a client bundle. The clock is already running: fresh keys on GitHub get probed by bots in under a minute after the commit. Here's the plan, step by step.

Step 1. Revoke the key immediately

Open platform.openai.com/api-keys and delete the compromised key. If the service has to keep running — create a new key first, switch production over, then delete the old one. Two minutes of duplicated effort beats downtime.

Important: "I removed the file from the repo" is not revocation. The key lives on in git history, in forks, in search-engine caches, and in the hands of scanners that already copied it. The only thing that makes a leaked key worthless is revoking it on the provider's side.

Step 2. Assess the damage

Check the last hours and days in Usage. Look for:

• request spikes at unusual times (nights, weekends);
• models you don't use (stolen traffic usually goes to the most expensive ones);
• request growth while your own traffic is flat.

If the charges are significant, contact OpenAI support: with a clear compromise they sometimes credit the costs, but it's decided case by case.

Step 3. Find the source of the leak

Revoking without finding the cause is just re-arming the mine. The usual suspects:

• Git history. Scan the repository: gitleaks detect or trufflehog git file://. — they find secrets across the whole history, not just current files.
• Logs. A key that ended up in a query string or debug output settles into app logs, nginx, CI, and monitoring systems.
• Client-side code. A key baked into a frontend or mobile app is public by definition — anyone with DevTools can extract it.
• CI and environment. Variables printed in build logs; a .env accidentally shipped inside a Docker image.

If the leak was in a public GitHub repo — rewrite history (git filter-repo), or, simpler and more honest: treat everything in that repo as compromised and revoke every secret that was ever in it.

Step 4. Make the next leak worthless

The key leaked because it sat where other hands could reach. A new key put in the same place will leak the same way. Working measures, in order of increasing strength:

1. Secrets out of code. Environment variables, .env in .gitignore, CI secret stores. The baseline everyone should have.
2. A secret scanner in CI. gitleaks/trufflehog as a pre-commit hook plus a mandatory pipeline check — leaks get caught before the push.
3. Don't hand out the real key at all. The real key lives in one encrypted place, and apps, scripts, and AI agents get proxy tokens — virtual keys with IP binding, their own rate limits, and instant revocation. A leaked token gives nothing: it doesn't work from a foreign address, limits cap the damage, and revoking it doesn't touch the original.

FAQ

Is rotating the key enough?

Rotation closes this leak, not the cause. If the key is stored the same way as before, the new one leaks the same way. Change the scheme: real key in a vault, revocable tokens outside.

How fast are leaked keys found?

Public GitHub is scanned continuously. The first foreign requests on a freshly leaked key show up within a minute. Assume a published key is compromised instantly.

What if an AI agent needs the key?

Never give an agent the real key: anything that enters a model's context can end up in logs and traces. Hand it a proxy token instead — details in our article on keys for AI agents.