ISO/IEC 27001:2022 audits passed with zero nonconformities.Find out more
Hand-drawn illustration of an investigator studying a cork board of robot mugshots connected by red string.

Introducing the Agent Incident Ledger: A Rogues' Gallery of AI Gone Wrong

Oct 27, 20267 Min

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.

Illustration: in, an agent wired to tools such as shell, HTTP, files and browser; out, a chatbot suggesting a database command that nobody runs.

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.

Illustration: in, an agent command that deletes backups, with harms such as backups deleted, data leaked, a malicious package published, and a blocked attempt that still counts; out, a written plan that was never executed.

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.

Illustration: in, a team asks an agent to fix a failing test and it deletes the staging database; out, an attacker using an agent against a victim as designed.

Test 4: public

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

Illustration: in, public sources such as postmortems, news, GitHub issues and papers reviewed by Manifold into a sourced ledger entry; out, rumours and unsourced screenshots.

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.

0204060 Jul 2025OctJan 2026AprJulOct
Running total of incidents publicly disclosed, by month, to 15 Oct 2026. Source: Agent Incident Ledger, figures as of 23 Oct 2026.

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%.

Bar chart of the share of incidents involving each agent failure, led by unauthorised access at 44%, with prompt injection highlighted at 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%.

Bar chart of controls that might have helped: recording every agent action 90%, monitoring each run 69%, limiting network 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

An iceberg: a small red tip above the waterline, labelled with the incidents on the ledger, and a much larger grey mass below it.
What's on the ledger is the tip. Below it: incidents never noticed, fixed quietly, or near misses never written up.

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.

Bar chart of how incidents came to light: later review 31%, the damage 27%, a security control 19%, an outside report 14%, not disclosed 10%.

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.

Bar chart of setup details made public: exact model and version 12%, network setup 5%, transcripts or action logs 0%.

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

  • Bastien Eymery

    Bastien Eymery

    VP of AI Security Advocacy

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

  • Neal Swaelens

    Neal Swaelens

    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.