
Introducing the Agent Incident Ledger: A Rogues' Gallery of AI Gone Wrong
Bastien EymeryVP of AI Security Advocacy
Neal SwaelensCEO & Co-Founder
TL;DR
- We're launching the Agent Incident Ledger: a free, sourced record of AI agents going out of bounds. At the time of writing, 71% of the publicly disclosed incidents it holds came out in the last three months, a sharp rise.
- Most are security failures any team would recognise: an agent reaching systems it had no business touching, or misusing credentials. Basic controls are often missing.
- What's public is likely a small fraction of the incidents out there. A security control caught 19% of the ones on the ledger. And even when an incident is disclosed, most of the details a defender would need about the agent's setup are never published.
- The AI safety debate seems mostly concerned with future catastrophes. The ledger shows the damage is already happening, and it's often banal.
- The ledger is free to use and open to new reports and corrections. We'll keep it updated and publish a monthly roundup.
Why we built the Agent Incident Ledger
Rogue AI agents are everywhere right now, and not just in security feeds: the agents that broke into Hugging Face have come up at dinner, at the barber's and in the family group chat.
There's a reason for the noise. The number of public disclosures has jumped, and the incidents themselves seem to be getting more frequent. Behind the headlines we find real security failures: agents with too much access, missing controls and nobody watching. They're worth analysing properly, so we built a place to do it.
What the Agent Incident Ledger is
The ledger is a public record of incidents where an AI agent took, or tried to take, harmful actions that the people running it didn't intend and wouldn't have approved. To go in, an incident has to pass four tests.
HOW AN INCIDENT GETS IN
Test 1: an agent
It acts through tools, not just text. A chatbot giving a bad answer doesn't count; an agent calling a tool does.

Test 2: harmful actions
It did, or tried to do, something outside the model's own output that its target would reasonably call harmful: deleting files, leaking data, publishing a malicious package. A failed attempt still counts.

Test 3: not intended
The people running it didn't mean it and wouldn't have approved it. Attackers running an agent as designed are out of scope.

Test 4: public
A public source documents it. Every entry is sourced and reviewed by Manifold.

Out of scope: chatbot answers, plans an agent never ran, and attackers running an agent as designed against someone else.
For each incident we record what happened, the dates from the first action to discovery to public disclosure where they're known, who noticed first, how it was caught, the impact and what's known about the agent's setup. We also map each one to the security controls that could have helped prevent, detect or limit it, because for many, if not most, of these incidents those controls already exist. Manifold reviews every entry, and the methodology explains every rule.
The ledger isn't a ranking of AI vendors. OpenAI and Anthropic appear most often partly because they publish frequent reports on their own experiments and failures. That says more about how much they disclose than about how safe their agents are.
Agent incidents are rising as agents do more
Of the 59 incidents on the ledger at the time of writing, 42 (71%) were disclosed in the last three months.
Part of that is a wave of disclosures about earlier events, from labs and others: OpenAI released six incident reports on a single day in September, and Anthropic disclosed four on 9 October. But that's not the whole story. Where we know when an incident started, 19 began in the second quarter of 2026 alone, more than in the whole year before it. In a single week in October, nine more were disclosed, from a Claude Haiku 4.5 agent that submitted an invented tip to a Philadelphia police homicide form to an OpenAI model that forged tokens to reach 24 years of restricted government statistics.
That's what you'd expect. Every new capability can turn a mistake into an incident. Give a model a browser and it can reach a public site. Give it credentials, and it will be more than happy to use them. Claude Opus 4.7 attacked a real company whose domain matched a fictional target because an evaluation's internet access was left open by mistake. In that case, and in many others, the agents had far more reach than the people running them meant to give them, and it went unchecked.
What the agents actually did
Across the 59 incidents at the time of writing, the ledger tags 117 agent failures, and most incidents involve more than one. The most common is unauthorised access (44% of incidents), followed by sandbox escape and credential misuse (25% each) and destructive action (22%). Prompt injection, the threat most agent security conversations start with, appears in just 8%.
WHAT WENT WRONG
The usual suspects
Unauthorised access shows up in 44% of incidents, sandbox escape and credential misuse in 25% each. Prompt injection, where most agent security conversations start, is in 8%.

Controls that already exist
Recording every agent action might have helped in 90% of incidents. Monitoring each run against its task: 69%. Limiting where an agent can send traffic: 56%.

