Scope
This guide outlines the structural requirements and operational practices for publishing AI incident post-mortems. It's designed for security engineers and governance teams who need to document system failures, coordinate external reviews, and balance transparency with operational security. You'll find requirement breakdowns, implementation steps, and a quick reference table you can bookmark.
This isn't about crisis communications or PR strategy. It's about creating a technical disclosure framework that helps your organization learn from incidents while protecting your attack surface.
Key Concepts and Definitions
AI Incident Post-Mortem: A structured analysis documenting what happened during an AI system failure or security breach, including root causes, timeline, and remediation steps. AI incidents often involve model behavior, training data exposure, or AI Supply Chain Compromise.
Third-Party Validation: External analysis by independent organizations to verify incident claims and assess response adequacy. OpenAI's HuggingFace incident included analysis from METR and Redwood Research alongside the internal post-mortem.
Responsible Disclosure: Revealing security vulnerabilities or incidents with enough detail to inform stakeholders without providing exploitation blueprints. Too little detail makes your post-mortem useless; too much turns it into an attack guide.
Validation Evidence: Artifacts, logs, and documentation that substantiate your incident timeline and root cause analysis. This is essential for external reviewers to take your findings seriously.
Requirements Breakdown
Structural Requirements
Your post-mortem needs these components to be credible:
Timeline Documentation: Precise timestamps for detection, escalation, containment, and resolution. Include what monitoring systems detected the incident and when human review began.
Root Cause Analysis: Explain not just what broke, but why it broke. For AI incidents, distinguish between model behavior issues, infrastructure failures, and supply chain problems. Document the permission structure if your model accessed resources it shouldn't have.
Scope Statement: Specify what systems were affected, what data was exposed, and what capabilities were compromised. Be specific about AI Actor roles if the incident involved multiple parties.
Remediation Actions: Detail what you fixed immediately and what you're changing long-term. Include configuration changes, access control updates, and monitoring improvements.
External Review Requirements
For a meaningful post-mortem, you need external validation:
Independent Analysis: Commission at least one third-party review from an organization with relevant technical expertise. They should have access to your logs, not just your summary.
Scope Agreement: Document what the external reviewers examined and what they didn't. If they only looked at the model's API logs but not the training pipeline, say so.
Dissenting Views: If external reviewers disagree with your conclusions, include their perspective. Credibility comes from acknowledging uncertainty, not pretending everything is resolved.
Implementation Guidance
Step 1: Secure Your Evidence
Before writing anything, secure your Validation Evidence. You need logs, model checkpoints, access records, and communication transcripts. Store these in an append-only system with cryptographic timestamps. If you lack this infrastructure, build it before your next incident.
Step 2: Conduct Internal Analysis
Write your timeline first. Use UTC timestamps and cross-reference multiple log sources. Identify every decision point where the incident could have been prevented or contained earlier.
Then work backward to root causes. Don't stop at "the model did something unexpected." Ask why the model had the permissions to act, why monitoring didn't catch it sooner, and why your testing didn't surface the vulnerability.
Step 3: Commission External Review
Engage your external reviewers while the evidence is fresh. Give them the same access you gave your internal team. Set a timeline: most serious reviews take two to four weeks.
Tell them explicitly what questions you need answered. Don't just ask "was our analysis correct?" Ask "what did we miss?" and "what would you have done differently?"
Step 4: Draft Your Public Post-Mortem
Your public document should include:
- Executive summary (what happened, what you fixed)
- Detailed timeline with enough specificity for other teams to learn
- Root cause analysis that explains the vulnerability without providing exploitation details
- Remediation actions, both immediate and planned
- External reviewer findings, including any disagreements
- Changes in your processes to prevent recurrence
Step 5: Security Review Your Draft
Before publication, have your security team review for operational security concerns. Remove or redact:
- Specific version numbers of internal tools
- Exact permission configurations
- API endpoints that aren't public
- Staff names unless they've agreed to attribution
But don't remove so much that your post-mortem becomes meaningless. If you can't describe the vulnerability class without exposing your infrastructure, you have an architecture problem.
Common Pitfalls
Pitfall 1: Vague Timelines
"The incident occurred over several days" tells nobody anything. Provide hour-by-hour breakdowns for the critical period.
Pitfall 2: Blaming the Model
"The AI acted unexpectedly" isn't a root cause. The root cause is why your system allowed unexpected AI behavior to cause damage.
Pitfall 3: Skipping External Review
Your internal team has blind spots. If you're publishing a post-mortem about a significant incident, external validation isn't optional.
Pitfall 4: Over-Redaction
If your security team removes every technical detail, you're publishing a press release, not a post-mortem. Push back. The point is to help other teams avoid your mistakes.
Pitfall 5: No Process Changes
If your post-mortem doesn't include concrete changes to monitoring, testing, or access control, you haven't learned anything.
Quick Reference Table
| Component | Required Detail | Security Consideration |
|---|---|---|
| Timeline | UTC timestamps, detection-to-resolution | Redact staff names, keep system names |
| Root Cause | Technical explanation of vulnerability | Describe class, not exact exploit |
| Scope | Systems affected, data exposed | Avoid listing all internal systems |
| Remediation | Specific changes made | Don't detail new security controls |
| External Review | Reviewer identity, scope, findings | Include dissenting views |
| Evidence | Log sources, checkpoints referenced | Don't publish raw logs |
| Process Changes | Monitoring, testing, access updates | Focus on principles, not configurations |
Keep this table handy when you're drafting. If you're missing any required detail column, your post-mortem isn't ready.
The goal isn't perfection. It's credibility. Your post-mortem should let other security engineers understand what happened well enough to check their own systems, without giving attackers a blueprint for your infrastructure.
