API key leaked: what to do, step by step

MacWindowsUpdated

If an API key has leaked, revoke or rotate it before anything else. GitHub's documentation says that when a secret has been committed, "as a first step you need to revoke and/or rotate that secret". Deleting the file or the commit doesn't stop the key working.

Quick answer

Revoke or rotate the leaked key in the provider's dashboard straight away, create a new one, and update your app to use it. Then check your usage and billing for activity you don't recognise, contact the provider if you find any, and remove the key from your code history. Keep keys in environment variables, never in code.

What should I do first if my API key leaked?

Kill the key, then replace it. Removing it from a repository isn't enough. LiteLLM's account of its October 2026 incident says a key committed to a public repository on 27 May 2026 stayed valid for more than four months, and the commit stayed in public history even after the file was deleted. In its words: "Because of human error, nobody followed through on revoking the administrative key."

  1. Revoke or rotate the key with the provider (Google's steps are below; for any other service, check your provider's own documentation for its revoke steps).
  2. Create a new key and store it safely.
  3. Update and redeploy anything that used the old key.
  4. Check usage and billing for activity you don't recognise.
  5. Then clean up the code and its history.

Google suggests a slightly different order for production apps: create and deploy the replacement first, then disable the leaked key once the new one works, to avoid downtime.

How do I revoke a Gemini or Google AI Studio API key?

Google's steps for a leaked Gemini API key:

  1. Generate a new key in Google AI Studio or the Google Cloud console.
  2. Update your app and deploy the code that uses the new key.
  3. Disable the leaked key in the Cloud console once the new key is verified.
  4. Audit activity: check billing logs and API usage in the Cloud console for unauthorised activity.

Google warns that if a key is compromised, others can use up your project's quota and run up unexpected billing charges. It says to treat a Gemini API key like a password.

Google may already have acted. Its troubleshooting guide says a key reported as leaked returns the error "Your API key was reported as leaked. Please use another API key." and can no longer be used with the Gemini API. It says to generate a new key in Google AI Studio and, if a leaked key caused charges, to submit a billing support case.

How can I check whether my API key has leaked?

GitHub's secret scanning runs automatically and for free on public repositories, and scans the entire Git history on all branches for hardcoded credentials. Beyond code, it also scans issue and pull request descriptions and comments, GitHub Discussions, wikis and secret gists. Through its partner programme, when a supported provider's secret turns up in a public repository or a public npm package, GitHub notifies the provider so it can act, for example by revoking the key. Partner secrets go straight to the provider and don't appear in your repository's alerts. GitHub's list of supported patterns includes partner patterns for Google API keys.

If validity checks are switched on, GitHub says secret scanning may contact the service that issued a secret to find out whether it has been revoked, which helps you deal with live keys first. For private and internal repositories owned by an organisation, secret scanning needs GitHub Secret Protection on GitHub Team or GitHub Enterprise Cloud.

GitHub also has push protection for users, switched on by default, which stops you pushing secrets to public repositories on GitHub.com. When it finds one, it blocks the push and explains why; you remove the sensitive information and push again. It looks for provider-specific credentials, generic secrets such as private keys and database connection strings, and custom patterns you define. By default, anyone with write access can bypass a block by giving a reason, one of which is "I'll fix it later".

How do I remove a leaked key from Git history?

Only after the key is revoked. GitHub's guidance explains why rewriting history is a cleanup step, not a fix:

  • You can't remove data from other people's clones of your repository.
  • If the commit exists in a fork, it stays accessible there.
  • After a force push, old commits can still be reached by their hashes in cached views on GitHub until GitHub Support removes them.
  • Rewriting history changes commit hashes, which can break tooling, and collaborators with old clones can push the data back.

Once a revoked key can no longer be used, GitHub notes that may solve the problem without rewriting history at all.

What has a recent AI-tool incident shown?

One incident in 2026, in the company's own words.

LiteLLM, 21 October 2026. LiteLLM says its release pipeline was compromised and pushed version 1.107.0 to PyPI and Docker with "compiled malware which steals credentials and loads remote-code execution tools". The PyPI package was live from 11:39 to 13:23 UTC on 21 October. LiteLLM says all previous versions are safe and recommends pinning to 1.106.2. If 1.107.0 ran on a host with outbound internet, it says to assume data was taken and rotate every provider key stored in the LiteLLM proxy database, master and virtual keys, the database password and any secret in the environment of processes on that host. LiteLLM's post marks the incident as contained.

How do I stop API keys leaking again?

Google's and GitHub's advice covers most of it:

  • Never put keys in client-side code. Google says not to hardcode keys in web or mobile apps, because keys compiled into client-side code can be extracted by users.
  • Never commit keys. Google says never to check API keys into source control systems like Git, and to read keys from environment variables such as GEMINI_API_KEY rather than configuration files. GitHub's push protection blocks many secrets at the push.
  • Restrict keys. Google lets you restrict a key to the Gemini API only, and says restrictions minimise the damage if a key is compromised.
  • Watch spending. Google suggests billing alerts in the Cloud console, to notify you if usage or costs spike.

More questions

Is an API key in a private repository safe?

Safer, not safe. Google says never to check API keys into source control systems like Git, and to read them from environment variables instead. For private repositories, GitHub says secret scanning matches go to repository admins and the committer, not to the provider.

Will I have to pay for charges from a leaked key?

That depends on the provider. Google says that if a leaked Gemini key caused charges, you should submit a billing support case. For any other service, check your provider's own documentation. Google also suggests setting billing alerts in the Cloud console, so you're notified if usage or costs spike.

My Gemini key returns a 403 saying it was reported as leaked. What now?

Google says a key reported as leaked can no longer be used with the Gemini API. Generate a new key in Google AI Studio, update your integrations, and review how you store keys so the new one stays private.

I installed LiteLLM 1.107.0. What should I do?

Follow LiteLLM's advisory: treat the environment as compromised, remove the malicious files it lists before running pip, reinstall a safe version such as 1.106.2, rebuild images and environments, and rotate every secret the host could reach. Check its blog for updates.

Sources