Rogue AI Agent Tracker
The AI agent incidents we could actually confirm, from deleted databases to full-blown breaches.
The 56 so far, at a glance
33
Accidents
18
Attacks run through an agent
5
Eval escapes
How the 33 accidents ended
Only 7 of the 33 are known to have gotten everything back. In 6, the backups were hit too, or there weren't any. Before an agent runs migrations, check that its credentials can't delete your backups, and that you have some.
AI agent incidents, newest first
Get updates when there's another one. Know one we missed? Email us
How we count
What counts
An AI agent’s own actions damaged production data, backups, or cloud resources, or took a service down. Two more kinds of cases count too, and each gets a tag. When an attacker uses an AI agent, or hijacks one, to break into real systems, the row is tagged Agent-assisted attack. When a model in testing or training gets out and reaches a real organization’s systems, and the vendor or that organization confirms it, the row is tagged Eval escape.
What doesn’t Count
Damage that stays on someone’s own laptop or inside a test environment, escapes that never leave the lab, demos, and mistakes a person made without an agent. Ransomware with no agent involved goes on the ransomware incident tracker. Cases with a disputed cause or no credible source stay off the page until that changes.
How we source
Each row links the best source we could find, and the label next to it says what kind it is. Usually that’s the affected organization’s own statement, the developer’s post or bug ticket, security research, or a regulator. Most accidents are self-reported, since the developer who got burned tends to post before anyone else does. We review and approve every row.
