Taxonomy: Incident vs. Vulnerability vs. Disclosure vs. Misuse

Four words show up in AI security reporting almost interchangeably: incident, vulnerability, disclosure ↗, misuse. They are not synonyms. Each describes a different kind of event, lives at a different point in time, and triggers a different operational response. Mixing them up produces bad reporting, bad triage, and bad regulatory submissions. This is the working taxonomy.

Incident

An incident is an event in which an AI system caused or contributed to a real-world impact, intended or not. The defining feature is impact-in-the-world. Until impact, there is no incident.

• A model that started generating high-rate fraudulent outputs after a deployment change: incident.
• A chatbot that handed a customer the wrong refund amount and the customer cashed it: incident.
• A research disclosure of a jailbreak technique that has not been observed in any deployment: not an incident (it’s a disclosure of a vulnerability).
• An attacker who got code execution on an inference server: incident (specifically, a security incident).
• A user who used a model to write a phishing email that succeeded: incident (specifically, a misuse incident).

When a vendor publishes an “incident report,” they are using the word in this strict sense — something happened, someone was affected, and the organization is acknowledging it.

Vulnerability

A vulnerability is a weakness in an AI system that could be exploited to cause harm. The defining feature is potential, not actualization.

• A jailbreak that bypasses a model’s refusals on a forbidden category: vulnerability.
• A deserialization bug in a model loader: vulnerability.
• A prompt-injection technique that succeeds against a class of agents: vulnerability.
• A model’s tendency to memorize training data: vulnerability (specifically, a privacy vulnerability).

A vulnerability has a discoverer, a fix lifecycle, and (in mature ecosystems) a CVE identifier. A vulnerability becomes an incident when it is exploited and produces impact.

The trap: many AI security write-ups describe vulnerabilities as if they were incidents because the language is more dramatic. Discipline matters here. A demonstrated jailbreak is a vulnerability. A jailbreak that was used to defraud a hundred customers is an incident.

Disclosure

A disclosure is the act of making information about a vulnerability or incident public. The defining feature is the publication event itself.

• A researcher publishing a paper about a new attack class: disclosure.
• A vendor publishing an advisory describing a patched bug: disclosure.
• A regulator issuing a finding against an AI provider: disclosure (though one with legal weight).
• A blog post by a red team naming a new technique: disclosure.

A disclosure has a date, an author, and a set of channels through which it was published. Disclosures can be coordinated (under embargo, with the affected vendor) or uncoordinated (published without notice).

The relationship between disclosure and the others:

• A disclosure may describe a vulnerability that has never been exploited.
• A disclosure may describe an incident long after it occurred.
• A disclosure is, itself, the event when we ask “when did this enter the public record?”

For incident reporting, the disclosure date is one of the four dates we record (see the methodology). It is distinct from the incident date.

Misuse

Misuse is the use of an AI system, working as designed, to cause harm. The defining feature is intentional adversarial use of capability — not a bug, not a misalignment, not a vulnerability.

• Using a working LLM to generate phishing emails: misuse.
• Using a working voice-clone model to impersonate someone: misuse.
• Using an open-source image model to generate non-consensual imagery: misuse.
• Using a coding agent to find vulnerabilities in software you don’t own: misuse.

The crucial distinction: misuse doesn’t require the model to fail. The model can be perfectly aligned, refuse no requests it was trained to refuse, and still be used as a tool for harm. Misuse is downstream of the model — it is a property of the user, the deployment, the application.

This matters editorially. A misuse-driven incident is not a model failure, and reporting that conflates the two contributes to the misperception that model providers can “fix” misuse with better alignment. Often they cannot, because the underlying capability is doing exactly what it’s supposed to do.

The four-way matrix

Event	Has impact?	Has weakness?	Was published?	Was the model doing its job?
Incident	Yes	Sometimes	Sometimes	Sometimes
Vulnerability	No (yet)	Yes	Sometimes	No (model failing)
Disclosure	N/A	About one	Yes	N/A
Misuse	Yes	No	Sometimes	Yes

These overlap. An exploited vulnerability is a vulnerability and an incident. A coordinated disclosure of a misuse pattern is a disclosure and a misuse case. The taxonomy is not categorical — it is a frame for asking the right question about an event.

Why we keep them separate

For incident reporting, mixing the terms produces measurable damage:

• Patching priority. A vulnerability with no observed exploitation does not get the same urgency as an active incident. Conflating them de-sensitizes responders.
• Regulator submissions. EU AI Act and NIST AI RMF reporting use these terms with specific definitions. Submitting a misuse case as an incident or a vulnerability as an incident produces compliance friction.
• Reader trust. A reader who reads “incident” expecting actualized harm and finds a theoretical disclosure stops trusting the publication.

How readers should use this

When you read coverage of an AI security event, classify it before reading further:

• Is anyone harmed yet? If yes → incident. If no → vulnerability or disclosure.
• Was the model working correctly? If yes → misuse. If no → vulnerability.
• Is the news the event, or the publication of the event? If the publication → disclosure.

Then read the piece looking for whether the writer maintains the same distinction. The good ones do. The aggregators don’t.

For broader coverage: the defensive cluster’s playbooks at guardml.io ↗ treat vulnerabilities and incidents as separate categories with separate runbooks. The policy-cluster post on EU AI Act Article 52 at aiprivacy.report ↗ handles disclosure obligations as a regulator-defined event. Keeping the terms straight makes both bodies of work coherent.

For more context, AI security digest ↗ covers related topics in depth.