What OWASP misses about LLM agents

The OWASP Top-10 for LLM Applications was a good start. It gave teams a vocabulary, a checklist, and — critically — permission to have the security conversation about AI features that product was shipping regardless. I’ve used it in reviews. I’ve recommended it to clients. I’ve printed it out and stuck it on a whiteboard during a particularly tense sprint retrospective.

But it has a blind spot, and it’s a structural one: the list was written for applications that use LLMs, not for agents that are LLMs. The distinction matters more than it looks.

The agent is not a feature

When you bolt a chat window onto your SaaS product, the LLM is a feature. It takes input, returns output, and the application around it decides what to do with that output. The attack surface is bounded by what the application lets the model do — which, in a well-designed system, isn’t much.

An agent is different. An agent has tools. It can read databases, call APIs, send emails, execute code. The model isn’t producing suggestions for a human to approve; it’s making decisions and acting on them. The attack surface isn’t bounded by the application anymore. It’s bounded by the agent’s capability set — which, in most systems I’ve reviewed, is far too large.

The column I’d add: Capability Overprivilege

The list has “Excessive Agency” (LLM07), but the framing is too gentle. It talks about granting excessive functionality, permissions, or autonomy. What it should say, plainly, is: most agents have access to tools they don’t need for the current turn, and this is the single most exploitable property of the system.

The fix isn’t a prompt telling the agent not to use certain tools. The fix is not giving it the tools in the first place — not globally, but per-turn. Dynamic capability scoping. The same principle behind principle-of-least-privilege, applied to a system that decides what it wants to do by reading English.

The column I’d quietly remove

I’d demote “Insecure Output Handling” (LLM02) from a standalone category. Not because it doesn’t matter — it does — but because it’s a symptom, not a root cause. In an agent architecture, insecure output handling is what happens when you’ve already failed at the more fundamental task of separating the model’s decision layer from the system’s execution layer.

If you get the architecture right — if the model proposes and the system disposes — then output handling becomes a standard engineering problem. If you get it wrong, no amount of output sanitization will save you, because the model will find a way to express its intention in a format your sanitizer doesn’t expect.

What a revised list might look like

I’m not going to rewrite the whole thing. But if I were advising the working group, I’d push for three changes:

1. Split the list into two tracks: one for LLM-as-feature, one for LLM-as-agent. The threat models are different enough that a combined list forces awkward compromises.
2. Add Capability Overprivilege as a top-3 item on the agent track. It’s the architectural equivalent of running your web server as root.
3. Add a “Confused Deputy” category that explicitly addresses the case where an agent with legitimate access is tricked into using that access on behalf of an adversary. This is the 1988 problem, and it’s back.

The OWASP list is a good foundation. It just needs to catch up with what teams are actually building.