Nexus Void Research
Leaked API Key, Secrets, Git History, Key Rotation, Incident Response, DevSecOps
Leaked API Key? What to Do: Rotate First, Then Clean Git History
Leaked an API key? Deleting the commit is not enough. Revoke or rotate it first, check logs for attacker-created keys, then decide on git history cleanup.
If you leaked an API key, revoke or rotate it first, then work out what it touched, and only then decide whether to clean it out of your git history. Deleting the commit does not make a leaked key safe: anyone who already cloned, forked or cached the repository still has it. Rotation is the fix; history cleanup is housekeeping.
Last updated 4 November 2026.
Leaked API keys are now one of the most direct routes into a company's cloud. On November 3, 2026, Google Threat Intelligence Group and Mandiant reported that attackers using stolen cloud credentials and LLM API keys ran up fraudulent charges above $100,000 in a single day, with cumulative charges reaching $1 million at some organizations. The keys came from places every engineering team recognizes: exposed service account keys, GitHub personal access tokens, and API keys committed to public GitHub repositories. This runbook is the order of operations we recommend when it happens to you. For finding keys before they leak, see how to find hard-coded secrets in code.
Does deleting the commit remove a leaked API key?
No. A new commit that deletes the key leaves it in every earlier commit, so anyone can read it with git log -p. Rewriting history with a tool like git-filter-repo removes it from your copy, but not from clones, forks, CI caches, package registries or search engines that already picked it up. GitHub's own documentation on removing sensitive data from a repository is blunt about this: if the data is a password, token or credential, the first step is to revoke or rotate it, and once it is rotated "that may be sufficient to solve your problem." GitHub also warns that rewriting history has real costs, including changed commit hashes, broken diffs on closed pull requests, lost commit signatures, and a high risk of a teammate re-pushing the old history with a single git pull and git push.
Assume a key was copied the moment it became public. Automated scanners watch public commits continuously, so the useful question is not "did anyone see it?" but "what could it do, and what did it do?"
What should you do in the first hour after leaking an API key?
Work in this order. Each step reduces the damage the key can do before you spend time on the next.
Step | Action | Why it comes here |
|---|---|---|
1 | Revoke or rotate the key at the provider | Stops new use immediately; everything else is cleanup |
2 | Deploy the new key from a secret manager, not code | Avoids leaking the replacement the same way |
3 | Pull the provider's usage and audit logs for the key | Shows whether it was used, from where, and for what |
4 | Check for persistence the attacker may have created | New keys, users, service accounts or tokens survive rotation |
5 | Check spend and set alerts | AI and compute abuse shows up in billing within hours |
6 | Decide whether to rewrite git history | Only after the key is dead; often optional |
7 | Add push protection and pre-commit scanning | Stops the next leak at the source |
Step 4 is the one teams skip. In the LLMjacking cases Google described, attackers used their first foothold to create additional API keys and backdoor service accounts disguised as billing utilities. Rotating the leaked key does nothing about credentials the attacker minted while they had access. On AWS, that means reviewing CloudTrail for CreateAccessKey, CreateUser and policy changes made by the leaked identity; AWS's access key guidance covers rotating and deactivating keys. On Google Cloud, look for new service account keys and IAM bindings.
How do you rotate a leaked API key without downtime?
Most providers let a key and its replacement exist at the same time, which makes a zero-downtime rotation possible. Create the new key, store it in your secret manager, deploy it to every service that uses the old one, confirm traffic is flowing on the new key, then revoke the old one. If you cannot find every consumer quickly, revoke anyway and accept a short outage. A brief failure is cheaper than an attacker holding a working credential while you search. The OWASP Secrets Management Cheat Sheet recommends automating rotation for exactly this reason: teams that rotate regularly already know where every key is used.
Better still, remove long-lived keys where you can. Cloud workloads can usually authenticate with short-lived credentials instead of key files, through IAM roles on AWS or workload identity federation on Google Cloud. A credential that expires in an hour is a much smaller problem when it leaks.
When should you remove a secret from git history?
Rewrite history when the repository is public or widely shared and the leaked value is something you cannot rotate, such as personal data, a private certificate you cannot reissue quickly, or a secret that also reveals internal structure. For a rotated API key in a private repository, rewriting history is often more disruptive than useful. If you do rewrite it, GitHub's guidance is to use git-filter-repo, coordinate with everyone who has a clone, have collaborators rebase rather than merge, and then contact GitHub Support to remove cached views and dereference affected pull requests. Forks that already contain the key are outside your control, which is one more reason rotation has to come first.
How do you stop API keys leaking in the first place?
Block them before they reach the remote. GitHub push protection rejects pushes that contain supported secret types, and secret scanning alerts on ones already in a repository. Add a pre-commit hook so developers catch keys on their own machine, keep .env files in .gitignore, and load secrets from a secret manager at runtime. AI coding assistants raise the stakes, because an agent that reads a .env file can paste its contents into code, logs or a prompt. Treat agent sessions as another place a key can leak; see AI agent and LLM security risks in 2026 for controls.
Where ARGUS fits
ARGUS checks every pull request for secrets alongside code, dependency and infrastructure-as-code findings, and each secrets finding shows whether the key is live, rotated or a test value. That status is what tells you whether step 1 of this runbook is urgent or already done. It is not a replacement for provider-side audit logs: ARGUS sees your code, not what an attacker did with a key after it leaked. See how ARGUS works.
Frequently asked questions
What happens if you leak an API key on GitHub?
Assume it is found within minutes. Automated scanners watch public commits, and attackers use leaked cloud and AI keys for data access, compute abuse and LLMjacking, sometimes running up six-figure bills in a day. Revoke the key immediately, then review its usage logs.
Is a leaked API key in a private repository safe?
Safer, not safe. Anyone with read access, any compromised developer account and any CI system with a clone has it. A stolen GitHub token gave an attacker access to private repositories in one of the cases Google described. Rotate it.
Do I need to rewrite git history after rotating a key?
Usually not for a rotated API key in a private repository. Rewrite history when the repository is public and the data cannot be rotated, and follow GitHub's coordination steps if you do.
How do I know if a leaked key was used?
Check the provider's audit logs for the key's identity: API calls, source IP addresses, new keys or users created, and billing for the period since the leak. On AWS, CloudTrail shows every API call made with the key.
Our read
The misconception that sinks teams is that a leak is a git problem. It is a credential problem that happens to start in git. Kill the key, read the logs, look for anything the attacker created, and only then tidy the history. The LLMjacking numbers make the timing concrete: when stolen keys can cost $100,000 in a day, the hour you spend rewriting history before rotating is the expensive hour.
Related reading: What is a software supply chain attack? · How to secure a CI/CD pipeline on GitHub Actions · LLMjacking: stolen cloud keys run up $1M in AI charges
DATA SOURCES
GitHub Docs: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository ; Google Threat Intelligence: https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models ; OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html