AI Incident Logging: How We Log and Tag AI Incidents

AI incident logging means writing each AI failure or attack into a structured record: what happened, which system, who was harmed, four separate dates, the strongest source and its tier, and classification tags. An event enters our log as an incident only when it caused material harm and a source we can cite backs it.

When a reader trusts an incident publication, what they’re actually trusting is the methodology behind the headlines — the editorial decisions about what to publish, what to verify, and what to leave out. That methodology should be visible. This post is ours.

Which events count as AI security incidents

An event qualifies for the AI security incident log when it meets criteria 3 (material impact) and 4 (citable reporting), plus at least one of criteria 1 and 2:

1. AI-system-mediated harm: the harm flows through the behavior of an ML model or LLM, not just from a system that happens to use AI internally.
2. Adversarial or unintended cause: the incident was caused by deliberate attack (prompt injection, data poisoning, model extraction) or unintentional misalignment (hallucinated outputs, reward hacking, safety failures).
3. Material impact: actual users, customers, or third parties were affected — not just a published vulnerability that was patched before exploitation.
4. First-party or credible third-party reporting: there’s a primary source we can cite — vendor advisory, court filing, regulator action, peer-reviewed disclosure, or reporting from a publication that demonstrates verification.

If an event falls short of that, we may track it internally but won’t publish until the criteria converge. This filters out a lot of “AI did a bad thing on Twitter” incidents that don’t have enough signal to verify.

Source tiers

We rank sources in five tiers. A standard entry publishes only when we have at least one Tier 1-2 source. The single exception is the provisional entry described below, and it is labelled as one.

Tier 1 — Primary: Vendor advisories, regulatory actions, court filings, organizational incident reports, peer-reviewed papers documenting the event.

Tier 2 — Established secondary: Reporting from publications with demonstrated verification practice (Reuters, Bloomberg, Wired security desk, KrebsOnSecurity, 404 Media, The Markup) where the reporter has independently confirmed the claim.

Tier 3 — Specialty secondary: Reporting from AI-specific publications, research org statements, social media posts from named researchers with reputation at stake.

Tier 4 — User reports: Individual users describing experiences. Triangulated only — a single Twitter thread is not enough; a pattern across multiple independent accounts may be.

Tier 5 — Speculation and aggregator content: AI-summarized news posts, anonymous Reddit claims, unverified screenshots. Not citable.

The exception to that rule is the provisional entry. A narrow Tier 3-only case, or a Tier 4 pattern triangulated across independent accounts, can publish as a clearly labelled provisional entry marked verification: partial. It keeps that label until a Tier 1-2 source lands or the entry is withdrawn. Examples of claims accepted and rejected at each tier are in source verification tiers.

Dating

Every incident gets four dates when available:

• incident_date: when the harmful behavior occurred
• disclosure_date: when the affected party or vendor first acknowledged it
• report_date: when public reporting first appeared
• verification_date: when we ourselves cleared the verification bar

The four dates often differ by weeks or months; conflating them leads to misleading timelines. A vendor disclosure on April 30 about an incident from January 12 is two events, not one.

For undated claims (especially in academic disclosures), we mark the date as approximate and explain the reasoning in the entry.

The fields in every AI incident log entry

Every published entry is one record with the same fields, so any two entries can be compared and filtered on the same terms.

There is no severity field, and that is the main departure from the OECD’s common reporting framework for AI incidents, which narrowed 88 candidate criteria to 29 across eight dimensions. Seven are mandatory, among them the description, the type of harm, the severity and the link between the AI system and the incident. Severity is also hard to label consistently: in the June 2026 validation pilot for MIT’s AI Incident Tracker, two expert reviewers classifying the same 10 incidents reached only “fair” agreement on harm severity (quadratic weighted kappa 0.31). Our entries clear the material-impact bar or stay unpublished, and the summary states the scale of harm in the source’s own terms, so readers can apply their own severity scale.

How we tag AI incidents

Every entry is tagged in three layers: one value for each of our own facets, a MITRE ATLAS technique ID when an adversary was involved, and the event’s AI Incident Database number when one exists. Tags record what the strongest source establishes. Anything the source only implies goes in the summary, worded as inference.

Our facets. incident_type follows our working taxonomy of incident, vulnerability, disclosure and misuse, so a published jailbreak nobody has been seen using is a vulnerability, not an incident. Each facet takes one value from the fixed lists above, which loses nuance but keeps filters and counts across entries meaningful.

ATLAS technique IDs. For adversarial incidents we add the technique the source describes, at sub-technique level where the evidence allows. In MITRE’s ATLAS data, AML.T0051 is LLM Prompt Injection under the Execution tactic (AML.TA0005), with AML.T0051.000 for direct and AML.T0051.001 for indirect injection. ATLAS is versioned, so the version is stored with the ID; this revision was checked against 5.6.0. Failures in an LLM application also get their OWASP category, such as LLM01:2025 Prompt Injection. A hallucinated citation gets no ATLAS tag, because no adversary technique was used.

AIID cross-reference. Rather than re-tag under other schemes, we link the AIID incident number. AIID applies several taxonomies to its records, including the CSET AI Harm Taxonomy for policy-relevant harms, the Goals, Methods and Failures (GMF) taxonomy for the technical and process factors behind an incident, and the MIT AI Risk Repository’s domain taxonomy of 7 domains and 24 subdomains.

The rules we tag by

