Revoke the key at the provider now, before you read anything else: every minute it stays valid is a minute a stranger can spend on your account. If you searched api key leaked what to do, the order is 6 steps: revoke, replace, check the bill, check the logs, prove the old key is dead, then clean the repository.
API key leaked what to do right now: the 6 steps in order
A leaked API key is handled in 6 steps, in this order: revoke it at the provider, deploy a replacement, check the bill, check the request logs, prove the old key now fails, and clean the repository last. Deleting the commit first leaves the key working.
- 01 Revoke or disable the leaked key in the provider dashboard. Allow about two minutes. The app may break until step 2 is done, and that is the right trade.
- 02 Create a new key, put it in your host environment variables, and redeploy. Allow about ten minutes.
- 03 Open the provider usage and billing page and compare the last few days with a normal week.
- 04 Read the provider request logs for calls you did not make, and write down the time range.
- 05 Prove the old key is dead with one request that must fail, and save the response with the time.
- 06 Only now deal with the repository: the history, any forks, and open pull requests.
The two times are my rough timing for one key on one host, not a provider figure. Steps 3 to 5 carry no time because they depend on how much traffic the key saw. Where keys should live once this is over is covered in secrets management best practices.
The order exists because the key, not the file, is what grants access. Removing the commit from GitHub feels like the fix, but anyone who copied the value keeps a working key until the provider refuses it. GitHub’s own guidance puts revoking or rotating the secret first and treats a history rewrite as an extra step that “may not be warranted”.
If the API key leaked on GitHub, what you do is the same: six steps, same order, and the repository only decides how long step 6 takes. As a response checklist for a git secret leak, the list is short on purpose: the order matters more than the items. If you leaked your own API key in a personal project with no customers, the list is the same and shorter, because steps 3 and 4 are a look at your own bill and logs.
Write down the time of each step as you go. A customer, your cofounder or the provider’s support team may ask when the key stopped working, and a note made at the time beats a reconstruction.
What happens if my API key gets leaked: what a stranger can do with it
A leaked API key works for anyone who holds it until it is revoked. An AI key runs up your bill, a payment key reaches customers and refunds, and a database admin key can skip row level security entirely.
In my audits of June and July 2026, 12 of the 14 AI apps had a confirmed denial-of-wallet path, where a stranger or free account can burn the owner’s paid AI or compute bill without limit. Those 14 are a selected set of apps I audited, not a random sample and not a rate for AI apps in general. What it means for a leak: an AI key can land on an account with no ceiling unless somebody set one.
| Key type | What a stranger can do with it | What it costs you | Where you would see it |
|---|---|---|---|
| AI provider key | Call any model your account can reach | Usage billed to you; in Anthropic’s words, “they incur charges on your behalf” | The provider’s usage page |
| Payment secret key | Read customers, issue refunds, create charges | Money moved and customer records read | The payment dashboard’s request logs |
| Database service or admin key | Read and write every row, bypassing row level security | Your customers’ data | The database provider’s logs |
| Email provider key | Send mail from your domain | Your domain’s sending reputation | The provider’s sending log |
| Cloud access key | Start compute billed to you | Compute charges; on AWS, a quarantine policy AWS may apply to exposed keys denies spend actions such as starting instances | The billing console and access logs |
| Webhook signing secret | Forge events your app trusts | Fake orders, upgrades or refunds your app acts on | Your webhook handler’s logs |
Keys get found because public code is scanned for them automatically. GitHub scans public repositories for known secret formats by default and sends matches in partner formats to the provider that issued them. It also tells those providers it recommends “considering any secrets that GitHub sends you messages about as public and compromised”, so a key that reached a public repository is best treated as compromised from the moment it was pushed. The one timing figure I rely on comes from a 2019 NDSS paper on secret leakage in public GitHub: researchers at North Carolina State University, collecting from public GitHub between October 31, 2017 and April 20, 2018, measured a median of 20 seconds for their own pipeline to see a test string they had just pushed. That is how fast the researchers’ own search saw it, on data from 2017 and 2018, not a measured attacker time.
An AI API key being used by strangers shows up as usage at hours you do not work and on models you never call. Lists of leaked API keys and GitHub API key finder tools turn up in the same searches; they are the other side of that machinery, and this page links none of them.
Why this happens
Anthropic names accidental exposure in public code repositories or third-party tools as “one of the most frequent causes of API key leaks”. The five routes below start with that one; the rest are in no particular order.
| How it leaked | How you might find out | The extra clean-up it needs |
|---|---|---|
Committed to a repository: a .env file, a config file, a test script, or an AI agent that wrote the key into code | A provider email, a scanner alert, or someone telling you | History, forks and clones (step 6) |
| Shipped in the browser bundle because the variable had a public prefix | Your own browser’s developer tools show it, to you and to anyone else | A new build without the key, and the call moved to the server |
| Pasted into a chat, a support ticket, a screenshot or an AI prompt | Often never, unless you remember doing it | Ask the recipient to delete the message; the revoked key is already useless |
| Printed in build or application logs | Reading the logs, or a log tool’s alert | Delete or expire those log lines where the host allows it |
| Left in a public gist, notebook or API client workspace | A provider email or a search | Delete the item or make it private |
The committed .env case has its own walk-through: if you committed .env to GitHub, start there once the key is revoked. The browser-bundle case is different enough to need its own page, on API keys exposed on the frontend.
A GitHub API key leak in a private repository still counts: every collaborator, every connected integration and every past clone has the value. The FTC’s revised complaint against Uber (Docket C-4662, issued October 25, 2018) says intruders reached Uber’s Amazon S3 datastore with an access key that “was in plain text in code that was posted to a private GitHub repository”. The intruders said they got into Uber’s GitHub using passwords exposed in other large data breaches, and the complaint says they downloaded 16 files between October 13, 2016 and November 15, 2016. Those are the FTC’s allegations, settled by consent order, not a court finding. In my reading, the lesson is that a private repository narrows who holds a key and does not make it unleaked: only the key stopping working ends the leak, and that has to be done at the provider.
”Your API key was reported as leaked”: what the provider’s email means
An email saying your API key was reported as leaked can come from a scanning partnership: GitHub reports matching key patterns in public repositories to the provider, which may revoke the key, notify you, or both. Treat it as true, revoke anyway, and verify the sender’s domain first.
GitHub leaves what happens next to each provider: its secret scanning partner program says partners “can enhance” their alert service to revoke exposed secrets and notify the users, and how they do it “is up to you”. Anthropic says it takes part: when a Claude API key is detected in a public GitHub repository, “Anthropic automatically deactivates the exposed API key” and the affected user gets an email, per Anthropic’s API key best practices. What OpenAI does with a key found in public is not stated in OpenAI’s developer docs, so do not assume it has been switched off.
Phishing messages copy these alerts, so open the provider’s dashboard from your own bookmark rather than a link in the email. If the key was already disabled for you, steps 2 to 6 still apply: the app needs a new key, and the bill, the logs and the repository still need a look.
Google API keys compromised: what to do, and which Google keys are not secrets
For compromised Google API keys, Google’s order is: create and deploy a replacement, delete the old key, then review all access to your Google Cloud resources. Restrict the new key by website, IP address or app (one type per key) and by API. Firebase-only keys need not be secret if you follow Firebase’s guidelines; a Gemini key must be.
Google’s compromised credentials guidance says to “generate a new credential, deploy it to all services and users that need it, and then revoke the old credential”, then review access with Cloud Logging or Security Command Center. In the console that is the Credentials page, the key’s name, Rotate key, Create, and, once your apps use the new string, Delete the previous key. Google orders it that way so revoking does not cause a service outage. For a key that is already public, I would still delete the old one first and accept a short outage, as step 1 says. Google’s API keys documentation lists the restrictions that limit the damage next time: application restrictions by websites, IP addresses, Android apps or iOS apps, only one type at a time, plus API restrictions on which APIs the key may call.
Not every Google key is a secret. Firebase says its data is protected by Security Rules and App Check, “not by keeping your Firebase API key secret”, and that if your setup follows its guidelines, keys restricted to Firebase services do not need to be treated as secrets. The same Firebase page says the key for the Gemini Developer API “must be protected from public exposure”. A service account key is replaced the same way as other credentials: create a new key, deploy it, disable the old one to check the new one works, then delete the old one.
How to fix it: revoke, replace, and prove the old key is dead
Revoking kills the old key; rotating replaces it with an overlap. After a leak use revocation, with no overlap. The proof is one request with the old key that fails with the provider’s authentication or revoked error, saved with the time. Rewriting git history may not be needed after that, and cannot reach other people’s clones.
To rotate credentials means to replace them on a schedule, with an overlap window in which the old and new values both work. That window is the thing to avoid after a leak. On Stripe, for example, a key rotated in the Dashboard keeps both the old and new keys working for up to 7 days unless you pick Now as the expiry, in which case “the old key is deleted” (see Stripe’s API keys guide).
| Provider | Where to revoke | Does the old key die at once | Where usage and logs show |
|---|---|---|---|
| OpenAI | Security settings, where you view all API keys and revoke compromised ones | ”Revocations of an API key take effect within a few seconds” | The Usage page, once tracking is enabled; keys made before Dec 20, 2023 are not tracked by default |
| Anthropic | Console, API keys page from your profile, the three-dot menu next to the key, Delete API Key | Not stated in Anthropic’s docs | Logs and usage patterns for your keys in the Console |
| Google Cloud and Gemini | Credentials page, the key, Rotate key, then Delete the previous key | Not stated in Google’s docs; a deleted key can be restored within 30 days | Cloud Logging or Security Command Center |
| Stripe | API keys page, the key’s overflow menu, Rotate key, expiration Now | ”If you choose Now, the old key is deleted” | The key’s overflow menu, View request logs (opens Workbench) |
| Supabase | Settings, API Keys: delete a secret key; deactivate legacy service_role keys | Deleting a secret key can’t be undone; deactivating legacy keys is reversible; timing not stated in Supabase’s docs | The Logs page (API Gateway and Postgres events by default); no per-key filter is listed |
| AWS | IAM, Users, the user, Security credentials, Access keys, Actions, Deactivate, then Delete | Apps still using a deactivated key stop working; it can be reactivated | The key’s Last used information |
| GitHub personal access tokens | Settings, Developer settings, Personal access tokens, Fine-grained tokens or Tokens (classic), Delete | Not stated in GitHub’s docs | Not stated for personal accounts; an Enterprise Cloud organization’s audit log can be searched by token |
Each row comes from the provider’s own documentation, checked on September 28, 2026.
Two providers deserve a note. Supabase’s API keys guide has you create the new secret key and confirm every component uses it before deleting the old one, because deletion can’t be undone; a legacy service_role key is deactivated instead, which is reversible. AWS documents a deactivate-then-delete order that suits a leak: deactivating stops the key, and you can reactivate it if you find a tool you missed. When an IAM user’s keys have been compromised or exposed publicly, AWS may apply AWS’s quarantine policy for exposed keys, which denies actions such as ec2:RunInstances; the policy text says “Do NOT remove this policy” and points you to the support case AWS created. The same policy also denies iam:UpdateAccessKey and iam:DeleteAccessKey to the user it is attached to, so that user cannot deactivate or delete its own key: run the table’s steps signed in as an IAM administrator, and follow the support case’s instructions.
After the swap, the app may throw an “invalid API key” error where an old value is still cached in a second place, such as a preview environment or a background worker. Tracking that down is covered in which of your keys broke, and where it lives.
Then prove the old key is dead. For OpenAI, one call to the models list with the old key is enough:
date -u
curl https://api.openai.com/v1/models \
-H "Authorization: Bearer sk-OLD-KEY-EXAMPLE-NOT-REAL"A revoked key should come back with a 401; OpenAI lists “You are using a revoked API key” as one cause of “401 - Invalid Authentication”. Save the output and the timestamp next to your notes. For another provider, the same test is any read-only call from its API reference, sent with the old key.
Only then turn to the repository. Rotating credentials after an accidental commit is what makes the old commit harmless: the value stays in the history and no longer works. If you still rewrite the history, GitHub’s guidance on removing sensitive data warns that the commits may still be accessible in clones or forks, through cached views on GitHub, and through pull requests that reference them. Before closing the incident, check the rest of the history for other keys with secret scanning for a small app.
If the usage page shows calls you did not make, send the provider’s support team the time range from step 4 and ask whether the charges can be reviewed. Treat any adjustment as their decision, not a given. Doing this swap calmly on a normal day, before anything leaks, is how to rotate API keys safely.
How to stop it happening again
- 01 Turn on push protection and add a pre-commit secret scan, so the next key never reaches the remote.
- 02 Keep keys only in the host environment store, never in files an AI agent edits.
- 03 Set a usage ceiling and a spend alert on every metered key, so a leak costs a known maximum.
- 04 Use restricted keys wherever the provider offers them (scoped permissions, allowed IPs or referrers), so a leaked key can do less.
On GitHub, push protection for users is on by default and stops you pushing secrets to public repositories; push protection for a repository requires GitHub Secret Protection to be enabled. Stripe, for one, recommends restricted keys for server-side code “to limit the damage to your business if your keys are ever exposed or compromised”. The ceiling for each provider is set out in how to cap monthly usage on a metered API.
If customer data was reachable with the key, the incident is bigger than this page. Keep the logs you pulled in step 4, and get advice on whether you have to notify anyone.
Common questions about a leaked API key
Is it safe to put a secret API key in a public GitHub repository?
No. Treat a secret key in a public repository as leaked from the moment it is pushed, since GitHub scans public repositories by default and advises providers to treat what it reports as compromised. Making the repository private later only narrows who can still read it.
Can I amend an already pushed commit?
Yes, with a force push, but it does not unleak the key. GitHub says rewritten commits may still be reachable in clones, forks, cached views and pull requests that reference them, so revoke the key first and treat the amend as tidying.
What can someone do with your OpenAI API key?
Someone holding your OpenAI API key can call the API as you, with the usage counted against your organization’s quota and billed to you, until a hard spend limit stops it or the key is revoked. Per-key usage shows on the Usage page once tracking is enabled, and OpenAI’s production best practices cover spend alerts and hard limits.
How to reset credentials in git?
Resetting credentials in git means clearing the login git stores for your host, which is separate from a key committed in your code. Git keeps that login in a credential helper: cache holds it in memory for a short time, store keeps it on disk indefinitely, and git-credential-osxkeychain, git-credential-libsecret and Git Credential Manager keep it in secure storage. Each helper has an erase operation, which git credential reject asks it to run.
Fixing the bug in this guide gets you past today. If you would rather have the whole foundation checked and built in one go, that is what the sprint below is for.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase