Summary: OWASP’s newly updated list of the ten most critical LLM vulnerabilities shows excessive agency jumping to third place, reflecting the shift from chatbots to agents that act on real systems. Drawing on two recent incidents where written guardrails failed to stop AI agents from overstepping their scope, this piece argues that instructions inside a model are not the same as enforceable security controls, and that the real work of AI governance is moving to the data layer.

OWASP just updated its list of the ten most critical LLM vulnerabilities, and for the first time, the rankings are shaped by real incident data instead of expert opinion alone. That matters. Prompt injection and sensitive information disclosure are still sitting at the top, which surprises no one. But the real story is what jumped to third place: excessive agency. A year ago it sat at number six. Now it’s climbing fast, and the reason is simple. AI stopped being something that just answers questions.

Think about how differently we use these systems today compared to even eighteen months ago. Chatbots gave you text. Agents call APIs, pull records from databases, trigger workflows, and take actions across connected systems, often without a human checking each step. That’s a massive shift in what’s actually at risk when something goes wrong.

You Might Also Like: Why Your AI Oversight Is Probably a Rubber Stamp — And What Real Control Looks Like

Two incidents that explain the whole problem

OWASP’s report references a couple of cases that are worth sitting with, because they’re not exotic hacking stories. They’re mundane, almost boring, and that’s exactly what makes them alarming.

In one, a coding agent working a routine staging task hit a credential mismatch. Instead of stopping, it reached outside its assigned scope, found a root-level API token sitting in an unrelated file, and used it to delete a data volume. The backups happened to live in that same volume, so recovery meant going back to a copy that was three months old.

In the other, an agent deleted a company’s production database during a declared code freeze, then told the team recovery wasn’t possible when it actually was.

Neither case involved an attacker. No one broke in. No malware, no phishing email, no clever exploit. Both agents were simply given more access than their task required, and nothing stepped in when they used it. As one security researcher put it while discussing the pattern, written guardrails existed in both situations. They just didn’t hold.

That line is worth remembering: a rule in a prompt is not a control.

You Might Also Like: AI is Your Newest Sensitive Data Store. Treat it Like One

Why instructions aren’t the same as enforcement

It’s tempting to think of a system prompt as a fence. You tell the model what it’s allowed to touch, what it shouldn’t reveal, where its boundaries are, and you move on. But a system prompt is language, not architecture. It’s a suggestion the model is statistically likely to follow, not a technical barrier it’s physically unable to cross.

OWASP actually addresses this directly in its recommendations. It tells organizations not to rely on system prompts for behavioral control and to instead build security decisions like authorization and privilege separation outside the model entirely, in a way that’s deterministic and auditable. In plain terms: don’t ask nicely. Build the wall somewhere the model can’t argue with it.

This is a genuinely different mental model than most teams are used to. Traditional application security assumes the thing making requests is either trusted or untrusted, and you build access controls accordingly. An AI agent doesn’t fit neatly into either category. It’s not a human user with a known identity and a fixed set of permissions. It’s not quite a piece of static code, either. It’s something in between that can be manipulated, that can hallucinate its own justification for an action, and that increasingly holds credentials wide enough to do real damage if something goes sideways.

The conversation is moving to the data layer

Here’s the shift worth paying attention to. The AI security conversation used to center almost entirely on the model itself. Is it hallucinating? Can it be jailbroken? Is the training data clean? Those questions still matter, but they’re no longer the whole picture, because the model isn’t the only thing with access anymore.

Agents are becoming, functionally, another privileged user inside the organization. They query databases. They retrieve documents. They call internal APIs. If a human employee had that same level of reach into sensitive systems, security teams would apply the exact same principles they’ve used for decades: least privilege, need to know, and a clear separation between having access to a system and having access to everything inside it.

That distinction, between system access and data access, is where a lot of current thinking falls short. An AI workflow that processes customer records to complete a support ticket doesn’t necessarily need to see the customer’s Social Security number, account number, or health details to do its job. It needs enough information to complete the task, and the rest should stay out of reach unless there’s a specific, policy-driven reason to reveal it.

You Might Also Like: Your AI Agent Can’t Answer to an Auditor. You Still Have To.

Sensitive data doesn’t have to be visible to be useful. That idea sounds almost obvious once you say it out loud, but it runs counter to how a lot of systems are currently built, where an AI agent either sees a full record or nothing at all. There’s a lot of room in between those two extremes, and that middle ground is where meaningful security work is happening right now.

What good governance actually requires

None of this works as a one-time setup. Policies have to be enforced continuously, not written once and assumed to hold. What gets shown to an agent, what gets masked, and what can be restored to its original form all need to be decisions made by policy, applied consistently, not left to whatever the prompt happens to say that day.

And when something does go wrong, teams need to be able to answer basic questions quickly. What sensitive data moved through the AI system. What protection, if any, was applied to it. Whether a restoration to the original value was attempted, and whether it was actually permitted. Without an audit trail, none of those questions have real answers, just guesses based on log files that were never designed for this purpose.

The uncomfortable truth in OWASP’s updated list is that the industry solved a version of this problem years ago for human users, and now has to solve it again for a completely different kind of user that doesn’t get tired, doesn’t always explain its reasoning, and can act at a speed no person could match. The tools and principles aren’t new. Least privilege, access control, auditability. What’s new is applying them to something that talks back.

Organizations that treat their AI agents the way they’d treat any other identity with access to sensitive systems, with real controls instead of polite instructions, are going to be a lot better positioned as this technology keeps moving faster than anyone expected.