About
Methodology
Incidents.si records operational incidents: cases where an AI agent or model in production failed, or did something it should not have. This page explains what gets in and how it is rated.
Purpose
The record is written for engineers who run AI agents in production: SRE and platform teams, AI security teams, and the journalists and researchers who need verified cases they can cite.
Broader databases cover every kind of harm from AI, including bias, deepfakes and privacy. This one is narrower in three ways:
- Scope. Operational incidents only.
- Form. A short technical record, written for an engineer.
- Speed. Published no later than 7 days after public disclosure.
What counts as an incident
An entry is a publicly documented event in which an AI system in real use failed, caused harm, or was shown to be vulnerable. An entry must meet all three criteria:
- Real use. The event involves a system or product that is in use, not a demo or a laboratory model.
- A source. The entry has the sources its evidence level requires.
- A definable effect. Data loss, an outage, financial harm, a security breach or a dangerous action, actual or demonstrated.
We do not publish opinions, predictions, benchmark results, rumors, or demonstrations on systems that are not in real use.
Evidence levels
Every entry carries an evidence level that says how much of it is confirmed. The level is always shown next to the title.
| Level | Meaning | Required sources |
|---|---|---|
| confirmed | The organization confirmed the incident, or an official document exists. | At least one primary source: a company statement, postmortem, court document or CVE. |
| reported | Media report the incident. The organization has not confirmed it. | At least two independent secondary sources. |
| research-demo | Researchers demonstrated the attack or failure on a system in use. No harm in production. | The researchers’ publication. |
| near-miss | A failure in production was stopped before it caused harm. | At least one primary source. |
Categories
Each entry has exactly one category.
| Category | Description |
|---|---|
| agent-action | An agent carries out a harmful action, such as deleting data or making a wrong transaction. |
| prompt-injection | An attack delivered through content the agent reads. |
| data-leak | Data is disclosed through a model or an agent. |
| outage | A major AI service or model becomes unavailable. |
| model-behavior | A model acts against its instructions or safeguards. |
| supply-chain | Malicious models, packages, plugins or MCP servers. |
Severity scale
Severity rates the effect of the incident, not the organization or the system.
| Level | Name | Threshold |
|---|---|---|
| SEV1 | Critical | Irreversible harm, or an effect on more than 1 million users. |
| SEV2 | High | Serious but recoverable harm, or an outage of a major service that lasts more than 4 hours. |
| SEV3 | Medium | A limited effect on one organization. |
| SEV4 | Low | A minor effect, resolved without lasting consequences. |
For research-demo and near-miss entries the scale rates the effect that would have occurred. These ratings are marked as potential and shown with a hollow marker.
How to read the numbers
The number of entries is not a failure rate for any system or organization. It reflects what was disclosed publicly and what we had the sources to document. An organization that publishes detailed postmortems will appear more often than one that discloses nothing.
Editorial rules
- Every claim about an organization has a source. No source, no entry.
- We write what the source states, for example “according to the company’s postmortem”. We do not assign blame or intent.
- Cause and failure mechanism are given only as far as the source gives them.
- Contested cases are marked
disputed, with both sides stated. - We do not name individuals, except official spokespeople in a public company statement.
- We describe the type of vulnerability. We do not publish working exploits or attack prompts.
- Sources are summarized in our own words. Quotes are short.
- Candidates are collected automatically, but publication is always manual. No entry appears without human review.
Independence
Incidents.si is an independent project and is not affiliated with the organizations named in its entries. Company names appear as plain text, without logos.
A sponsor of the weekly digest, when there is one, is clearly labeled and has no influence on entries. An incident involving a sponsor is published by the same criteria as any other.
Corrections policy
- Anyone can request a correction by writing toeditor@incidents.si with the entry ID and a source.
- We reply to correction requests within 72 hours.
- Every correction is recorded in the entry’s history with its date.
- An entry that no longer meets the criteria is marked
retractedand stays online with its history.
Contact and publisher
Contact: editor@incidents.si
Publisher: [PUBLISHER NAME AND ADDRESS]
See also the privacy policy.