Markdown Editor

LLM and Agent Incident Postmortem Template

LLM and agent postmortem: impact, harmful output, data exposure, timeline, trace replay, eval regression, AI failure taxonomy, actions, notification check

AI 및 데이터전체NIST SP 800-61 Rev. 3; EU AI Act Art. 73; GDPR Art. 33-34; NIST AI 100-2 E2025llmincidentpostmortem

사용법: Use it for a blameless review when a model, prompt, retrieval step or agent action contributed to an incident. Freeze traces and versions first and run the notification check within hours, then replay affected calls many times. The main pitfall is stopping at the model's bad output instead of asking why pre-release evaluation passed.

미리보기

LLM and Agent Incident Postmortem: [Incident title]

Blameless postmortem for an incident involving a language-model application or an AI agent: harmful or wrong output, unintended tool actions, data exposure, safety filter failures or quality regressions. It extends a classic software postmortem with what makes AI incidents different: trace replay, non-determinism, evaluation regression analysis, an AI failure classification and a check of AI-specific notification duties. Incident handling follows the lifecycle in NIST SP 800-61 Rev. 3 (April 2025); the notification check points to the EU AI Act (Regulation (EU) 2024/1689, Article 73) and the GDPR (Articles 33 and 34), with the regulatory report itself kept in the AI Incident Report (ai-data/ai-incident-report). Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice. Worked examples use a billing support agent that, after a context change, showed some customers another account's invoice details and promised refunds outside policy.

Document control

FieldValue
Document ID[PM-AI-2026-001]
Version[0.1]
Status[Draft / In review / Final]
Owner (postmortem author)[@author]
Approvers / reviewers[@incident-commander], [@agent-owner], [@security-lead], [@privacy-lead]
Last updatedYYYY-MM-DD
Classification[Confidential]
Incident ID[INC-2026-0412]
Severity[SEV1 / SEV2 / SEV3]
Incident window (UTC)[YYYY-MM-DD HH:MM] to [YYYY-MM-DD HH:MM]
System and versions[Application version], [model and snapshot], [prompt or context spec version], [tool catalogue version], [retrieval index version]
Linked records[AI incident report], [security incident ticket], [privacy breach record]

Approvals

RoleNameDecisionDate
Incident commander[@name][Approved / Changes requested]YYYY-MM-DD
Agent or product owner[@name][Decision]YYYY-MM-DD
Privacy or legal lead[@name][Decision on section 11]YYYY-MM-DD

Revision history

VersionDateAuthorChange summary
0.1YYYY-MM-DD[@name]First draft within 48 hours
0.2YYYY-MM-DD[@name]Example: Added replay results and evaluation gap analysis
1.0YYYY-MM-DD[@name]Example: Final after review meeting

Contents

1. Summary

Example: On [date], between 09:12 and 12:05 UTC, the billing support agent showed invoice details belonging to other accounts in 37 conversations and promised refunds outside policy in 212 conversations. A context change released at 09:05 moved retrieved past tickets into an application-side cache of assembled context blocks keyed without the account id, so examples from one account appeared in another account's context, and the new ordering placed refund policy after those examples. A customer reported the exposure through support at 11:31; the on-call engineer disabled the past-tickets source and the refund tool at 12:05. The context change had passed the task evaluation suite, which contained no multi-account cases and no check on refund promises.

2. Impact

2.1 Users and business

MeasureValueHow measured
Conversations in the incident windowExample: 1,240Session logs, 09:12 to 12:05 UTC
Conversations with out-of-policy refund promisesExample: 212 (17.1%)Classifier over transcripts, then manual review of all flagged items
Unintended agent actionsExample: 0 refunds created; 212 refund promises made in textTool call logs
Customer remediation costExample: USD 9,800 in goodwill credits honouredFinance report
Support loadExample: 96 follow-up ticketsTicketing system

2.2 Harmful or unsafe output

CategoryCountExample (redacted)Severity
Out-of-policy commitmentsExample: 212"I have approved a full refund of your annual plan"Medium
Disclosure of another person's dataExample: 37Invoice number, plan name and amount of another accountHigh
Abusive, dangerous or discriminatory contentExample: 0Not applicableNot applicable

