API key leak postmortem template for AI credentials

What goes into a postmortem for a leaked AI API key? A UTC timeline from the first moment the key could have been exposed, through detection, revocation and rotation; the blast radius, stated both as what the key could reach and what it is known to have done; how you worked with each provider; who you had to notify; the financial impact; the control gaps; and actions with owners and dates. Keep it blameless. The template below is ready to copy, followed by guidance for the sections that are specific to AI credentials.

AI credential incidents have a shape of their own. A stolen key is used at the provider, outside every control you run, so the evidence lives in the provider's usage reports rather than your logs. The cost arrives as an invoice. And a provider can respond in ways that hurt you as well as the attacker: reports about the OpenCode Console incident in October 2026 included users saying Google suspended their projects for "abusive activity consistent with hijacked resources", alongside unauthorized charges from several hundred dollars to more than $1,700¹. A postmortem has to cover the security, financial and availability sides together.

For the live response itself, see LLM incident response. This template is for the review afterwards.

The frame: NIST SP 800-61 Rev. 3 and blameless review

NIST SP 800-61 Rev. 3, published in April 2025, replaced the 2012 Rev. 2. It is written as a CSF 2.0 Community Profile, folding incident response into an organization's cybersecurity risk management and aiming to improve "the efficiency and effectiveness of their incident detection, response, and recovery activities"². In practice that means the review should end in changes to how you govern, protect and detect, not only in a closed ticket.

Google's SRE book describes a blameless postmortem as focusing on the contributing causes of an incident without blaming an individual or team, and recording impact, mitigation, root causes and follow-up actions³. For a key leak this matters more than usual. Someone pasted the key somewhere, and everyone knows who. The useful question is why a single paste could spend that much, reach that much, and go unnoticed for that long.

The template

# Postmortem: <short description>, <date>

Status: draft | in review | final       Severity: <your scale>
Incident lead: <name>                   Review date: <date>
Authors: <names>                        Distribution: <who may read this>

## 1. Summary
Three to five sentences: which credential, how it was exposed, what it was
used for, how it was found, how it was stopped, what it cost.

## 2. Impact
- Financial: provider charges attributed to the incident, per provider (estimate
  and invoiced); response costs (people-hours, vendor fees).
- Availability: services degraded or stopped (spend limit reached, project
  suspended, key revoked before replacement deployed).
- Data: what the credential could read; what it is known to have read.
- Customers: affected customers and what they experienced.

## 3. Timeline (UTC)
| Time (UTC) | Event | Source of evidence |
| --- | --- | --- |
| | Earliest possible exposure | |
| | First unauthorized use (provider usage report) | |
| | First signal (alert, invoice, report, provider email) | |
| | Detection confirmed | |
| | Credential revoked at the provider | |
| | Replacement deployed; service restored | |
| | Related credentials rotated | |
| | Provider contacted / responded | |
| | Customers notified (if applicable) | |
| | Incident closed | |
Key intervals: exposure-to-detection, detection-to-revocation,
revocation-to-recovery.

## 4. Blast radius
| Credential | Provider / account / scope | Could reach | Known use | Spend limit at time | Network restriction |
| --- | --- | --- | --- | --- | --- |
Other credentials exposed in the same place (same file, vault, vendor):

## 5. Detection
How it was found, by whom or what. Which signal should have fired first and
why it did not.

## 6. Response
Containment, revocation, rotation and recovery steps, with what went well and
what slowed them down.

## 7. Provider coordination
Per provider: ticket ID, date contacted, what was asked (investigation,
charges, account restrictions), what was answered, open items.

## 8. Notification
Customers, partners, regulators, insurers: decision, reasoning, who decided,
when sent. "Not required" is a decision; record why.

## 9. Contributing factors
Blameless. Conditions, not culprits.

## 10. Control gaps
| Layer | Expected | Actual | Gap |
| --- | --- | --- | --- |
| Key scope | | | |
| Provider spend limit | | | |
| Network restriction | | | |
| Gateway control | | | |
| Detection | | | |
| Revocation | | | |
| Inventory | | | |

## 11. Actions
| Action | Layer | Owner | Due | Status |
| --- | --- | --- | --- | --- |

## 12. What went well
## 13. Open questions

Writing the timeline

Start the timeline at the earliest possible exposure, not at detection. If the key was in a commit, that is the push time; if it was in a vendor's workspace that was breached, it is the earliest time the vendor gives. OpenCode, for example, told affected users that the earliest possible exposure was 2026-10-17 00:30 UTC¹. The interval from exposure to revocation is the window in which the key could be used, and it is the number the actions should shrink.

Use the provider's usage report, grouped by API key and in hourly buckets, for the "first unauthorized use" line; detecting gateway bypass shows the calls for OpenAI and Anthropic. Record every time in UTC with its source, because provider dashboards, billing systems and your own logs often show different time zones.

