Guide · Leaked keys
My API key was exposed. What do I do now?
If it is a secret key, treat it as stolen from the moment it was public, even if you have already deleted it. Make a new one at the provider, put the new one where visitors cannot see it, switch the old one off, then check your usage and bill for anything you did not do. First, check it really is a secret: some keys are meant to be seen.
Is it actually a secret key?
Many apps built with AI tools ship keys that are public on purpose. Those are not a leak, and replacing them changes nothing. Look at how yours starts:
| Key | Usually starts with | Safe for visitors to see? |
|---|---|---|
| Supabase publishable key (older name: anon key) | sb_publishable_ | Yes, if every table has a rule about who may read it |
| Supabase secret key (older name: service role key) | sb_secret_ | No. It skips every rule in your database |
| Stripe publishable key | pk_live_ | Yes |
| Stripe secret or restricted key | sk_live_, rk_live_ | No. It can move your money |
| OpenAI key | sk- | No. Anyone can spend on your account |
| Anthropic (Claude) key | sk-ant- | No. Anyone can spend on your account |
| Firebase key in your app’s Firebase settings | AIza | Yes, Google says these are public by design |
| Gemini key | AIza | No. Google says it must never be in your code |
Notice the last two look the same. A Google key is only as safe as what it is allowed to call: one limited to Firebase is fine to show, one that can call Gemini is not. You can see what each key is allowed to do on the Credentials page of the Google Cloud console.
Why deleting it from my code is not enough
Once a key has been public, copies of it exist that you cannot reach: in the history of your repository, in anyone’s download of your site, in tools that scan GitHub all day for exactly this. GitHub’s own advice is to consider any leaked secret to be immediately compromised, and it says removing the key, pushing a new version or even deleting the repository does not stop it being used. The only thing that stops it is switching the key off at the provider.
What to do, in order
1. Make a new key and switch the old one off
Do it in one sitting. A feature that is broken for half an hour costs far less than a stranger’s bill. Where to do it, provider by provider, is below.
2. Put the new key where visitors cannot see it
If the old key was in your website’s code, the new one will leak the same way unless that changes. Paste this into Lovable, Bolt, Cursor or whichever tool built the app:
A secret key is in code that visitors’ browsers download, or in my repository. Move every secret key (payments, AI, email, database admin) into server side code and environment variables that never reach the browser, and make the browser call my own server instead of calling those services directly. Keep only keys that are meant to be public in the browser, such as the Supabase publishable key or the Stripe publishable key. When you are done, list every key you moved and where it lives now.
3. Check what was done with it
Open the provider’s usage or billing page and look for activity on dates you did not use it, or amounts that do not match your customers. Google warns that an exposed key can lead to unexpected charges. If you find some, contact the provider’s support straight away and say the key was stolen; the sooner they hear, the more they can do.
4. Set a ceiling on the bill
Most AI providers let you set a monthly limit and an alert. OpenAI’s limits page has both: a hard limit that stops traffic once spend reaches it, and alerts before that. A limit will not stop a leak, but it decides how much a leak can cost.
5. Clean the old key out of your code history, last
Worth doing, but only after the key is switched off, because cleaning the history does nothing for a key someone has already copied.
Where to replace it, provider by provider
OpenAI
On the API keys page of the OpenAI platform, make a new key, put it in your app, then revoke the old one. While you are there, set a monthly limit on the Limits page.
Anthropic (Claude)
In the Claude Console, open API keys, make a new key, put it in your app, then disable or delete the exposed one.
Google Gemini
On the Credentials page of the Google Cloud console, make a replacement key, put it in your app, then delete the old one. Deleting is permanent and breaks anything still using that key, which is the point.
Stripe
On the API keys page of the Stripe Dashboard, open the menu beside the key and choose Rotate key. Set the expiry to Now: any later choice keeps the old key working for up to seven days, which suits a routine change and not a leak. Stripe also suggests a restricted key, allowed only what your app needs, in place of a full secret key.
Supabase
Follow Supabase’s guide to rotating a leaked or compromised key, and fix the cause first, as Supabase advises, or the new key leaks the same way. If your project still uses the older service role key, note that it keeps working until you switch it off under Settings, API Keys; making new keys does not retire it. Supabase blocks its secret keys in browsers, but says a stolen one still works from other tools, so the browser block is no reason to wait.
How common is it?
In our 30 October 2026 study of 50 public apps built with Lovable and Bolt, we read the code of 47. 18 of the 47 had a key or password sitting in it. The study page explains how the apps were chosen and what the numbers cannot tell you.
Not sure whether your site is handing out a secret right now? Our free key check reads what your site sends to a browser, tells a secret key apart from a public one, and says which is which in plain English. GuardCue checks apps built with AI tools, for the person who built them rather than for a developer.