OWASP published the 2026 edition of its LLM Top 10 on August 3, and the headline isn't the list itself — it's how the list got made. For the first time, real-world incident data sat alongside the expert vote that has always driven the ranking. That change moved one entry more than any other: Excessive Agency, the risk that an AI agent can be pushed into using its own tools and permissions to cause harm, climbed from sixth place to third (Help Net Security, ReversingLabs).

If your organization is piloting or running agentic AI — copilots that file tickets, agents that touch production data, assistants wired into internal APIs — this is the part of the 2026 list worth reading closely.

The methodology changed before the ranking did

Every prior edition of the OWASP LLM Top 10 was built entirely from a community vote of practitioners. The 2026 edition kept that vote as the backbone — it still carries 75% of the weight — but added a second input: a corpus of 7,714 real AI-security incidents pulled from public vulnerability databases and an AI-harm database, of which 6,639 carried enough detail to classify and weight at 25% of the final score (Invicti, TechTimes).

OWASP's own reasoning, as reported by outlets that reviewed the release notes, was deliberately conservative: the list is a consensus product, and a single year of incident data shouldn't overturn the collective judgment of the people building and breaking these systems every day (TechTimes). So the vote still leads. But where the two disagreed, the gap became visible for the first time — and that gap is where Excessive Agency and, further down the list, Misinformation both moved.

What "Excessive Agency" actually covers

OWASP breaks Excessive Agency into three root causes, and they're worth naming precisely because each one maps to a different fix (ReversingLabs):

  • Excessive functionality — an agent has access to tools or actions beyond what its actual task requires. A document-summarization tool that can also delete files is the canonical example.
  • Excessive permissions — the tools an agent does need are wired to credentials broader than the task needs. A read-only reporting feature connected through an account that also holds UPDATE and DELETE rights.
  • Excessive autonomy — high-impact or irreversible actions execute without a human checkpoint.

None of these three are new ideas in security. What's new is that they're now showing up in production AI deployments at a scale OWASP's incident data could actually measure. The mechanism that makes this dangerous is combinatorial: prompt injection is still the #1 risk on the list, and an attacker who successfully injects a malicious instruction into an agent's context inherits whatever functionality, permissions, and autonomy that agent already has. Excessive Agency doesn't need to be exploited directly — it's the blast-radius multiplier sitting behind whatever gets an agent to misbehave in the first place (ReversingLabs, Mend.io).

That's a useful way to think about where it sits: prompt injection is the door, Excessive Agency decides what's on the other side of it.

The rest of the list moved too

The top two positions held: Prompt Injection stayed #1, Sensitive Information Disclosure stayed #2 — the one entry where the incident data and the expert vote fully agreed (Help Net Security). Below Excessive Agency, several other categories shifted enough to be worth tracking if you're scoping an AI risk assessment this year:

  • Supply Chain (down from #3 to #4) and Data and Model Poisoning (down from #4 to #5) both dropped, though neither disappeared — poisoning now explicitly absorbs fine-tuning subversion as a subcategory.
  • Unbounded Consumption jumped from #10 to #6, reframed around cost asymmetry and the resource drain of reasoning-heavy models — a risk that reads more like an availability and billing problem than a classic security one, but lands on security teams anyway.
  • Misinformation rose from #9 to #7 — the clearest case of incident data overruling the expert vote, which had ranked it far lower (TechTimes).
  • Improper Output Handling fell the furthest, from #5 to #10, now scoped to cover newer sinks like ANSI/terminal injection and auto-fetching renderers rather than the broader category it used to be.

The pattern across all of these moves is the same one driving Excessive Agency's rise: OWASP is tracking where AI systems are actually being given room to act, not just room to answer.

A chatbot that says something wrong is a support ticket. An agent that acts on something wrong is an incident.

What this means if you're deploying agentic AI now

Excessive Agency at #3 is a specific, actionable signal, not a general warning to "be more careful with AI." OWASP's own guidance, echoed across the coverage of this release, converges on the same starting controls (ReversingLabs, Mend.io):

  1. Inventory what your agents can actually touch — not what they were designed to touch. Shadow tool access accumulates the same way shadow IT does, one integration at a time.
  2. Apply least privilege at the tool level, not just the account level. A read-only reporting agent should be issued read-only credentials, not a service account that happens to also have write access nobody's using yet.
  3. Scope permissions to be short-lived where possible. Just-in-time, task-scoped credentials shrink the window an injected instruction has to work with.
  4. Keep a human checkpoint on irreversible actions — deletions, financial transactions, external communications — even when the agent's normal-case accuracy looks good in testing.
  5. Treat agent permissioning as a governance artifact, not a one-time engineering decision. If nobody can answer "what can this agent do and why" in a sentence, that's the gap Excessive Agency is measuring.

None of this requires abandoning agentic AI. It requires treating an agent's permission set with the same scrutiny you'd apply to a new employee's access request — because functionally, that's closer to what it is.

Where MBCTG fits

If you're deploying LLM-backed tools or agents and haven't mapped what they can actually reach, that's the exact gap our application and API security testing is built to surface — including the tool-permission and injection paths OWASP's 2026 list flags as highest-risk. For organizations building AI governance into an existing risk program, our GRC services help turn "who approved this agent's access" into a documented, auditable answer instead of an assumption, and our Risk Operations Center puts that risk in front of a board in language it can act on.

Not sure what your own AI deployments can actually do once prompted the wrong way? Talk to an MBCTG expert — mapping agent permissions against OWASP's 2026 list is a good place to start.