2.3 Data exposure

ItemValue
Data categories exposedExample: Invoice numbers, plan names, amounts, company names; no payment card data
Data subjects affectedExample: 29 accounts whose data appeared (some appeared more than once); 37 recipients
Exposure channelExample: Agent replies shown in the support chat; also stored in chat transcripts
Was data sent to a third partyExample: Model provider processed it under the existing data processing agreement; no new recipient
Containment of copiesExample: Affected transcripts purged from analytics exports; retention hold on originals for the investigation

Example: 37 of 1,240 conversations is 3.0% of conversations in the window.

3. Timeline

Time (UTC)EventSource
Example: D-2 14:00Context change CTX-2026-001 v0.3 approved after task suite passedPull request
Example: 09:05Context change deployed to 100% of trafficDeploy log
Example: 09:12First conversation with another account's invoice detailsTrace replay
Example: 10:20Context block cache hit rate rises from 41% to 88%; no alert configuredMetrics
Example: 11:31Customer reports seeing another company's invoiceSupport ticket
Example: 11:40Support lead pages on-call; incident declared SEV2Paging tool
Example: 11:52Awareness of possible personal data breach recordedIncident channel
Example: 12:05Past-tickets source disabled; refund.quote and refund.create removed from tool setFeature flags
Example: 12:30Severity raised to SEV1 after confirming cross-account exposureIncident channel
Example: 15:30Rollback to context v0.2 complete; tools restoredDeploy log
Example: D+1 10:00Privacy lead decision on notification (section 11)Decision record

4. Detection

ItemValue
First signalExample: Customer report
Time to detectExample: 2 hours 19 minutes from first bad output (09:12 to 11:31)
Signals that existed but did not alertExample: Cache hit rate jump; rise in "refund" phrases in replies; output scanner flagged 4 replies as containing foreign invoice ids but only logged them
Signals that did not existExample: No per-conversation check that every invoice id in a reply belongs to the session account

Monitoring improvements belong in LLM Observability Specification (ai-data/llm-observability-spec) and Guardrails Specification (ai-data/guardrails-spec); list the actions in section 10.

5. Response and containment

Time toValue (Example)
Acknowledge9 minutes (11:31 to 11:40)
Contain34 minutes after report (11:31 to 12:05)
Recover3 hours 59 minutes after report (11:31 to 15:30)

Containment options used and their effect:

  • Example: Disabled the past-tickets retrieval source by flag. Stopped new exposure immediately; answer quality dropped slightly.
  • Example: Removed refund tools from the tool set, so the agent handed refund requests to staff. Raised staff queue by 40 tickets.
  • Example: Rolled back the context version. Restored normal behaviour.

Containment options that were missing: Example: no single switch to lower the agent to suggest-only mode; this is an action in section 10. Oversight modes are designed in Human Oversight Design (ai-data/human-oversight-design).

6. Trace replay and reproduction

ItemValue
Traces preservedExample: All 1,240 sessions; full context hashes and block contents for 48 sampled sessions
Replay environmentExample: Same model snapshot, same context v0.3, cache disabled and enabled
Sampling settingsExample: Production settings (temperature 0.3)
Runs per caseExample: 50
CaseConditionReproducedRate
RP-01 (Example)Cross-account data, cache enabled, v0.331 of 5062%
RP-02 (Example)Same, cache disabled, v0.30 of 500%
RP-03 (Example)Out-of-policy refund promise, v0.322 of 5044%
RP-04 (Example)Out-of-policy refund promise, v0.21 of 502%

Interpretation (Example): RP-01 and RP-02 show the data exposure came from cache sharing, not from the model. RP-03 and RP-04 show the reordering raised the out-of-policy promise rate from 2% to 44%. The 2% baseline is itself a defect that existed before the incident. Zero of 50 does not prove a zero rate: by the rule of three it only bounds the true rate below about 6% (3 / 50) at 95% confidence, which is why EV-REG-01 uses 500 runs (bound below about 0.6%).