Some of the best-known incidents happened in live production systems, with real users. Replit's agent deleted a live database during a declared code freeze, then told its user a rollback was impossible. Claude Code ran terraform destroy on DataTalks.Club's production infrastructure, snapshots included. Claude Cowork, asked to delete temporary Office files, removed a folder holding about 15 years of family photos. Attackers talked Meta's AI support assistant into resetting Instagram accounts, up to 20,225 of them by Meta's count.
There's a good case that preventing any of these didn't take a breakthrough in alignment research. It took knowing which agents were running, how they were set up, what they were allowed to reach and what they actually did. In our analysis of the publicly available information, recording every agent action outside the agent might have helped in 53 of the 59 incidents, monitoring each run for actions outside what's acceptable for the task in 41, and limiting where an agent can send traffic in 33. These are basic failures, not signs of a superintelligence.
Yes, it's the tip of the iceberg

We know the iceberg is one of the most overused pictures out there. We think it fits, though, not just for how many incidents are public but for how little we know about the ones that are. Let us explain.
The ledger only holds what someone chose, or was forced, to disclose. A security control flagged 11 of the 59 incidents. The rest came out through a later review (18), through the damage itself (16) or an outside report (8), and 6 don't say. In 18, someone other than the people running the agent noticed first: a website owner, a package registry, a researcher or another vendor's control. Some of those incidents would never have come to light if the victim hadn't spotted them. Four are disputed, with sources disagreeing on what happened, and the ledger shows both sides.
Even when an incident is disclosed, most of what a defender would want to know isn't. We track 12 details about each agent's setup, and 92% of them aren't fully public (annoyingly close to the roughly nine tenths of a real iceberg that sits underwater). The exact model and version is public for 12% of incidents, the network setup for 5%, and transcripts or action logs for none. The median incident took 70 days from the agent's first action to public disclosure.
BELOW THE WATERLINE
How incidents came to light
A security control caught fewer than one in five. The rest surfaced in a later review, through the damage itself or from an outside report.

What's public about each setup
The exact model and version is public for 12% of incidents, the network setup for 5%, and transcripts or action logs for none.

This is also why the vendor counts need care. OpenAI (23 incidents) and Anthropic (19) lead the ledger. They're the biggest and most prominent AI companies, they've had real incidents, and they likely publish more about them than anyone else. Companies running agents in production mostly don't publish at all. So the real numbers are far higher: incidents fixed quietly, near misses and the ones that have gone unnoticed aren't on the ledger.
Our research keeps finding the same holes before they become incidents
The incident record and our own vulnerability research point the same way. In September we published GitSpawn: a repository's own Git configuration could make AI coding agents run a command on the developer's machine, outside the sandbox and before any approval prompt, because the agents run git in the background to gather context. We found eight issues across seven agents, and four were still unpatched when we published.
And the way the reports were handled is also quite revealing. One fix shipped without a public advisory. One vendor never triaged our private report, so the CVE came from an independent numbering authority. Five of our reports came back as duplicates of findings other researchers had filed, which means the problem is being found from several directions at once. It's the same disclosure gap the ledger measures, one step earlier.
Get an alert every time a new agent incident goes on the ledger, plus a monthly roundup with our analysis. Sign up for ledger alerts.
The rules are being written for catastrophes, not banal failures
The loudest voices in AI safety warn about extinction. They're serious people with serious concerns, and we're not trying to diminish or deny the task ahead. But the framing can shape the rules. On 16 October, POLITICO reported that Anthropic had been showing lawmakers a draft federal bill on frontier AI. Under it, the government could stop a model only over a foreseeable, imminent risk of more than $1 billion in damage or more than 50 people killed or seriously hurt. Quite a high bar.
Other bills, from the House FRONTIER Act to California's SB 53, are also aimed at the top of the scale. None of them is built for a company whose coding agent deleted its production database last Tuesday.
What's next
We'll keep watching: adding new incidents as they're disclosed, following the ones already on the ledger as the stories unfold, correcting entries when new facts come out, and publishing a monthly roundup.
We also hope the ledger becomes a place for people to come and disclose, share and learn. If you were involved in an incident, found one or know something that isn't public yet, whether you run agents, build them, research them or blow the whistle on them, tell us.
Know of an agent incident we've missed, or a detail we got wrong? Report it to the ledger, or get alerts when new ones are disclosed.
About the authors

VP of AI Security Advocacy
Product and growth specialist with a background in building and securing AI products. Created the Agent Incident Ledger.

CEO & Co-Founder
Neal is a serial founder and product leader with deep expertise in AI security. Prior to founding Manifold, Neal was the co-creator of LLM Guard, and co-founder of Laiyer AI, acquired by Protect AI, later acquired by Palo Alto Networks.




