For the fourth consecutive year, broken access control holds the top spot on the OWASP Top 10. Not second. Not climbing. First — and according to OWASP‘s own testing data, present in 100% of the applications they evaluated.
That’s not a developer problem. That’s an architecture problem. And if your organization is deploying agentic AI, it just became your most urgent security problem.
What Broken Access Control Actually Means
Broken access control means a user, device, or service can reach resources it was never supposed to touch. Wrong account. Unauthorized API. Privileges that exceed the role.
The reason it’s still #1 isn’t ignorance. Security teams know the fix: enforce least privilege, validate server-side, deny by default. The problem is friction. Permissions get set broadly to avoid breaking things. Service accounts accumulate access over time. Nobody audits what they don’t have to audit. The gap between what entities are allowed to do and what they should be allowed to do just… stays open.
The Agent Problem is the Age-Old Permissions Problem
If you’ve been thinking about agentic AI security at all, you’ve probably started with the right question: what identity does an agent use, and how do we control it? (If you haven’t started there yet, our previous post on applying zero trust principles to agentic pipelines is a good place to start.
But broken access control makes that question harder to answer — because the problem often exists before the agent arrives.
When your environment already has overpermissioned service accounts, APIs without proper access controls, and roles that haven’t been reviewed since they were created, you’ve built a runway. The agent doesn’t have to be compromised to cause damage. It just has to do its job. And that’s the part that doesn’t show up in your threat model. No attacker. No malicious intent. Just an agent executing a legitimate task with more access than it should have, at machine speed, with no human in the loop to notice it went somewhere it shouldn’t.
The Blast Radius has Changed
Security teams have always understood that broken access control is bad. The risk calculus has shifted because the entity on the other end of that permission has changed.
A human user with excessive privileges is a risk. An AI agent with excessive privileges, running autonomously at machine speed, across a multi-step workflow that no human is monitoring in real time, is the kind of risk that gets a CVE number, a catchy name, and a segment on the evening news.
That last variable — time to detection — is the one that matters most. Agents are already running in production. Most organizations have no way to distinguish between “an agent doing what it was told” and “an agent doing what it was told, plus everything it had access to.” If the permissions exist, your SIEM won’t blink.
What Actually Fixes This
The answer isn’t a new framework. It’s doing the foundational work that broken access control has always demanded — and being rigorous about applying it to non-human identities.
That means genuine least privilege enforcement, not aspirational documentation. Permissions defined by what the agent’s current task actually requires, not by what’s easiest to configure and least likely to break something. It means access controls enforced at the network layer — not just at the application layer, where broken access control has historically lived — so that even a misconfigured API can’t be reached by an entity that has no business reaching it. And it means continuous verification: not just asking “is this agent authenticated?” but “is this action consistent with what this agent was authorized to do?”
None of this is new thinking. What’s new is the urgency. An environment with endemic broken access control was a chronic risk when the entities exploiting it were human. When those entities are autonomous, fast, and multiplying, chronic becomes acute.
The OWASP data has been telling us broken access control is everywhere for four years running. AI agents are telling us it’s time to actually fix it.