Ninety documented AI agent security incidents from this year alone is enough data to stop treating each one as a freak accident and start asking what they actually have in common. Individually, each incident reads like a specific, unlucky failure. Looked at together, a much smaller number of root causes accounts for most of them.
The Pattern Isn’t “The AI Did Something Unexpected”
The instinct is to treat an AI agent security incident as fundamentally different from a normal security incident, something about the model behaving unpredictably. Most of the 90 don’t actually fit that story. The agent usually did exactly what it was built to do. The failure was in what it was allowed to do, not in some surprising leap of reasoning nobody could have predicted.
Where the Incidents Actually Cluster
Over-scoped permissions, by a wide margin. The single biggest cluster is agents given broad access “to be safe” or “to avoid friction,” where a narrower, task-specific permission would have contained the same incident to a non-event. An agent that can only touch what it needs to touch has a much smaller blast radius when something goes wrong, and most of these incidents happened precisely because that scoping was skipped.
Prompt injection through content the agent was trusted to process. A meaningful share of incidents trace back to an agent treating untrusted input, an email, a document, a scraped web page, as if it were a trusted instruction. This isn’t a subtle vulnerability. It’s a design assumption (that content is safe to act on) that doesn’t hold up once an agent can actually take actions based on what it reads.
No effective human checkpoint before a consequential action. Several incidents involved an agent taking an action that would have been an obvious problem to a human reviewer, if a human had actually been in the loop at that step. The pattern isn’t “no oversight existed.” It’s oversight that existed on paper but wasn’t actually positioned before the action that mattered.
Credentials and access that outlived their purpose. A smaller but real cluster involved agents retaining access or credentials well past the task that justified granting them, turning a temporary, task-scoped risk into a standing one.
Why Treating These as One-Offs Makes the Next One More Likely
Every incident that gets handled as an isolated, unfortunate event without asking “which of the four patterns above does this fit” is a missed chance to fix the actual systemic cause. Ninety incidents that mostly trace back to four root causes isn’t ninety separate problems. It’s four problems that happened ninety times, and fixing the underlying pattern is a fundamentally different, more durable response than patching the specific incident in front of you.
What This Actually Means for How You Deploy Agents
Default to the narrowest permission that completes the task, not the broadest one that avoids friction. This single change would have prevented the largest cluster of incidents in the dataset.
Treat any content an agent processes as untrusted input by default, the same way a web application treats user input, rather than assuming it’s safe because it came from an internal source.
Put the human checkpoint at the actual point of consequential action, not somewhere earlier in the pipeline where it looks like oversight but doesn’t actually catch anything.
Scope credentials to the task’s actual lifetime, and make sure the access expires when the task does, not indefinitely by default.
The Bottom Line
Ninety incidents sounds like ninety different failure stories. It’s closer to four design mistakes, repeated at scale, because most agent deployments make the same permission and trust assumptions by default. The fix isn’t more caution about AI specifically. It’s the same access-control discipline that’s applied to any other system that can take real actions, actually applied this time.