OpenAI API key leaked? What to do in the first hour
What to do when your OpenAI, Anthropic or other AI provider key leaks: revoke it, cap spending, check usage, find the source and keep it from happening again.
Leer en español →
If your OpenAI key (or an Anthropic, Gemini or other AI provider key) leaked, revoke it in the provider's dashboard right now, before you do anything else, then create a new one and put it only on your server. Next, set a hard spending limit, check the usage page for calls you didn't make, and find out how the key got out so the new one doesn't follow it. Deleting the key from your code or your GitHub repository does not stop anyone who already copied it.
This guide walks through the first hour in order, what to look for in the usage data, how to contact the provider about charges, and the changes that make the next leak much less expensive.
Why is a leaked AI key so urgent?
Because it is money, not just data. A leaked AI key lets anyone send requests billed to your account. People run scanners over public GitHub repositories, browser bundles and paste sites looking for these keys, and a working one can be resold or used to run someone else's product on your credit. The damage is limited mainly by how much your account is allowed to spend.
Some providers get help from GitHub here. OpenAI and Anthropic both take part in GitHub's secret scanning partner program: when a key in their format is pushed to a public repository, GitHub notifies the provider, which can disable it. Anthropic's support pages say it deactivates such keys automatically and emails the owner. That only covers public GitHub repositories, though. A key in your website's JavaScript, a screenshot or a shared document is not caught by it.
What should I do in the first hour?
Work through these in order. Each step is short.
- Revoke the key. In OpenAI, open the API keys page of the project that owns the key and revoke it. In the Claude Console, disable or delete it from the API keys section. Other providers have an equivalent page. If a production system still needs a key, create the replacement first, but don't let that delay the revocation by more than a few minutes.
- Create a new key with the smallest scope you can. OpenAI keys belong to a project, so a key for one app should live in a project used only by that app. Where the provider offers per-key permissions, give the new one only what the app needs.
- Store the new key on the server only. Put it in your backend's or Edge Function's secret store, not in a
VITE_orNEXT_PUBLIC_variable and not in a file the browser loads. If you are not sure where it was before, read our guide on finding an API key exposed in your frontend. - Set a spending cap. In OpenAI, project spend limits are under the project's settings, in Limits. A hard limit makes requests fail with a
429error and the codeproject_spend_limit_exceededonce the monthly amount is reached. OpenAI notes that enforcement is not instant, so recorded spend can go slightly over. Add a spend alert below the cap so you hear about it first. - Redeploy and test. Make sure the app works with the new key and that the old one is rejected.
How do I check whether the key was used?
Open the provider's usage page and look at the period between when the key could have leaked and when you revoked it.
| What you see | What it may mean |
|---|---|
| A spike in requests or tokens you can't explain | Someone else was using the key |
| Models your app never calls | Almost certainly not your traffic |
| Activity at hours your users are asleep | Automated use by a third party |
| Usage that keeps rising after you "fixed" the code | The key was never revoked, or a second key leaked |
If usage is split by key or by project, check which key generated the traffic. This is one more reason to keep one key per app and environment: you can tell the leak apart from your own usage, and revoke one key without taking down everything else.
Can I get the charges refunded?
Possibly, but don't count on it. Contact the provider's support with the dates, the key's name or last characters, and what you have already done (revoked, rotated, added limits). OpenAI's own API key safety guidance asks you to rotate the key and contact support through its help centre if you believe it was compromised. Keep screenshots of the usage graphs. Whether anything is credited is the provider's decision.
How did the key get out?
You need the answer before you can stop the next leak. The common sources in apps built with AI tools are:
- The browser bundle. The app calls the AI provider directly from the frontend. This is the most frequent cause, and it means every visitor received the key.
- A public GitHub repository. A
.envfile was committed, or the key was hard-coded in a config file. Search the history, not only the current files:git log -S "sk-"finds commits that added or removed that string. - A shared screen or file. A screenshot in a support ticket, a recorded demo, a prompt pasted into a public channel, a Notion page.
- A third-party tool. A no-code automation, a browser extension or an online "prompt tester" you gave the key to.
- An ex-collaborator. Someone who once had access to your dashboard or code and still has a copy.
If the key was in the frontend, fixing the leak means building a small server function that makes the AI call for the browser. Revoking alone won't hold: the new key will leak the same way within days.
How do I make the next leak cheaper?
Leaks happen even on careful teams. These settings decide whether one costs you pocket change or a month's revenue.
- One key per app and per environment. Development, staging and production each get their own, in their own project where the provider supports it.
- Hard limits at both levels. A project limit for each app and an organization limit as a backstop.
- Per-user limits in your own app. Even with the key safe on the server, a single user can still run up the bill through your feature. See rate limiting AI features and our guide to controlling AI API costs.
- Expiring keys. OpenAI's guidance recommends giving keys an expiration date and rotating them on a schedule.
- IP allowlisting where your provider offers it and your server has a fixed address.
- Secret scanning in your repository with push protection, so a commit containing a key is blocked before it is public.
Quick answers
Is deleting the key from GitHub enough? No. Old commits, forks and clones keep it. Revoking it in the provider's dashboard is the only thing that stops it working.
Will OpenAI disable the key for me? Sometimes, if it was pushed to a public GitHub repository. Don't wait for that: revoke it yourself.
Do I need to tell my users? A leaked AI key usually exposes your billing, not their data. If the key also gave access to stored conversations or files that contain user data, treat it as a possible data incident and get advice.
Why did the new key leak again? Because the cause wasn't fixed. If the app calls the provider from the browser, every new key is public the moment you deploy it.
Need help closing the gap?
If you're not sure where the key was exposed, the free health check shows what your live app reveals from the outside. If the AI calls need to move to a server with proper limits, our maintenance and support plans and Supabase security review cover that, and you can write to us with what happened.
