Leaked API key, the emergency procedure in five steps

A leaked API key is handled like a water leak. You shut off the flow first, mop up second and look for the cause last. Revoking the key takes thirty seconds in the provider's console and stops everything. Every minute spent investigating before that step is a minute of possible fraudulent usage, so the procedure that follows runs in the exact order you should carry it out.

There is still no reason to panic. A stolen key lets someone spend money, but it does not let them into your account or let them change its settings. The incident is financial, limited by your cap if you set one and reversible in every case. The procedure takes five steps and less than an hour, with your phone in hand if your computer is far away.

01Key takeaways and the five-minute checklist

• Revoke the compromised key immediately in the provider's console, before any investigation.
• Create a new key and plug it back into your legitimate tools, one by one.
• Audit the usage of the last few days and report any fraudulent spending to support.
• Find the source of the leak, whether a Git repository, a screenshot or a published file, then fix it for good.
• Set the cap and the alerts that will make the next incident painless.

02Reflex zero, cut first and understand later

Published reports agree that an API key leaked in public gets exploited within minutes, because bots continuously scan code repositories and public pages. Incident stories describe fraudulent usage that burns through the equivalent of years of normal use in two days. The practical conclusion leaves no room for nuance. At the slightest doubt, you revoke. A key revoked by mistake takes a minute to recreate, while a key left active by mistake costs you money.

Like any emergency response, this composure is learned in advance. That is the spirit of the whole guide to AI without a subscription. A personal key gives you control, including the power to stop everything in thirty seconds without depending on anyone else to do it for you.

03Step 1, revoke the compromised key

Go to the provider's console and open the API keys section. Every key there has its own revoke or delete button, which takes effect immediately. Calls that used the key fail right away with an authentication error. That is the goal. The interruption of your tools is the normal price of the cutoff. It only lasts for the duration of step 2, a few minutes in practice.

If several keys look alike and you remain unsure which one leaked, revoke every plausible one. The inconvenience of recreating three keys is nothing compared with the risk of having left the right one running. Doubt is always settled on the side of the cutoff. The detailed steps, provider by provider, are in the full key rotation tutorial.

04Step 2, create a new key and reconnect

You generate the new key in the same place, in a minute. Name it clearly and take the chance to apply the one-key-per-use rule if the old key was used everywhere, since the incident is a good moment to tidy up what was never tidy. Then reconnect your legitimate tools one by one. The writing tool, the website and the automation each get the new value in their usual setting. Creating a key at the provider covers the screens of each provider.

One point matters a lot here. Update EVERY environment that held the old key, meaning the workstation, the server and any continuous integration tool. A forgotten copy means a tool that will fail later, at a moment chosen by chance. The list of locations you draw up now will serve for every future rotation. You should be able to count the copies on one hand. Beyond that, what is missing is a split into several keys rather than a better memory.

05Step 3, measure the impact

The financial investigation comes after the cutoff. The provider's usage page shows consumption by day and by key. Auditing your account usage explains how to read it. Look for the break, the day the curve leaves your usual pace. It dates the leak better than any memory and limits the period you need to examine. Write down the figures before and after, since they will serve both for the report to support and for your own review.

If the spending is clearly fraudulent, contact the provider's support with the details, namely the dates, the key concerned and the usage profile. Goodwill policies vary and nothing is guaranteed. A documented request costs only one message, though. Published reports show that it regularly succeeds when the incident is reported quickly, with the key already revoked and a clear timeline to back it up.

06Step 4, find and fix the source

Three origins dominate. The Git repository comes first. A key that entered the history once stays there even if the file has since been fixed. Purging it requires dedicated history-rewriting tools. The platforms document the official procedure, so search for removing sensitive data in their official online help. Specialized scanners such as gitleaks or trufflehog on the open source side search an entire repository in a few minutes and confirm that it is clean, history included.

Next comes the screenshot, the shared configuration or the homemade tutorial where the key appears in plain text. Delete it or blur it, on the assumption that anything that was public has been read, even for five minutes, even at night. Last comes the published configuration file, the archive or the folder exposed by mistake on a server. Fix the exposure itself and not only the current file, which is merely a symptom. Until the source is closed, the new key will take the same path as the old one. An API key leaked twice through the same channel is a habit by then, far more than an accident.

07Step 5, make the next incident painless

A closed incident is the best moment to equip yourself, while the energy is still there. Set the cap that limits the damage at each provider, the one-minute step that turns any future leak into an interruption instead of a bill. Turn on email threshold alerts, split your uses into separate keys and write down the date for the next rotation. Ten minutes of setup while things are fresh spare you the next hour of emergency work.

Then adopt the underlying habits. The good protection practices cover the eight habits that keep you from needing this procedure again. A leak handled in an hour and then prevented for good beats a leak you never had and never prepared for. An incident that teaches you something is not wasted, because it ends up paying for itself.

08The timeline of a well-handled incident

At minute zero, the threshold alert email arrives or the spike jumps out on the usage page. At minute one, the key is revoked, from your phone if need be, since provider consoles work very well on mobile. At minute five, the new key exists and the first critical tool is reconnected. The remaining environments follow within fifteen minutes, thanks to the list of locations you keep up to date.

Within the hour, the usage page has given you the date of the break and the scope of the spending. The message to support has gone out if the fraud is obvious. Within the day, the source is identified and closed, the repository scanned and the screenshot deleted. Within the week, the cap and alerts are set everywhere and the rotation date is on the calendar. The incident has turned into a drill. The whole difference from the disaster scenario lies in preparing the steps ahead of time.

09The BYOK case, one less place to leak from

Think about where your key lives when you hand it to an online tool. If the tool stores it on its servers, its leak becomes yours, multiplied by all of its customers. The opposite architecture exists with a key that stays in the browser, kept on your device and never sent to the service. That's the setup behind OpenTahr, where the account is free. Our servers have nothing to lose because they hold nothing.

No architecture exempts you from the five steps above. A good one simply reduces the number of doors through which an incident can come in. Fewer places where the key exists means fewer places it can leak from. You check that criterion before handing over your key, well before an incident that could have been avoided.

10Frequently asked questions

What should I do first if my API key has leaked?

Revoke the key in the provider's console, immediately and before any investigation. Those thirty seconds stop all fraudulent usage. Creating the replacement key, auditing the spending and finding the source come next, in that order and without rushing. Nothing is more urgent than the cutoff. Everything else can wait ten minutes.

How can I tell if my key was stolen?

The most reliable sign is usage that doesn't match your activity. Look for a spike on the usage page, models you never use or regular calls at hours when you are asleep. An email threshold alert catches it automatically. At the first strange profile, revoke the key and then investigate.

Does a stolen key give access to my account?

No. The key lets someone consume the API on your billing, but it does not let them log in to the account, read its payment details or change its settings. That is what makes the spending cap so effective. The thief spends up to the limit you set and then everything stops dead.

How do I remove a key from Git history?

Fixing the file is not enough, because the history keeps everything. You need to rewrite the repository with a dedicated purge tool and then force the update, following your platform's official procedure. The exposed key still has to be revoked in every case. Treat it as burned from the moment it was pushed, however fast the fix was.

Transparency. The procedure follows the official recommendations of the providers and platforms cited as sources, consulted on June 13, 2026. The orders of magnitude for how exposed keys get exploited come from published reports and are given without precise figures because no verifiable primary source was available. None of the providers mentioned pays us.

11Sources

1. OpenAI official help on API key safety
2. GitHub official documentation on removing sensitive data from a repository
3. Gitleaks open source secret scanner (official repository)