API Key Leak Response Playbook Template

A leaked API key is a working credential in someone else's hands, and deleting it from the place it leaked does nothing to stop its use. API keys for payment, messaging, model, mapping, monitoring and data services leak through commits, client-side code, CI logs, tickets, chat and screenshots, and many of them carry no user identity, no expiry and broad permissions. This playbook template gives a repeatable response for any API key, whatever the provider: confirm whether it is real and active, revoke or rotate it in an order that avoids outages, review what it was used for, and close the route it leaked through. It is for security operations, platform and development teams, with decision points for the incident manager. Replace the bracketed text before adoption.

How to use this template

Replace text in square brackets, such as [Organisation], [Key Owner] and [SIEM], with your own names. "Must" is mandatory; "should" is recommended.
Decision points are marked D1 to D5. Record each decision, who made it and when.
This is the API key branch of the Leaked Credential Response Playbook. Use the Cloud Access Key Leak Playbook for cloud provider access keys, and provider-specific pages such as AI model provider API keys or Payment API keys beyond Stripe for console steps.
Keep a short provider annex (section 10) for each service whose keys [Organisation] holds: where to revoke, where usage logs live, and whether the provider supports two active keys.

1. Scope and triggers

1.1 This playbook applies when an API key, token or client secret issued to [Organisation] by any service provider, or issued by [Organisation] to its own API consumers, is, or may be, visible to anyone who should not hold it.

1.2 Triggers:

A secret scanning alert. GitHub secret scanning covers the full Git history on all branches, plus issues, pull requests, discussions, wikis and secret gists; for partner key formats in public repositories, GitHub sends the match directly to the provider through its secret scanning partner program.
A provider notification that a key was found exposed, or that it has been disabled.
An internal scanner hit in code, container images, CI logs, tickets, chat or documents.
A key visible in shipped client-side code: a web bundle, a mobile app or a browser extension.
Unexpected usage, spend or rate limit errors on a provider account.
A canary key firing, or a researcher or customer report.

1.3 Relevant ATT&CK techniques: T1552.001 Credentials In Files and T1213.003 Code Repositories (how keys are found), T1550.001 Application Access Token (their use) and T1496.004 Cloud Service Hijacking (paid services consumed at your cost). The OWASP Non-Human Identities Top 10 2025 lists this risk as NHI2 Secret Leakage, and NHI7 Long-Lived Secrets explains why an old key is worth more to an attacker.

2. Roles and contacts

Role	Responsibility	Named contact
[Incident Manager]	Owns the incident, decisions D1 to D5 and the timeline	[Name, phone]
[Key Owner]	Knows what uses the key, creates and deploys the replacement	[From secrets inventory]
[Provider Account Admin]	Has rights in the provider console to revoke keys and export usage logs	[Name per provider]
[SOC Analyst]	Triage, usage review, evidence export	[Rota]
[Source Control Owner]	Removes the exposure, decides on history rewrite, checks forks and caches	[Name]
[Legal and Privacy]	Notification decisions where data was reachable	[DPO, counsel]

2.1 Each provider account must have at least two named administrators who can revoke keys, so a response never waits for one person.

3. Validate: is it real, whose is it and is it live?

Capture the exposure as evidence: URL or path, commit hash, file, line and timestamp, and a screenshot. Find the commit that introduced it (git log -S on the key prefix) to date the first exposure.
Identify the provider and key type from the prefix or format, the surrounding code and the secrets inventory. Distinguish secret keys from keys designed to be public (for example publishable or client-side keys that the provider restricts by referrer or app), and test keys from live keys.
Find the owner and account: the [Key Owner] and the provider account or project it belongs to. Use CODEOWNERS, deployment records and the inventory.
Check whether the key is active without creating noise: the provider console's key list or last used information, or the validity check result where your scanning tool offers one. GitHub's validity checks may contact the issuing service to see whether the credential has been revoked. Do not test a key by calling business APIs from a personal device: it pollutes the usage logs you need for the review.
Size the permissions: scopes, restrictions (IP, referrer, app, API), environment (production or test), and whether the key can create other keys or users.

D1: Severity. Critical: active live key, publicly exposed, with write, payment, data export or key management permission, or any evidence of use from an unknown source. High: active key, public exposure, read-only; or internal exposure with broad permissions. Medium: internal exposure, narrow scope, no use. Low: confirmed test key, or a key already revoked before exposure. A public, active key is never below High, because removing it from the repository does not remove copies.

4. Revoke or rotate

D2: Revoke now or rotate first? GitHub's remediation guidance says the most important step is revoking the secret with the provider, and that deleting it, pushing a new commit or recreating the repository does not prevent the secret from being exploited. For Critical, revoke immediately and accept the outage. For High and Medium, rotate first if the replacement can be deployed within [1] hour, then revoke.

Provider capability	Response pattern	Watch for
Two keys can be active at once	Create new key, deploy, deactivate old, verify, delete old. AWS documents this sequence for access keys and advises deactivating rather than deleting first, so the old key can be reactivated if something breaks	Do not leave the old key active "for a few days" when it is public
Single key, "roll" or regenerate	Regenerate and deploy the new value in one change window	Outage for every consumer until deployment completes
Key with optional expiry on roll	Set the shortest overlap the deployment allows	Overlap is attacker time too
Restrictable key (IP, referrer, app, API)	Rotate, then add restrictions to the new key	Restrictions reduce damage but do not replace rotation
Key issued by [Organisation] to its own API consumers	Revoke at your gateway or key store, notify the consumer, issue a new key	Consumers whose key leaked from their systems need their own investigation

