What to Do When Your API Key Leaks (First 60 Minutes)
2026年10月17日
A leaked API key is a valid API key. It authenticates, it bills, and it does not trip any “suspicious login” alarm. Here is what to do in the first hour — in order.
Minutes 0–5: Revoke, don’t investigate
The instinct to figure out how it leaked before doing anything is understandable and wrong. Investigation is for later. Right now the meter is running.
- Revoke the key immediately in your provider’s console. Not rotate — revoke. Rotation creates a new key but leaves the old one valid for a window.
- Check for sibling keys. If one key leaked, others in the same environment likely leaked with it. Revoke the whole set.
- If you can’t find the key right now, revoke the most recently used ones. The attacker is using a key, and it’s one of yours.
Minutes 5–30: Quantify the damage
Open your provider’s usage dashboard and look at the last 24–48 hours, broken down by model and by hour.
What you’re looking for:
- Which models spiked. In the February 2026 incident, the anomalous usage was concentrated in Gemini 3 Pro Image and Gemini 3 Pro Text — the expensive multimodal models. Attackers route to the most expensive endpoint available because they’re not paying.
- When it started. This tells you how long the key was live and whether the exposure window matches a specific commit, deploy, or log entry.
- Whether it’s still running. If usage is still climbing after revocation, you haven’t found the right key.
Minutes 30–60: Contact the provider — properly
This matters more than most people expect, because the default answer is no. Cloud providers generally treat key compromise as the customer’s responsibility, and the documented case ended with the charges standing.
What makes a difference in the appeal:
- Speed. Contact them the same day. A week later looks like regret, not incident response.
- Specifics. “My bill went up” is weak. “Between 03:14 and 11:52 UTC on February 11, usage from this key rose 8,000% while all other keys stayed flat” is strong.
- Evidence of your own response. Show the revocation timestamp. Demonstrate that you acted as soon as you knew.
- A concrete ask. Ask for a specific outcome: full waiver, partial credit, or a payment plan. Vague appeals get vague answers.
Be prepared for the answer to still be no. That is why prevention and hard limits matter more than appeals.
Hour 1–24: Rotate everything, not just the one
The key you found is rarely the only exposure. Work through this list:
- Environment variables on every machine that ran the app — including laptops
- CI/CD secrets (GitHub Actions, GitLab CI, CircleCI)
- Any AI coding agent’s context or config file (Cursor, Claude Code, Windsurf, Codex, and agent frameworks generally)
- Third-party plugins and MCP servers with filesystem access
- Logs — check whether keys were ever printed and shipped to a logging service
- Shared documents, screenshots, and support tickets
Day 1+: Fix the reason it happened
Once the bleeding stops, the question becomes structural. Most leaks come from a small number of repeating patterns:
- Committed to Git. The most common. Remember that deleting the file does not remove it from history.
- Hardcoded in source. Usually because an AI coding assistant suggested it — and the suggestion looked reasonable.
- In a config file that gets copied.
.envfiles end up in screenshots, zip archives, and shared drives. - Printed in logs or error output. A single debug statement can ship a key to a logging service with a long retention policy.
- Readable by an agent or plugin. Anything with filesystem access can read every credential on the machine. In the OpenClaw ecosystem, a scan of nearly 4,000 skills found 7.1% leaking credentials in plaintext.
A hard limit is not a soft alert
Most providers offer budget alerts. Alerts are notifications — they tell you something is happening while it continues to happen. What the February 2026 incident shows is that notifications were not the missing piece. A cutoff was.
Check today whether your provider’s limit actually stops requests or merely emails you. For most, it’s the latter.
The checklist
- ☐ Revoke the key (not rotate)
- ☐ Revoke sibling keys in the same environment
- ☐ Pull the 48-hour usage breakdown by model and hour
- ☐ Contact the provider the same day, with specifics
- ☐ Rotate every credential that shared an environment with the leaked key
- ☐ Check logs, CI secrets, agent configs, and plugin access
- ☐ Confirm whether your provider’s budget limit is a hard cutoff or just an email