# API key leak postmortem template for AI credentials URL: https://infro.io/blog/ai-credential-incident-postmortem-template Author: INFRO Editorial (https://infro.io/blog/editorial) Publisher: INFRO Published: 2026-10-21 Last modified: 2026-10-21 Last reviewed: 2026-10-21 (next review due 2026-11-20) Topic: Security and governance Format: Guide > A postmortem for an AI credential incident should record a UTC timeline from first exposure through detection, revocation and rotation; the blast radius (which keys, accounts, models, data and spend the credential could reach, and what it actually did); coordination with each provider; any customer or regulator notification; the financial impact separated into provider charges and response costs; the control gaps, mapped to layers such as key scope, provider spend limits, network restrictions and detection; and owned, dated actions. Keep it blameless and align it with NIST SP 800-61 Rev. 3. Key takeaways: - Write the timeline in UTC from first possible exposure, not from detection; the gap between them is the most important number in the review. - State blast radius twice: what the credential could reach, and what it is known to have done. - Keep provider charges and response costs as separate lines, and record any adjustment to the charges exactly as the provider decided it. - Map every control gap to a layer: key scope, provider limit, network restriction, gateway control, detection or revocation. - Blameless means the question is which control would have made the leak smaller, not who pasted the key. **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[1]. A postmortem has to cover the security, financial and availability sides together. For the live response itself, see [LLM incident response](https://infro.io/blog/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"[2]. 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[3]. 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 ```text # Postmortem: , Status: draft | in review | final Severity: Incident lead: Review date: Authors: Distribution: ## 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[1]. 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](https://infro.io/blog/detect-gateway-bypass-provider-usage) 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](https://infro.io/blog/ai-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[4]. 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[5]. 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](https://infro.io/blog/cap-stolen-ai-key-damage): - **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? > **Example: A filled-in gap table, abbreviated** > A key for an internal evaluation job was committed to a public repository on a Friday evening and used from outside the company over the weekend. Invented details: > > | Layer | Expected | Actual | Gap | > | --- | --- | --- | --- | > | Key scope | Evaluation key in its own project | Shared project with the support assistant | Revocation also stopped the assistant for 40 minutes | > | Provider spend limit | Project hard limit near monthly usage | Organization limit only | Spend ran to $3,100 before detection | > | Detection | Alert on a project's unusual day | Weekly review of the invoice | Found on Monday, 58 hours after first use | > | Revocation | Owner can revoke in minutes | Owner on leave; admin found the key by its last four characters | 25 minutes to identify the right key | > > Actions: one project per workload with a hard limit; a daily per-key usage comparison; push protection on the repository; the inventory gains the key's provider ID and a second owner. ## 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[2]; 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](https://infro.io/docs/org/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](https://infro.io/docs/observability/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](https://infro.io/docs/cost/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. ## Questions ### What should a postmortem for a leaked API key include? A UTC timeline from first possible exposure to full recovery, the blast radius (what the key could reach and what it actually did), provider coordination, any customer or regulator notification, financial impact, the control gaps that let it happen or made it larger, and owned, dated actions. Write it blameless. ### Which NIST guide covers incident response? NIST SP 800-61 Rev. 3, published in April 2025, titled Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. It supersedes Rev. 2 from 2012 and places incident response inside the CSF 2.0 risk management functions. ### Should I tell my AI provider when a key leaks? Yes, when you see usage you did not make. OpenAI's guidance is to delete the key, review usage for unexpected activity and keep the details, and contact support. Anthropic's is to revoke the key immediately, create a new one stored in a secrets manager, and contact support if suspicious activity continues. ### Is a leaked AI key a data breach? It can be. If the key could read stored resources such as files, batches or conversation history at the provider, or if prompts and responses were logged somewhere the attacker could reach, assess it as a possible data exposure with your legal and privacy teams. A key that could only make new inference calls is primarily a financial and abuse incident. ## Sources 1. OpenCode hack exposes API keys amid AI distillation attacks — BleepingComputer. https://www.bleepingcomputer.com/news/security/opencode-hack-exposes-api-keys-amid-ai-distillation-attacks/ (accessed 2026-10-21) 2. SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile — NIST. https://csrc.nist.gov/pubs/sp/800/61/r3/final (accessed 2026-10-21) 3. Postmortem Culture: Learning from Failure — Google. https://sre.google/sre-book/postmortem-culture/ (accessed 2026-10-21) 4. Keeping your OpenAI account secure — OpenAI. https://help.openai.com/en/articles/8304786-how-can-i-keep-my-openai-accounts-secure (accessed 2026-10-21) 5. What should I do if I suspect my API key has been compromised? — Anthropic. https://support.claude.com/en/articles/8384961-what-should-i-do-if-i-suspect-my-api-key-has-been-compromised (accessed 2026-10-21)