4.1 Rotate any credential that sat next to the key in the same file, log or message: database passwords, webhook signing secrets and other keys are often leaked together.

4.2 Rollback: if a rotated key breaks a service, deploy the new key to that service. Do not reactivate a publicly exposed key.

5. Review usage

5.1 Review all activity from the first exposure time, not from detection time. Exposure windows can be long: the Toyota T-Connect key sat in a public repository for about five years before the server's key was changed.

Question	Where to look	Signal of misuse
Was the key used after exposure?	Provider usage logs, last used date, request logs	Use after first exposure from sources other than your services
From where?	Source IP, user agent, region in provider logs	Hosting providers, VPN exit nodes, unfamiliar regions
What did it do?	Endpoints called, objects read or changed, exports	Bulk reads, list or export calls, configuration changes
Did it create persistence?	Provider audit log	New keys, users, webhooks, OAuth apps or forwarding rules
What did it cost?	Billing and quota dashboards	Spend spikes, especially on model or messaging services
Was it only validated?	Low-volume calls to identity or account endpoints	A single "who am I" style call from an unknown source shortly after exposure

5.2 Validation-only use still means the key was found and tested; treat it as compromised. See Leaked Secret Validation Detection. Leaked keys are also used by automated agents: in the OpenAI agents and Census API keys case, AI agents used developer keys posted in public repositories as a routine step in a task.

D3: Data impact. If the key could read personal or confidential data and use by an unknown party cannot be ruled out, the [Incident Manager] escalates to [Legal and Privacy].

6. Remove the exposure and close the route

Remove the key from where it leaked after evidence is captured: repository, image, log, ticket, chat. Ask platform administrators to purge caches and search indexes where available.
D4: Rewrite history? The OWASP Secrets Management Cheat Sheet notes that rewriting Git history can scrub secrets but breaks links to existing commits; GitHub calls it destructive and disruptive. Rewrite only when the key cannot be revoked or the repository will stay public; revocation always comes first.
Find other copies: forks, mirrors, package registries, built artefacts, backups and other repositories of the same team.
Fix the cause: move the key to a secrets manager or runtime injection, turn on push protection, keep secrets out of client-side code by having the server add the credential (as Google's API key guidance advises), and send keys in headers rather than URL query strings so they do not land in logs.

7. Recovery

Confirm the old key fails at the provider and that all services run on the new key.
Apply restrictions to the new key: least privilege scopes, IP, referrer or app restrictions, and an expiry where the provider supports it.
Add the key to monitoring: usage and spend alerts at the provider, and a detection in [SIEM] for use of the revoked key, which the OWASP cheat sheet recommends logging.
Update the secrets inventory with the new key, owner, location and rotation date.

8. Communication and notification

Internal: key owner, service owners and [Incident Manager] updates at agreed intervals.
Provider: report misuse and ask for usage logs not visible in the console, and for billing review where spend was fraudulent.
Regulators and individuals: where personal data was accessed, apply the relevant regime; under GDPR Article 33 the controller notifies the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. See the Data Breach Notification Checklist.
API consumers: where [Organisation] issued the key, tell the consumer what was exposed and when the key stops working.

D5: External notification. [Legal and Privacy] decides and records the reasoning.

9. Post-incident review

9.1 Within [10] working days, record: time from first exposure to detection, detection to revocation, how the key leaked, whether it was in the inventory with an owner, whether the provider supported zero-downtime rotation, and what was found in the usage review. Assign actions with owners and dates. Close the scanning alert as revoked.

10. Provider annex

10.1 Complete one row per provider before an incident and test it yearly.

Provider	Key types and prefixes	Revoke or roll location	Two active keys?	Usage and audit logs	Admins
[Provider]	[Secret, publishable, test]	[Console path or API]	[Yes or no]	[Where and retention]	[Two names]

Implementation guidance

Rollout. Phase 1: inventory API keys with owner, provider, location and last use; see the API Key Management Guide. Phase 2: complete the provider annex and test revocation and rotation of a non-production key, which is your rollback rehearsal. Phase 3: turn on push protection and route scanning alerts and provider notifications into [SIEM]. Phase 4: automate D2 for Critical cases (revoke on alert) for providers with reliable key APIs. A small organisation should start with the inventory and push protection; a large one should automate triage and feed key usage logs centrally.

Framework mapping.

Area	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Key inventory and lifecycle	PR.AA-01, PR.AA-05	IA-5, AC-2
Usage review	RS.AN-03	AU-6
Containment and eradication	RS.MI-01, RS.MI-02	IR-4
Detection	DE.CM-09	SI-4

Metrics. Mean time from detection to revocation (target under [1] hour for public keys); mean time from first exposure to detection; share of leaks blocked by push protection before publication; share of API keys with a named owner; share of providers with a tested annex row; active keys unused for 90 days.

Common failure patterns.

Deleting the commit and closing the alert while the key stays active.
Reviewing usage only from the detection date, missing months of exposure.
Testing the key from a laptop and then mistaking that call for attacker activity.
Rotating the key but not the database password in the same file.
Treating a key in a mobile app or web bundle as private and leaving it unrestricted.

API Key Leak Response Playbook: Validate, Revoke, Rotate and Review Usage