The Orca AI Incident Archive: 354 Real AI Agent Incidents, Each With a Receipt

A security team can tell you precisely how well a model resists prompt injection inside a test harness. What almost no one can tell you is how many organisations were actually breached by an agent last month, which of those breaches had a confirmed victim, and which of the numbers quoted in the write-up came from the vendor rather than from a regulator. That gap — between what models might do and what has already happened — is the gap the a href="https://www.orcarouter.ai/incident-archive">Orca AI Incident Archive/a> was built to close. It went live on 23 September 2026 and, as of its 22 September data cut, holds 354 records drawn from 593 unique sources.

Accuracy note: every figure below is read from the archive's own published code>dist/stats.json/code> at version 2026-09-22 and from the live page. The launch announcement on 23 September quoted 340 records, 548 sources and 126 with confirmed harm; those were the figures at the moment of posting, and the archive is updated continuously, so the two sets differ by roughly a day of intake. Where the archive's README and its live page have disagreed on a badge number during development, the live page and the JSON export are the ones to trust.

What the archive actually contains

It is not a news feed and it is not a CVE list. Every entry is a single Markdown file with structured frontmatter, filed under the month the event happened, and every entry carries at least one source. The dataset is published under CC BY 4.0 and mirrored in a public repository, so the whole thing can be cloned, diffed and cited rather than screenshotted.

The coverage window runs 22 months, from a December 2024 precursor through to 22 September 2026, and the distribution is the interesting part. Severity splits 45 critical, 139 high, 77 medium, 8 low and 85 informational. Source confidence splits 302 grade A, 47 grade B, 2 grade C and 3 grade D. Confirmed real-world harm is recorded for 127 records, explicitly ruled out for 142, and left null for 85.

Those last three numbers are the reason the archive is worth reading carefully rather than skimming. A count of 354 records is not a count of 354 incidents. Only 138 of them are classified as an incident at all; the rest are vulnerability disclosures, research demonstrations, threat reports and policy moves. Counting all five together is exactly how a headline number goes wrong, which is why the archive keeps them apart and lets you filter.

Why "a jailbreak is not an incident" is the whole point

Most collections of AI security events collapse one distinction: an agent that actually caused damage is not the same thing as a researcher showing that it could. That single conflation is what turns a conference demo into a breach headline, and it is what the archive is built to refuse.

Three fields carry that weight. code>real_harm/code> records whether a victim was confirmed. code>ai_involvement/code> records whether a primary source — the vendor, the victim, law enforcement or an official report — confirmed the AI's role, with disputed attributions kept in the dataset but labelled. code>kind/code> records what sort of document the entry is. A record with no source does not enter. A record with conflicting evidence is marked disputed rather than resolved in whichever direction reads better. When new evidence arrives, the record is updated and the change is written into its revision history rather than silently overwritten.

The archive has applied that rule to itself. During its own verification rounds it deleted two entries that could not be substantiated, corrected a widely repeated claim about how fast one intrusion progressed, and downgraded a third entry's confidence grade when the underlying evidence turned out to be second-hand. An incident database that has never removed anything is a database that has not been checked.

The twelve attack surfaces it sorts by

Every record is tagged with one or more of twelve types, and each type carries its own month-by-month count. Governance and policy is the largest bucket at 65 records, but only one of those has confirmed harm — which is the correct shape for regulatory activity and a misleading one to quote as an incident count. Credential abuse follows at 55, with 40 confirmed victims, the highest harm density in the set. Agent-as-a-weapon sits at 51 with 28 confirmed. Indirect prompt injection has 45 records but only 5 with confirmed harm, which is the clearest illustration of the capability-versus-consequence split in the whole dataset: it is the best-studied attack class and one of the least productive ones in the wild. Supply-chain poisoning, at 36 records, has 27 confirmed victims — the worst ratio on the board.

September 2026 is the month that makes the case

Fifty-one records landed in September 2026 alone, more than double any previous month in the window. That is not a sudden collapse in security. It is a month in which the record-keeping finally caught up with a year of accumulated events, and the composition is what matters: critical entries for a malicious code>.git/config/code> that executes attacker code in seven coding agents before the model is ever contacted, for a Langflow flaw exploited in the wild, for an AI agent swarm campaign at a print-management vendor, and for an npm worm that enters the chain upstream. Alongside them sit informational entries on the OWASP Agent Control Standard, an EU State of the Union address that named agent escapes, and a United Nations panel brief that treated one incident as a loss-of-control warning.

The Korean entries, and what a region field does not mean

The archive's code>region/code> field marks where an event actually landed, not where the vendor is headquartered — cross-border vendor disclosures are always filed as global, which is why 291 of 354 records carry no single-country tag. Two records carry the KR tag, both policy entries with grade A sourcing and no confirmed harm: South Korea's removal of DeepSeek from domestic app stores in April 2025, and the company-wide ban on OpenClaw adopted by Naver, Kakao and Karrot in February 2026.

That restraint is deliberate. A region count of two is not a claim that Korea has had two AI security events. It is a claim that two events in the window landed in Korea with a primary source strong enough to file — and the archive would rather publish a small honest number than pad a country page with events that happened to a Korean company's customers somewhere else.

How to read the confidence grades before you cite one

Confidence is about source quality, not severity, and a grade of D does not mean false — it means the parties disagree and you should not cite one side alone. Grade A means a primary source: the vendor, the victim, law enforcement or an official report. Grade B means a research lab or a major outlet with checkable detail. Grade C means second-hand only. Grade D means the facts or the attribution are disputed. At 302 of 354 records, grade A is 85% of the dataset, which is unusually high for incident reporting and is the direct result of the no-source-no-entry rule.

The honest caveats are worth stating plainly, because the archive states them. Two records remain grade C and three grade D. Eighty-five records carry informational severity because they are policy or threat-report entries kept for timeline continuity, not incidents. The repository is three weeks old and carries no stars, no releases and no external audit of its own methodology — it is a dataset published in the open, not a peer-reviewed study.

Why this matters more than another benchmark

As agents acquire browsers, shells, credentials, code execution and production access, the security question stops being what a model is capable of and becomes what has already been done with one. Benchmarks answer the first question well and the second one not at all. An archive of incidents, graded by source quality and filtered by whether anyone was actually harmed, is the only kind of instrument that answers the second — and it only works if the entries are traceable, correctable and free to reuse.

That is what is now open. The dataset is at a href="https://www.orcarouter.ai/incident-archive">orcarouter.ai/incident-archive/a>, the raw Markdown, the JSON and CSV exports and the schema are in the a href="https://github.com/Continuum-AI-Corp/Orca-AI-Incident-Archive">public repository/a>, and corrections go through the record's revision history. If you know of an event that belongs in it, the contribution path is one Markdown file and at least one source. No source, no entry.

OrcaRouter, which publishes the archive, runs a single OpenAI-compatible endpoint across more than 200 models with no markup on provider pricing and automatic failover between them — the same routing layer that makes it possible to point an agent at a cheaper model for the easy calls and a stronger one for the hard ones, which is exactly the architecture most of the incidents above were found in.