Non-determinism notes:

  • Record the sampling parameters, seed support, and whether the provider guarantees identical output for identical input. Most do not.
  • Check whether the provider changed the model behind the snapshot or alias during the window.
  • When a case does not reproduce, say so and keep it in the regression set anyway; a low-rate failure is still a failure at volume.

7. Evaluation regression analysis

QuestionFinding (Example)
Which evaluation gated the changeTask suite (420 cases) and injection suite (60 cases)
Did the failure appear in any existing caseNo: every case used a single account and an empty cache
Which metric would have caught itA policy-compliance metric on refund replies; a cross-account leakage check
Were thresholds hiding a shiftGroundedness fell from 0.94 to 0.92, inside the 0.03 tolerance
Was production monitoring an evaluation gapYes: output scanner findings were logged but not evaluated

New regression cases (add to the LLM Evaluation Plan, ai-data/llm-evaluation-plan, and the Agent Evaluation Plan, ai-data/agent-evaluation-plan):

IDCaseMetricPass criterion
EV-REG-01 (Example)Two accounts in parallel sessions with cache enabledForeign identifier in replyZero occurrences in 500 runs
EV-REG-02 (Example)Refund request above policyOut-of-policy promise rateBelow the agreed bar in 200 runs
EV-REG-03 (Example)Context reorder of any blockFull suite rerun with cache enabledNo metric drop beyond tolerance

8. Contributing factors

IDFactorCategoryEvidence
CF-01 (Example)Context design placed per-account examples in an application cache block keyed without the account idDesignContext spec v0.3, section 7
CF-02 (Example)Policy text moved after examples, weakening its effect on refund repliesContext orderingRP-03, RP-04
CF-03 (Example)Evaluation had no multi-account or cache-enabled casesEvaluation coverageSection 7
CF-04 (Example)Output scanner findings were logged without alertingMonitoringSection 4
CF-05 (Example)Context changes were not treated as releases needing staged rolloutProcessDeploy log shows 100% at once
CF-06 (Example)No suggest-only mode for fast containmentOversight designSection 5

9. AI failure classification

CodeClassDescriptionThis incident
AF-01SpecificationInstructions, policy or scope were wrong or ambiguousNo
AF-02Context assemblyWrong, missing, stale, leaked or misordered contextPrimary (Example)
AF-03RetrievalWrong or poisoned documents retrieved, or right ones missedSecondary (Example)
AF-04Model behaviourFabrication, policy non-compliance, refusal or tone failure with correct contextSecondary (Example)
AF-05Tool selection or argumentsWrong tool, wrong arguments or wrong sequenceNo
AF-06Tool or integration defectTool, API or permission check behaved incorrectlyNo
AF-07Adversarial inputPrompt injection, jailbreak, data or memory poisoningNo
AF-08Oversight failureHuman approval or review missed or approved a harmful actionNo
AF-09Evaluation gapPre-release tests could not detect the failureSecondary (Example)
AF-10Change and configurationModel, prompt, index or provider change not controlledSecondary (Example)

For adversarial causes, add the attack class from NIST AI 100-2 E2025 and the matching OWASP Top 10 for Agentic Applications 2026 category (for example ASI01 Agent Goal Hijack or ASI06 Memory & Context Poisoning), and update the Agentic AI Threat Model (ai-data/agentic-threat-model).

10. Corrective and preventive actions

IDActionAddressesTypeOwnerDueVerification
CA-01 (Example)Add the account id to every context block cache key; add a test that fails if per-account content enters a shared blockCF-01Prevent[@agent-owner]YYYY-MM-DDUnit test plus EV-REG-01
CA-02 (Example)Restore policy block before examples; add policy-compliance metricCF-02Prevent[@prompt-owner]YYYY-MM-DDEV-REG-02
CA-03 (Example)Add multi-account and cache-enabled cases to the release gateCF-03Detect[@evaluation-lead]YYYY-MM-DDGate run attached to next release
CA-04 (Example)Alert when a reply contains an identifier that does not belong to the session account; block the replyCF-04Detect and prevent[@platform-owner]YYYY-MM-DDSynthetic test in production
CA-05 (Example)Roll out context changes to 5%, then 25%, then 100%, with automated comparisonCF-05Prevent[@release-owner]YYYY-MM-DDNext two context changes follow it
CA-06 (Example)Add a suggest-only switch for the agentCF-06Contain[@agent-owner]YYYY-MM-DDGame day drill
CA-07 (Example)Fix the 2% baseline out-of-policy promise rate seen in RP-04RP-04Prevent[@prompt-owner]YYYY-MM-DDEV-REG-02 on v0.2 lineage

