Definitions

The rules we use to decide what is an incident, what is a report, and what we leave out. A person applies them to every item before it goes live.

Public incidents and testing incidents

Every incident is filed as a public incident or a testing incident, assigned by these rules, most serious first. A staged scenario is a kind of testing incident:

Public incident
The most serious type. One or more specific events in which a model or agent misbehaved (reached systems, data or accounts it was not meant to, broke out of a sandbox, deleted or changed things, used a tool in an unapproved way, deceived, hid something or sabotaged work), and that were not a staged scenario. It counts as a public incident when it happened in public-facing or deployed use, when it touched real systems, institutions or people outside the lab's own test setup, when the researchers did not catch it as it happened (it was found later in a review, an audit or a postmortem), or when the publisher itself calls it an incident, postmortem or disclosure. "Public" does not mean "in a public product": a test or an internal-use run that reached real websites is a public incident, and its two labels (Ran in, Affected) say exactly where it ran and what it touched.
Testing incident
One step less serious than a public incident. A model really misbehaved (cheated or hacked its reward, lied, held back on purpose, schemed, sabotaged, resisted shutdown or took actions it should not have) during a test, evaluation, audit, red-team exercise or training run that researchers set up and watched. Nothing outside the lab was affected and nothing was hidden from the researchers for long. The setup was not designed to provoke the behavior. It can be a single case, several cases, or rates across many runs.
Staged testing incident
A kind of testing incident in which the scenario was staged on purpose, such as a simulated company or a red-team test set up to provoke the behavior, and the model actually did the wrong thing.

Where it ran and what was affected

Every incident also carries two short labels, because a test can have real consequences outside the lab and a public product is not the only place a real system can be touched:

Ran in: training
The behavior happened while a model was being trained.
Ran in: evaluation
It happened in a test, audit, red-team exercise or staged scenario.
Ran in: deployed use
It happened while the model was in real use, public or internal.
Ran in: not stated
The reports do not say.
Affected: simulated environment
Only a test or training setup, or invented people and companies, was involved.
Affected: real external system
A real website, service, account or organization outside the lab that ran the model was reached.
Affected: real internal system
The lab's own real systems were reached.
Affected: not stated
The reports do not say.

Kinds of behavior

Each incident is also tagged with the kinds of behavior it involved, and may have several:

Went past a limit
The model went beyond a limit, scope or instruction it was given.
Hid something
It concealed, withheld or misreported what it did or could do.
Gamed a test
It cheated or took a shortcut to score well without doing the task as intended.
Used access it shouldn't have
It used credentials, systems or data it had not been given permission to use.

Notices and updates are not a kind of their own. When an organization later publishes a notice or an update about an incident that is already recorded, it is pinned to that incident and listed under the title of the first report.

What counts as misalignment

An AI model is misaligned when it does, or is shown to do, something its developers, operators or users did not intend. We count four kinds:

  • Acting against intent: cheating or reward hacking, ignoring limits, unauthorized actions, going beyond the task.
  • Deception and concealment: lying, hiding actions or abilities, sandbagging (holding back on purpose), alignment faking, scheming, sabotage, covering tracks.
  • Power and self-preservation: resisting shutdown or modification, copying itself (including tests of whether models can copy or spread themselves), seeking extra access or resources, blackmail or threats, escaping a sandbox.
  • Unintended learned behavior: emergent misalignment or unwanted traits picked up in training. Sycophancy counts only when it is a side-effect of training.

Reports and research

Besides the incident reports themselves, the site summarizes research and work on alignment: efforts to prevent, find or contain misalignment.

Research or test
Reports where no model misbehaving is the main finding: methods, tools and training techniques, benchmarks, audits or evaluations that found nothing, risk reports and frameworks, interpretability, and staged scenarios in which the model did not misbehave.
  • Making models behave as intended: training or other methods, such as alignment training, specs and constitutions, or fine-tuning fixes, that were tested against misalignment.
  • Detecting and auditing: evaluations, audits, monitors, probes, interpretability and AI-control work whose purpose is to find or contain misaligned behavior.
  • Risk reports and frameworks: safety cases, risk reports, testing frameworks, roadmaps and standards about misalignment risk.
  • Concepts and research agendas: definitions, theory and agendas about alignment, as formal publications by the organization.

What we leave out

Even when a report is about AI safety, we leave out:

  • Misuse and capability tests: people misusing AI (jailbreaks, cyberattack or biological uplift), and capability evaluations in which the model did nothing misaligned (tests of self-replication, escaping with its own weights or gathering resources on its own are the exception, and are included).
  • Bias, toxicity and hallucination: model-quality problems that are not about acting against intent.
  • Policy and commentary: regulation, policy and opinion with no model behavior, test or method behind it.
  • Product and privacy safeguards: content moderation, privacy and the security of a model's infrastructure.
  • Talk without findings: podcasts, interviews, testimony, reading lists, how-to guides and opinion posts, unless they report a new finding: a test, a method, a specific event, a formal assessment or an organization's formal statement.

Which reports we include

A report is included when it is original (published by the organization that ran or studied the model, or a paper whose authors work at such organizations), in scope under the definitions above, and a finding rather than talk. We never use news coverage or social media. A person approves every report before it goes live.

Organization types

Each report is labelled with the type of its lead author's organization, and every organization on the Sources page shows its type:

Frontier AI lab
A company that builds the most capable general-purpose AI models, such as OpenAI, Anthropic and Google DeepMind.
AI company
A company that builds or sells AI products or tools but is not one of the frontier labs, such as Apple, ByteDance or Snowflake.
Government institute
A public body that tests or studies AI for a government, such as the UK AI Security Institute.
Independent evaluator
An outside group whose main job is testing AI models and publishing what it finds, such as METR, Apollo Research or Palisade Research.
Research group
A non-profit, fellowship or small research organisation that studies AI safety and alignment but is not mainly a testing service.
University or institute
A university or academic research institute.
Independent researcher
One or more researchers publishing as independent researchers through one or more organizations, such as a preprint server. The publisher is named on the report but is not treated as the organization type. If they publish through a university or institute, the report is listed under University or institute instead.