Leaked OpenAI API Key on GitHub: How to Check and Rotate
Where OpenAI, Anthropic and other AI keys leak from an app project, how to look for them in your repositories and frontends, and what to do when one is out.
Published Last updated
An AI-service key leaks when it sits where other people can read it: a public repository, a commit from last month, or the JavaScript your app ships. Search your repositories, their history and your built app for the key, revoke it in the provider dashboard, create a replacement that lives on a server, and set a spend limit. Deleting the line is not enough.
What do we know about leaked AI keys?
Checked on October 24, 2026, against the pages listed under Sources.
| Fact | What the source says | Source |
|---|---|---|
| Volume | 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% on the year before | GitGuardian, March 17, 2026 |
| AI services | 1,275,105 AI-service leaks in 2025, an 81% rise | GitGuardian, March 17, 2026 |
| Staying valid | Of credentials validated in 2022, about 70% were still active in January 2025, and the rate held above 64% at a January 2026 retest | GitGuardian, March 17, 2026 |
| In an Expo app | EXPO_PUBLIC_ variables are visible in plain text in the compiled application | Expo docs |
| On GitHub | Push protection for users is on by default and stops pushes of detected secrets to public repositories; anyone with write access can bypass it with a reason | GitHub Docs |
GitGuardian counts what its detectors recognise in public commits, so the figures describe public GitHub and say nothing about your private repositories or your app. They show that stale keys stay live for years, which is why finding one matters less than revoking it.
Where do AI keys leak from?
An AI key is a bearer credential. Whoever holds the string can spend your credit, and the provider bills the account that issued it. OWASP's Mobile Top 10 lists hardcoded credentials as M1 and advises against putting them in an app's code or configuration files. In an app project, the keys get out through five routes:
- The frontend bundle. A variable with a public prefix is written into the JavaScript at build time. Next.js inlines
NEXT_PUBLIC_values into code sent to the browser, and Vite exposesVITE_variables in client-side source. - A committed file. A
.envfile, a config file or a test script with the key pasted in, pushed to a public repository. - Old history. The key was removed in a later commit, but the earlier commit still holds it.
- Shared text. CI logs, issue threads, screenshots and chat exports that include a request with its key.
- An AI coding tool.GitGuardian reports that commits assisted by Claude Code leaked a secret 3.2% of the time against a 1.5% baseline across public commits. That is GitGuardian's measurement of one tool in one dataset. Read what an assistant adds to your project the way you would read a colleague's commit.
Path B is the fix for the first route. The Vite docs say to consider a backend server or serverless functions to protect secrets, and OpenAI's production guidance says to expose keys to your application through environment variables or a secret management service rather than hard-coding them.
How do I check my own repository and app?
Newly builds a real iPhone and Android app with React Native and Expo, and you can download your project code or connect your own repository. That gives you files you can search, which is all these checks need. They work the same in any project.
1. List the variables that ship
Open your .env files and app config and list every variable. Anything starting with a public prefix is in the bundle. Use the table to see which prefix your tooling publishes.
| Tooling | Prefix that ships | What the docs say |
|---|---|---|
| Expo | EXPO_PUBLIC_ | Do not store private keys in these variables; they are visible in plain text in the compiled app |
| Next.js | NEXT_PUBLIC_ | Inlined at build time into the JavaScript sent to the browser |
| Vite | VITE_ | Exposed in client-side source; should not contain API keys |
An AI provider key in any of these is detected. A key with no public prefix is still unknown until you search the built output, because a hardcoded string ships regardless of its name.
2. Search the current files and the history
Search the repository for the start of your provider's key format, then run a secret scanner over the whole history, not only the latest commit. GitHub lists OpenAI, Anthropic and Google API keys among the patterns it detects, and secret scanning runs for free on public repositories. Turn push protection on for private ones if your plan includes it, since it blocks the push before the key lands.
3. Search the built app
Export a production web build and search the output folder for the same key prefixes. For a phone build, the JavaScript bundle is inside the package, and anyone can unpack it. A key you find there has been published, whatever your repository settings say.
4. Search the places that are not code
Open your CI logs, issue tracker, shared documents and any screenshots you posted while asking for help. Treat a key in any of them as exposed to everyone who can read that place.
Why live keys stay live
GitGuardian's retest found over 64% of credentials it had validated in 2022 still active in January 2026. A key does not expire because the commit is old. Only revoking it ends the access.
What do I do if a key leaked?
GitHub's guidance on removing sensitive data says that when the data is a secret, the first step is to revoke or rotate it, and that rewriting history may not be warranted afterwards. The OWASP Secrets Management Cheat Sheet gives the same order: revoke, replace, then remove the secret from code and logs.
| Step | What to do | Evidence to keep |
|---|---|---|
| 1. Create a replacement | Issue a new key, ideally scoped to one project, and put it on your server | The new key's name and date |
| 2. Switch the app | Point the server function at the new key and test one call | A successful test call |
| 3. Revoke the old key | Delete it in the provider dashboard (Anthropic's guidance is to revoke a suspect key immediately) | The revoke entry and a failed call with the old key |
| 4. Read the usage | Check the provider's usage and log pages for requests you did not make | A dated screenshot |
| 5. Cap the next leak | Set a spend limit and an alert on the account or project | The limit setting |
For limits, OpenAI documents spend alerts and hard monthly limits, and Anthropic documents workspace spend limits. Anthropic's key guidance also suggests rotating on a schedule, for example every 90 days.
Some providers take part in GitHub's partner program. Anthropic does: GitHub forwards tokens found in public repositories, and Anthropic revokes them and notifies the owner. That helps after the fact for one route only, so keep your own checks.
If the key pays for AI inside an app you publish, remember that AI features in a Newly app use credits and some features have limits. Any key you hold with a provider directly has the limits you set on that account, so set them.
When the leak came from a wider breach
If the key sat next to other secrets in a file that was exposed, such as a .env a scanner could fetch, rotate every value in it. Red has a guide to rotating secrets after a breach and a 30-second check for bots requesting .env and .git. For the app itself, start with the 15-minute app check, and see the security hub for the rest.
Where do you stand?
Every item starts as unknown. Move it to detected when you find the problem, and to confirmed only when you hold the evidence under it. The chat feature in your app is a separate exposure, covered in the chatbot self-test.
Your AI key check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
I deleted the key from my repository. Is it still exposed?
Treat it as exposed. The key stays in earlier commits, in forks and clones, and in every app build that already shipped it. GitHub's own guidance says the first step is to revoke or rotate the secret, and that rewriting history may not be needed once the old key no longer works.
Will OpenAI or Anthropic shut off a key that leaks on GitHub?
Do not count on it. Anthropic is a GitHub secret scanning partner: GitHub forwards tokens found in public repositories and Anthropic revokes them and notifies the owner. That covers public repositories, not a key inside an app bundle or a private repository, and a revoked key still leaves you to find out how it got out. Revoke and replace keys yourself.
Is it fine to call the AI provider straight from my mobile app?
Only with a key you are willing to publish. Expo documents that EXPO_PUBLIC_ variables are visible in plain text in the compiled app, and anyone who installs the app can read what it contains. Put the provider key on a server that checks who is asking, and let the app call that server.
How do I limit the damage if a key is already out?
Revoke the key first, then set spend limits so a future leak has a ceiling. OpenAI documents spend alerts and hard monthly limits, and Anthropic documents workspace spend limits. Review the usage pages for requests you did not make.
Does a clean scan mean my keys are not exposed?
No. A scan of your live site can report a key it saw in a public file or bundle. It cannot see your repository history, your CI logs, a teammate's laptop or code that never answers a public request. Treat a clean result as unknown until you have checked those places and hold the evidence.
Do I need to rotate keys that only live in a .env file?
Rotate any key that was ever committed, pasted into a chat, printed in a log or built into an app. A .env file that was never committed and never shipped does not need an immediate rotation, but add .env to your ignore file and rotate on a regular schedule.
Sources
- The State of Secrets Sprawl 2026 (March 17, 2026), GitGuardian
- Leaked API Keys in LLMs (October 19, 2026), GitGuardian
- Production best practices, API keys, OpenAI developer docs
- API key best practices, Anthropic Help Center
- Workspaces and spend limits, Claude Platform docs
- Anthropic is now a GitHub secret scanning partner (August 20, 2024), GitHub changelog
- Supported secret scanning patterns, GitHub Docs
- About push protection, GitHub Docs
- Removing sensitive data from a repository, GitHub Docs
- Environment variables in Expo, Expo docs
- Environment variables, Next.js docs
- Env variables and modes, Vite docs
- M1: Improper Credential Usage, OWASP Mobile Top 10
- Secrets Management Cheat Sheet, OWASP Cheat Sheet Series