Record each action in the Corrective and Preventive Action Plan if your organisation keeps one, and link it here.

11. Regulatory and contractual notification check

DutyApplies?Trigger summaryDeadline summaryDecision and dateOwner
GDPR Article 33, notify the supervisory authorityExample: YesPersonal data breach, unless unlikely to result in a risk to peopleWithout undue delay and, where feasible, within 72 hours of awarenessExample: Notified D+1 11:00, after the decision at D+1 10:00[@privacy-lead]
GDPR Article 34, inform affected peopleExample: Assessed: noBreach likely to result in a high risk to peopleWithout undue delayExample: Not required: low sensitivity, recorded reasons[@privacy-lead]
EU AI Act Article 73, serious incident (high-risk AI systems)Example: No: support agent is not a high-risk system under Annex IIISerious incident as defined in Article 3(49)Immediately once a causal link is established or reasonably likely, at the latest 15 days after awareness; shorter limits apply for death and for widespread infringement or serious critical infrastructure disruption (check the consolidated text and current application dates)Example: Recorded D+1[@legal]
Sector or national rules[Yes / No][Rule][Deadline][Decision][@legal]
Customer contracts and data processing agreements[Yes / No][Clause][Deadline][Decision][@account-owner]
Model or tool provider terms[Yes / No][Clause on misuse or security reports][Deadline][Decision][@vendor-owner]

When any regulatory notification applies to the AI system, complete the AI Incident Report (ai-data/ai-incident-report), which holds the regulator-facing fields, and link it in Document control. Security handling follows the Incident Response Plan (compliance/incident-response-plan).

12. Lessons learned

What went well (Example):

  • Support recognised the report as a possible data exposure and paged within 9 minutes.
  • Feature flags allowed containment without a full rollback.
  • Full context hashes made exact replay possible.

What went poorly (Example):

  • A context change was treated as a configuration tweak, not a release.
  • The evaluation suite tested the model, not the assembled system with its cache and multiple users.
  • Signals existed (cache hit rate, scanner findings) but nobody watched them.

Where we were lucky (Example):

  • The refund tools required a quote that the server validated, so no money moved even though the agent promised refunds.
  • The exposed data did not include payment details.

Share the lessons with other teams running agents; the context caching pattern in CF-01 is likely to exist elsewhere.

13. Glossary and references

TermMeaning
Blameless postmortemA review that looks for system conditions behind a failure rather than individual fault
Trace replayRebuilding the exact inputs of a recorded model call and running it again
Non-determinismVariation in model output between runs with the same input
Evaluation regressionA behaviour change that pre-release tests failed to detect or allowed
Context block cacheApplication-side cache of assembled context blocks; distinct from provider prompt caching, which reuses processing of an identical prefix and does not add content to a request
AwarenessThe moment the organisation has reasonable certainty an incident occurred; many legal deadlines count from it

References:

Standard and licence note

Based on NIST SP 800-61 Rev. 3 (April 2025) for the incident handling lifecycle, on Regulation (EU) 2024/1689 Article 73 and Regulation (EU) 2016/679 Articles 33 and 34 for the notification check (paraphrased in original words), and on NIST AI 100-2 E2025 for adversarial attack classes. OWASP Top 10 for Agentic Applications 2026 IDs and short names are cited for mapping with attribution to the OWASP GenAI Security Project (CC BY-SA 4.0). The AI failure classification, structure and all wording are original. Laws and their application dates change: check the consolidated texts and the current official versions before use. This is a documentation format, not legal advice. Template licence: MIT.

관련 템플릿