Production API key leaked

Your preparation

0 of 0 safeguards ready

Incident worksheet

Make the next decision with evidence

Stop the credential at its issuer, determine what it could do, and prove every legitimate consumer moved to a safer replacement.

EvidenceDecisionActionProof

Capture before evidence disappears

Save the provider, key identifier, permissions, owner, creation time, last-use time, source IPs, user agents, and the first place the value appeared.
Preserve secret-scanning alerts, Git commits, build artifacts, CI logs, chat or ticket links, and provider audit events for the full exposure window.
List every workload that uses the key. Record its deployment, environment, secret name, last successful call, and replacement status.
Export billing, data-access, configuration-change, and outbound-message activity that the key could authorize.

Decisions that change the response

Question	Act when	Action
Revoke now or stage a replacement?	The key can expose data, spend money, change production, or its use is unknown.	Revoke immediately. Accept a controlled outage rather than leaving the capability available.
Treat this as a data incident?	Logs show reads, exports, enumeration, or the provider lacks adequate access logs.	Open a privacy/security incident and scope the data the key could reach.
Rewrite Git history?	The value is revoked but policy, scanners, forks, or redistribution make removal useful.	Remove it after revocation. Coordinate force-push effects and keep forensic references.

Proof that recovery worked

A direct request using the old key fails at the issuing service, not only inside your application.
Every known workload succeeds with a uniquely named, least-privilege replacement.
Provider logs are reconciled against expected callers, actions, data access, and spend for the complete exposure window.
A repository and artifact scan finds no usable copy of the replacement credential.

Controls to put in place

Use workload identity or short-lived credentials instead of static keys where the provider supports it.
Give each environment and workload a separate credential with a named owner and expiry date.
Enable secret scanning, push protection, client-bundle scanning, and high-risk provider usage alerts.
Keep a tested zero-downtime rotation procedure beside the service inventory.

Tabletop drill

Leak a harmless test credential in a private training repository. Time how long it takes to identify the issuer, revoke it, rotate one consumer, find its audit events, and prove the old value fails.

Escalate when

Contact security specialists, the provider, your insurer, and qualified privacy counsel when the key could expose regulated data, sign releases, move money, control infrastructure, or when logs cannot establish misuse.

What this means

Assume a publicly exposed key was copied immediately. Deleting the file or message does not revoke the credential.

Warning signs

Secret scanning reports a token in code, an issue, logs, or chat.
API usage, location, cost, or actions are unfamiliar.
A provider automatically revokes a detected credential.
A build artifact or client-side bundle contains a server secret.

Recover now

First 15 minutes

Identify the issuing provider, permissions, and exposure window.
Revoke the key at the provider. Do this before cleaning Git history or screenshots.
Create a replacement with the smallest required permissions.
Search provider logs for use during the exposure window and preserve evidence.

Today

Update every legitimate consumer and confirm the old key fails.
Search repositories, logs, artifacts, tickets, and backups for related secrets.
Investigate actions performed with the key and contain downstream impact.
Remove the secret from current content; rewrite history only when its continued presence creates a separate risk.

Verify recovery

The old credential is rejected by the issuing service.
All legitimate workloads use the replacement.
Unauthorized actions and resulting data exposure are understood.
Secret scanning and push protection cover the affected location.

Prepare now

Access

Production keys are least-privilege, named, and short-lived where possible.
Client-side code never receives server credentials.

Backups and evidence

Provider audit logs are retained long enough to investigate a leak.

Contacts and ownership

Every key has an owner and documented revocation location.

Practice

A test key has been rotated without downtime.

Common mistakes

Deleting the commit but leaving the key active.
Rotating only the visible key when related credentials were exposed.
Putting the replacement into the same unsafe channel.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.