An OpenAI API key lets whoever holds it send requests that are billed to your account and use your rate limits, with access to whatever your project allows. If yours ended up in a public place, the fix takes about a minute, and it has to come before anything else: revoke the key first, then look at what happened. Deleting the commit is not enough, because public commits are copied within minutes.
Check your GitHub account for leaked secrets — free
- Provider
- OpenAI
- Severity
- High
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- Yes
- Revoke at
- OpenAI
What an OpenAI API key looks like
OpenAI secret keys start with sk-. Keys created inside a project start with sk-proj-, older user keys with plain sk-:
sk-proj-…XXXX (project key, masked)
sk-…XXXX (older user key, masked)
Two look-alikes are not OpenAI keys: sk-or-… belongs to OpenRouter and sk-ant-… to Anthropic. If your key starts with one of those, use the OpenRouter or Anthropic guide instead.
How OpenAI keys get leaked
- A
.envfile committed by accident, or an.env.examplethat someone filled with the real value to “make it work”. - Calling the API from the browser. Anything shipped in a front-end bundle is public. A key in client-side JavaScript is leaked the moment the page loads.
- Notebooks. A key pasted into a Jupyter or Colab cell is saved with the notebook, and cell outputs can echo it again.
- Copy-pasted snippets. Code from a chat, a tutorial or an AI assistant often contains a placeholder that gets replaced with the real key “just to test” and never put back.
- Logs and screenshots: a debug print of request headers, a CI log, a screenshot of a terminal shared in a bug report.
What to do in the first hour
- Revoke the key. Open the OpenAI API keys page, find the key (the list shows the name and the last characters, so match them against what leaked) and delete it. Do this before cleaning anything. If the key belongs to a project, make sure you are in the right project.
- Create a replacement and store it in an environment variable or a secret manager, not in the repository. Give each service its own key so the next revoke does not take everything down, and restrict its permissions to what that service actually calls.
- Check usage for abuse. Open the usage dashboard and look at the period since the key was exposed. Red flags: a spike in requests, models you never call, or activity at hours when nobody on your team works. Usage figures can lag, so check again in a few hours.
- Cap the damage next time. Set a monthly budget or spend limit on the project and enable usage alerts, so a stolen key cannot silently run up a large bill.
- Check what else was in the same file. A leaked
.envrarely holds only one secret. Revoke the database password, cloud keys and webhooks that were next to it. - Only then clean the repository: remove the value from the code, add the file to
.gitignore, and rewrite history if you want. The full order of operations is in our guide I accidentally pushed an API key to GitHub.
Revoke it at OpenAI
Go to the OpenAI API keys page, select the key and delete it. A deleted key stops working for new requests. Keys are scoped to a project, so a key you cannot find may live in another project of the same organization.
How LeakWatch detects it
LeakWatch recognizes the sk- / sk-proj- format and excludes the look-alike prefixes of OpenRouter and Anthropic, so those keys are reported under their own type. See which vendors leak most this week on the leak trends page.
LeakWatch can check whether a detected key is still active with a read-only request to OpenAI. It never reads your data or spends your credits.
The request lists the available models. It does not generate text.
FAQ
How do I know if someone used my OpenAI key?
Look at the usage dashboard for the period since the exposure and compare it with your normal traffic. Unexpected models, a sudden jump in volume or off-hours activity are the signs. If you see unfamiliar activity, revoking the key already stops it for new requests; contact OpenAI support if you need billing reviewed.
Can I just regenerate the key and keep the old one for a while?
No. The point of rotating is that the old value stops working. Create the new key, deploy it, and delete the old one right away. Keeping the exposed key “just in case” leaves the hole open.
Is an sk- key in a private repository still a problem?
It is a smaller risk, not zero: anyone with repository access, every clone and every CI log can read it. Treat it as exposed if the repository was ever public, was forked, or is shared with people who should not have the key.