1. Tag from the source, not the coverage. A headline that says “hacked” does not make an entry adversarial.
2. Separate known from inferred. AIID’s GMF taxonomy labels a failure “Known” when it is almost certainly involved and “Potential” when it probably is, with a quoted snippet justifying each label. We apply the split more bluntly: only known values become tags.
3. Default to unknown. If no source names the actor, the entry says actor_class: unknown.
4. Change types in the open. When a logged vulnerability is later exploited, its type moves to an incident type, an incident date is added, and the change is dated in updates.
5. Treat machine tags as leads. MIT’s tracker classifies AIID incidents with a language model and says it “relies on automated LLM classification rather than manual review”. That suits trend work across a catalog. For a single entry, a person assigns each facet from the source.

Worked example: Microsoft’s Tay, March 2016

The layers disagree in useful ways. AIID dates the incident 24 March, while its own CSETv1 date fields and the ATLAS case study give 23 March, and Microsoft’s post says Tay launched “on Wednesday”, which 23 March 2016 was; we log the 23rd. MIT files the event under toxic content, our facets under safety. Neither is wrong. They answer different questions, which is why we link other catalogs instead of translating their tags into ours.

AI incident logging inside an organization

For a team running AI systems, incident logging starts before any incident: the system has to record enough about each interaction that an entry like ours can later be built from it. For high-risk systems in the EU that becomes a legal duty.

Article 12 of the EU AI Act requires high-risk AI systems to technically allow automatic logging of events over their lifetime, so that risks and substantial modifications can be identified, post-market monitoring supported and operation monitored. For remote biometric identification systems (Annex III, point 1(a)), the logs must at least record each use’s start and end, the reference database checked, the input data that produced a match, and who verified the result. Providers (Article 19) and deployers (Article 26(6)) must keep those logs, where they control them, for at least six months unless other Union or national law says otherwise. Article 12 applies from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Who must then be notified, and how fast, is set out in AI incident reporting requirements.

Outside the EU the reference point is voluntary. NIST’s AI RMF, under MANAGE 4.3, expects that “processes for tracking, responding to, and recovering from incidents and errors are followed and documented.”

Either way, an internal log earns its keep when it can fill the fields above:

What we do not publish

• Speculative attribution: claims about who is responsible without evidence at the source-tier level required.
• Personally identifiable victim information beyond what the original source published.
• Working exploit code for active vulnerabilities. We link to the academic paper or vendor advisory, not the proof-of-concept repo, until a patch is broadly available.
• Unverified jailbreak prompts as a service. If a jailbreak technique is publicly disclosed, we describe the technique class; we don’t republish the working string.
• Capabilities-not-yet-public: research findings that haven’t been disclosed to affected vendors yet, even if a researcher offers them.

This is not a comprehensive list. Editorial judgment applies on novel cases.

Corrections

When we get something wrong, we correct the affected post and say so in the post itself. Silent edits are not allowed. The correction states:

• What we said
• What was actually true
• How we learned of the error
• What we changed in our process to reduce the chance of repeat

What we link to

External links go to:

• The primary source when available
• The most authoritative secondary source otherwise
• An archive (web.archive.org or archive.today) when a primary source is on a domain known to alter or remove content

We don’t link to aggregators, AI summaries, or auto-generated news sites, even when they have higher search ranking.

Cross-references

Where applicable, every incident is cross-referenced to:

• The MITRE ATLAS knowledge base, when a case study matches
• The AI Incident Database entry, when one exists
• The OECD AI Incidents Monitor, when one exists
• Related entries in our own archive

The goal is that a reader investigating an incident can rebuild the full evidence trail without leaving documented sources.

Update policy

Incidents are not static. We update entries when:

• New disclosures from the affected party change the facts
• A patch, mitigation, or remediation is released
• A regulatory finding or court decision is published
• A subsequent incident provides additional context
• A source supports a different tag, such as a logged vulnerability being exploited

Each update carries a date. We do not retroactively edit out earlier framings, because the history of how an incident was understood is itself part of the record.

Why this matters

The AI security beat is full of high-velocity, low-rigor reporting. Twitter threads claim breaches that didn’t happen. AI-summarized news sites republish each other’s errors. A serious reader who wants to understand what’s actually happening needs a publication that does the verification work and shows its sources.

That’s our job. The methodology is the product. Everything that clears these criteria lands in the AI Incident Explorer — a faceted, filterable timeline where every entry is dated, classified under this taxonomy, and linked to its strongest primary source. For the methodology pieces behind it, browse the incidents and methodology topics index.

For how this catalog differs from the larger public ones, and when you should be citing AIID, the OECD monitor or a vulnerability catalog instead, see our AI incident database comparison. For the operational side of the same logging decisions, the evidence an incident-response playbook for AI systems depends on is the evidence these criteria describe.

FAQ

is ai incident logging mandatory?

Only in some cases. The EU AI Act requires high-risk AI systems to log events automatically, and providers and deployers to keep those logs for at least six months, from 2 December 2027 for Annex III systems. The NIST AI RMF expects documented incident tracking, but it is voluntary guidance rather than law.

what is the difference between an ai incident log and an ai system log?

An AI system log is the automatic, machine-written record of what a system did: inputs, outputs, timestamps, tool calls. An AI incident log is a curated register of events that caused harm, each with dates, sources and tags. The system log is the evidence; the incident log is the finding a person writes from that evidence.

how do you tag an ai incident with mitre atlas?

Match the technique the source actually describes, then record its ATLAS ID at the most specific level the evidence supports, for example AML.T0051.001 for indirect prompt injection rather than the parent AML.T0051. Note the ATLAS version you checked, link a case study if one exists, and leave non-adversarial failures untagged.

should near misses go in an ai incident log?

Yes, but under a separate type. The OECD’s monitor splits incidents, where harm occurred, from hazards, where harm is credible but not yet realized. We log a disclosed flaw with no documented exploitation as a vulnerability with no incident date, and convert it to an incident only when a source shows exploitation and harm.