JIJI LABS
SHIPSAFE All guides Mac App Store

SHIPSAFE guides / Guide

Developer guide

Leaked an API key on GitHub: what to do in the first hour

You just noticed a key in a commit, maybe a public repo, maybe a private one. Do not start by rewriting git history. Start by making the key useless, then look for damage, then clean up.

By Ilyas A. Almadani · Updated October 22, 2026 · Steps checked against the vendors' official documentation, linked at the end

The short version
  1. Treat the key as already stolen. Deleting the commit does not undo that.
  2. Revoke or rotate the key with the provider (not just in GitHub).
  3. Check the provider's usage and logs for activity you do not recognise.
  4. Put the new key in an environment variable or secret store and redeploy.
  5. Only then clean the repository, and turn on push protection.

Assume the key is compromised

GitHub's own guidance is to treat any leaked secret as already compromised, because removing it from the code does not stop someone who already copied it. Automated scrapers watch public repositories, and Stripe notes that even private repositories can be exposed through development environments. You do not need proof that anyone used the key. Rotate it anyway.

Step 1: Revoke or rotate the key at the provider

GitHub calls this the most important remediation step: revoking the secret with the secret's provider. Open the provider's dashboard (Stripe, OpenAI, Anthropic, Google Cloud, AWS, Slack, and so on), delete or roll the leaked key, and create a replacement.

  • If production traffic depends on the key, create the new key first, switch your app to it, then revoke the old one. For a key that is actively being abused, revoke immediately and accept a short outage.
  • Provider-specific walkthroughs: Stripe, OpenAI, Anthropic and Gemini.
  • Some providers also react on their own. Anthropic, for example, takes part in GitHub's secret scanning partner program and deactivates keys that GitHub finds in public repositories. Do not wait for that. Revoke it yourself.

Step 2: Check for abuse

Look at the provider's usage and audit logs for the window between the commit time and the revocation. You are looking for requests from places or at volumes that do not match your app, new resources you did not create, and unexpected charges. GitHub also suggests reviewing its audit logs for events related to the secret.

  • Find when the key was committed: git log -S "the-key-prefix" --all --oneline (use only the first few characters).
  • Note the time. It marks the start of the exposure window.
  • If you see abuse, follow the provider's incident steps and contact their support.

Step 3: Replace the key everywhere it ran

Search your whole project and your CI settings for the old value. Put the new one in an environment variable or your host's secret store, never in source files, then redeploy. Check these easily forgotten places: CI logs and variables, Docker images and build args, local .env copies on teammates' machines, mobile app builds that already shipped, and shared notes or chat messages.

A quick way to find the rest

A leaked key is rarely alone. SHIPSAFE, a Mac app that runs entirely on your machine, scans the files of a project folder for keys in known formats, hard-coded passwords, private keys and committed .env files. It reads the current files, not your git history, so it will not find a key that only exists in an old commit. See it on the Mac App Store.

Step 4: Clean the repository (optional once the key is dead)

Once the key is revoked, the old commit is only a leftover. Removing it from history is still good hygiene, but it is disruptive: it rewrites commit hashes and needs a force-push. GitHub says to weigh it with your security lead before doing it. The full procedure is in How to remove a .env file from git history.

Forks, other clones and cached views can keep the old commit alive. That is one more reason to rely on revocation, not on deletion.

Step 5: Make the next leak harder

  • Add .env and other secret files to .gitignore and commit that change.
  • Turn on GitHub push protection, which blocks pushes that contain recognised secrets.
  • Add a pre-commit hook with a scanner such as gitleaks or git-secrets.
  • Stage files by name instead of git add ., and read git diff --cached before committing.
  • Keep real keys out of code that AI coding tools generate. Ask them to read from environment variables, and review what they commit. See the pre-release checklist for AI-built apps.

A sensible order for the first hour

  1. Revoke or rotate the key at the provider.
  2. Deploy the replacement from a secret store.
  3. Read the usage and audit logs for the exposure window.
  4. Search the project, CI and old builds for other copies.
  5. Turn on push protection, then plan the history cleanup.

Frequently asked questions

Is deleting the commit or the file enough?

No. Anyone who cloned, forked or scraped the repository while the key was visible still has it. Only revoking the key at the provider makes it useless.

Do I need to rewrite git history after I rotate the key?

Not to stay safe. Once the key is revoked, the old value cannot be used. Rewriting history is optional cleanup, and GitHub warns it is disruptive because it needs force-pushes and changes commit hashes.

Will the provider revoke a leaked key for me?

Sometimes. Anthropic deactivates keys that GitHub finds in public repositories, and Stripe says it may notify you or deactivate a key it detects. Neither is guaranteed, so revoke the key yourself.

Official documentation used for this guide

Vendor interfaces change. If a menu looks different, follow the linked documentation.

More guides

How to remove a .env file from git historyRotate first, then git filter-repo or BFG, then a careful force-push.Stripe secret key exposed: roll it and check for abuseRoll the key, read the logs, check charges and payouts, then restrict it.AI API key leaked (OpenAI, Anthropic, Gemini): revoke, set spend limits, check usageDelete the key, cap spending, read the usage, and replace it safely.

See all SHIPSAFE guides

Check your project before the next release

SHIPSAFE scans a project folder on your Mac for leaked keys and risky release settings, and shows the file, the line and a suggested fix for each finding. It runs 100% locally, with no upload and no account. It is a review assistant, not a guarantee of security.

Get SHIPSAFE on the Mac App Store
SHIPSAFE findings list showing the file, line and evidence for each issue