AI Agent Incident Register

Methodology

The Register documents AI agent incidents and analyzes them legally. Each entry asks four questions: what happened, which legal duty was engaged, who bears liability across the chain, and what governance would have prevented it. This page describes how entries are made, so readers can judge the work and cite it with confidence.

What counts as an entry

An incident qualifies when an AI agent (a system that takes actions: executing commands, holding credentials, transacting, publishing, or advising with delegated authority) caused or nearly caused real-world harm, and the public record is rich enough to support a responsible legal analysis. Four classes appear in the Register:

• Enterprise agent incidents — deployed agents causing harm in production
• Coding agent incidents — development agents with shell, repository, or credential access
• Demonstrated vulnerabilities and near misses — research findings analyzed for the liability that exploitation would have produced, always labelled as demonstrations
• Legal proceedings and crystallized outcomes — decided cases, regulatory actions, and live litigation involving agent conduct

Sourcing standards

• Every entry rests on at least two independent public sources, at least one primary: a court or tribunal decision, a regulator notice, a first-party disclosure or postmortem, or an established incident database entry.
• Every load-bearing fact is attributed inline. Direct quotes are verbatim with named speakers.
• What the public record does not establish is stated as a gap, in the entry, rather than papered over.
• Threat-actor references follow the investigating firm's designations. A tracking label is a cluster designation, never an identification.

The analysis is analysis

Liability sections set out how liability would plausibly allocate on the public facts, under the legal frameworks engaged (GDPR and UK GDPR, the EU AI Act, contract, negligence, agency principles, and sector rules where relevant). Conclusions are framed conditionally where facts are incomplete. Allegations in live proceedings are described as allegations. Nothing in the Register is an assertion that any named party broke the law, and nothing here is legal advice.

Entry IDs and corrections

• Entries are numbered AIR-YYYY-NNN in publication order. IDs never change and are never reused — cite an entry as its ID plus URL, e.g. AIR-2026-001, companyscope.io/register/air-2026-001.
• Corrections and updates publish as dated addenda at the foot of the entry. Original text is not silently edited.
• Entries are re-reviewed quarterly; the last-reviewed date updates on every review.

Framework mappings

Where the fit is real, entries map to the OWASP Top 10 for Agentic Applications, Singapore IMDA's Model AI Governance Framework for Agentic AI, and runtime-control references. The Register sits alongside the security-side incident trackers; its distinct contribution is the per-incident legal layer. Partial fits are flagged as partial.

Who writes this

Michael K. Onyekwere — CIPP/E, common law qualified lawyer practising as a Data Protection Officer, founder of Janus Compliance. Research support uses AI tooling against public documentation; every entry is reviewed and edited by him before publication, and the legal analysis is his judgement.

Suggest an incident or flag an error: use the form on any entry, or contact Janus Compliance. Back to the Register.