Stating the blast radius

Write it twice.

Could reach is what the credential was able to do: which account, project or workspace; which models; whether it could read stored resources such as files, batches or conversation state; which networks it worked from; what spend limit applied. This comes from your credential inventory, or from the provider console if the inventory did not have the row (which is itself a finding).

Known use is what the evidence shows it did: requests, tokens, models, times, source networks if the provider gives them, and estimated cost. Where you cannot tell, say so. "Unknown whether stored files were read" is a truthful line; "no data accessed" without evidence is not.

Always check the neighbours. A key leaked in a .env file usually leaked with everything else in that file, and a vendor breach exposes every key you saved with that vendor.

Provider coordination

Each provider tells you what it expects. OpenAI's guidance for a suspected compromise: delete the affected key through the API key dashboard, review API usage for unexpected activity and keep the details, and contact OpenAI Support, including details of activity you did not perform or authorize. OpenAI also says that when it detects a key on the public internet, or leaked inside an app in an app store, the key is disabled immediately⁴. Anthropic's guidance: revoke the key immediately from the API keys page, create a new one and store it in a secrets manager rather than version control, and contact Support if suspicious activity continues⁵.

Record each contact with its ticket number and what you asked for. If you request an adjustment to the charges, record the provider's decision as the provider stated it; do not assume one. If a provider restricted or suspended your account, record when, why it said it did, and what it took to restore service.

Financial impact

Keep two lines and never sum them into one figure without showing both:

• Provider charges attributed to the incident. Per provider, from the provider's own usage and cost reports for the affected keys over the exposure window. Mark each figure as an estimate until it appears on an invoice, then record the invoiced amount and any adjustment the provider made.
• Response costs. People-hours, external responders, and any refunds or contractual remedies you gave your own customers.

If a provider spend limit stopped the spend, write down the limit, when it tripped and what else stopped with it. That is evidence for the next decision about where limits sit.

Control gaps, by layer

Map every gap to the layer that would have made the incident smaller. A useful set of layers for AI credentials, from how to limit the damage from a stolen key:

• Key scope. Was the key used by one workload in one environment, in its own project or workspace?
• Provider spend limit. Did its project or workspace have a hard limit at the provider, sized to the workload?
• Network restriction. Could the provider have refused requests from outside your networks?
• Gateway control. Did applications hold gateway keys with their own limits instead of provider keys?
• Detection. Which signal should have fired first: a spend alert, a per-key usage comparison, secret scanning?
• Revocation. How long did it take to find the key and kill it, and who could?
• Inventory. Did a row exist, with an owner, a holder and a revocation path?

Actions that close the loop

Good actions change a layer, have one owner and a date, and can be checked. "Be more careful with keys" is none of those. "Every OpenAI project that holds a key has a hard limit by 2026-11-15, owner: platform lead, checked by a weekly script" is all of them.

Review the actions at the next postmortem meeting, not only this one. NIST's framing is that incident response feeds improvement across governance, protection and detection²; an action list that is never revisited does not.

Evidence INFRO can contribute

If the leaked credential was an INFRO gateway key, or the incident involved traffic through INFRO, the console and API hold evidence for several sections:

• Timeline and response. The audit log records key creation, rotation (api_key.rotated), revocation and configuration changes with actor and time.
• Blast radius of a gateway key. Each key's providers, environment, allowed networks and spend limit are on the key; a request from outside its networks was refused with 403 ip_not_allowed before any provider call, and budget refusals return 402. Request traces show what the key did; prompt and response logging is off by default, so content is only there if your organization switched it on.
• Detection. Spend alerts flag a scope whose day departs from its usual day.
• Bypass. On the Business plan, reconciliation with usage access on can name traffic on your provider keys that did not go through INFRO; without usage access it reports "not checked".

INFRO's controls govern traffic that goes through INFRO. If the leaked credential was a provider key, including one connected to INFRO, it could be used directly against the provider, and INFRO's budgets and allowlists would not have applied. The evidence for that case is at the provider, and the controls that bound it are the provider's spend limits, key scopes, network restrictions and revocation.

Postmortem checklist

• Timeline starts at earliest possible exposure, in UTC, with a source for every line.
• Blast radius states both what the credential could reach and what it is known to have done.
• Neighbouring credentials (same file, vault or vendor) have been rotated or explicitly cleared.
• Every provider contacted is recorded with ticket, request and answer.
• Notification decisions are recorded with who decided and why, after review by legal and privacy where data may be involved.
• Provider charges and response costs are separate lines.
• Every control gap is mapped to a layer, and every action has one owner and a date.
• The credential inventory has been updated with what the incident revealed.