A leaked API key is a quiet incident. There might be no login prompts, no password reset emails, and no visible signs until the attacker has already copied data or changed infrastructure.
Rule of thumb: assume a leaked secret is already compromised. Rotate first, investigate second.
Immediate containment (first hour)
- Revoke or disable the exposed secret as fast as possible. Do not wait to confirm abuse.
- Rotate credentials safely: create a replacement, deploy it, then invalidate the old one.
- Check for automation and integration breakage (CI jobs, webhooks, serverless functions). Restore service using the new secret.
- Start an evidence timeline: where the leak happened, when it was introduced, when it was rotated.
If you are a small team and this is already affecting customer data or core operations, use what to do if your business or employees are hacked to keep containment and communication decisions structured.
Classify what leaked, because response depends on it
Not all secrets have the same blast radius. The fastest way to avoid over-rotating or under-rotating is to classify the secret.
| Secret type | Typical leverage | Containment priority |
|---|---|---|
| Cloud provider keys | Infrastructure access, data access, billing risk | Highest |
| Database credentials | Direct data theft or destruction | Highest |
| Payment processor tokens | Fraud or payout redirection (depending on scope) | High |
| Webhook or signing secrets | Forged events, business logic abuse | High |
| OAuth client secrets | Token abuse or impersonation in some flows | Medium to high |
Map the blast radius instead of guessing
Once rotation is in progress, answer three questions.
- What could this secret do? Read data, write data, create users, change infrastructure, trigger payments.
- Where was it used? Which repos, which CI workflows, which services, which environments.
- What can an attacker do next? Pivot from the secret to accounts, sessions, and administrative access.
Attackers often chain technical access into identity access. If a leak could enable takeover of admin accounts or token minting, treat it as an account takeover risk, not only a "developer mistake".
Investigate for misuse without delaying containment
Investigation should be evidence-driven. Common high-signal indicators include:
- Unexpected API calls or unusual geographic access patterns
- New resources created (users, service accounts, keys, tokens)
- Changes to logging, retention, or security settings
- New integrations, webhooks, or connected apps you did not authorize
If a secret can create access tokens or alter identity flows, also audit connected applications and grants. OAuth-related persistence is a common confusion point; see OAuth for the defensive model.
Containment that reduces repeat incidents
Leaked secrets are usually a symptom of a broader control gap. The durable fix is to make secrets harder to leak and easier to rotate.
- Prefer scoped secrets with least privilege. Separate read-only from write and admin permissions.
- Separate environments: do not reuse production secrets in development.
- Centralize secret storage so rotation is one controlled operation, not a hunt across scripts.
- Design rotation as a routine: if rotating breaks everything, you will avoid rotating and attackers will benefit.
For small teams, this is part of control-plane discipline. The resilience framing in defeat hackers as a business is a good mental model: protect the accounts and keys that can reset everything, and make recovery predictable.
If you want a broader business baseline that connects secrets, identity, backups, and finance verification, keep how to protect your business from hackers as a reference.
A secret leak is painful mostly because it is invisible. The right response makes it visible: rotate quickly, measure what the secret could do, and verify what changed.
Once that is done, the incident is no longer "did someone use it". The incident becomes "can anyone still use it" and "what evidence do we have". That shift is what closes the event.
Teams that handle leaks well do not rely on perfect prevention. They rely on fast rotation, minimal privilege, and logs that answer the basic questions quickly.