OWASP LLM Top 10 for 2026: What the Data Reveals

Here is the tension at the heart of the 2026 OWASP Top 10 for LLM Applications: the people who work in AI security every day and the databases that record what actually goes wrong don't agree on what's most dangerous. That gap is, arguably, more instructive than the rankings themselves.

The IBM Security Intelligence panel — Seth Glascow, cyber range executive adviser, and Ryan Anuts, North America leader of X-Force Incident Response — spent a recent episode working through the new list, and the conversation surfaced something worth sitting with. OWASP, for the first time, combined a practitioner community vote with a corpus of real-world incident data. The result is a list that reflects both what experts fear and what attackers are actually doing — and those two things do not perfectly overlap.

The Prompt Injection Paradox

Prompt injection holds the top spot. No surprise there — it's been number one before, and the LLM vulnerability landscape hasn't changed enough to dislodge it. But here's what's interesting: when OWASP looked at actual incident databases, prompt injection barely registered. Wasn't even in the top ten.

The panel's explanation for that gap is worth considering carefully. Glascow called it a "defensive bias" — the security community has poured so much energy into building prompt injection defenses that the attacks either don't land or don't make it to incident databases when they do. The attack surface is visible and well-understood, so it gets defended. That's not a flaw in the list; it's arguably evidence that collective attention to a known threat works.

The flip side is where it gets uncomfortable. Practitioners ranked misinformation low. Incident data suggests they shouldn't.

"Misinformation on the other hand is a little bit harder to detect," Glascow noted. "It's a little bit harder to prevent against. You have to kind of prevent for model drift. This could happen over a much longer period of time."

Anuts added a layer that I found particularly sharp: users are now conditioned to expect AI to be occasionally wrong. That tolerance — that ambient expectation of hallucination — creates a blind spot. If you're already discounting a percentage of AI output as noise, you're less likely to notice when that noise has been deliberately introduced. Slow drift through misinformation becomes harder to catch precisely because we've already accommodated imprecision as a feature of the technology.

Agents Are the New Privileged Accounts

Excessive agency jumped to third on the list, up three spots. The panel treated this as overdue recognition rather than a new discovery.

Glascow framed it cleanly: AI agents are functionally identical to privileged accounts. They authenticate to systems, access data, and take automated actions at scale. The access is the point — an agent that can't do things isn't useful. But that same access profile is exactly what makes a compromised privileged account catastrophic in traditional environments. Security teams have decades of tooling and practice around privileged account management. Almost none of that has been applied to agents yet.

"The question isn't can I manipulate what the AI says anymore," Anuts said. "The question is becoming can I manipulate what the AI actually does."

Prompt injection as an entry point and excessive agency as the blast radius: that's the threat model the panel kept returning to. Getting into an AI system is one problem. What happens after that — how far the agent can reach, how fast it can act, how little visibility defenders have — is the larger problem.

What Black Hat Demonstrated

Anuts attended Black Hat 2026, and one briefing in particular gave the abstract threat a concrete shape. Researchers demonstrated an attack chain against agentic browsers: a malicious calendar invite manipulating an already-authenticated agent, leading to credential theft, data exfiltration, and code execution.

The concept the researchers named "intent collusion" is what makes this distinct from a classic prompt injection. You're not tricking the agent into doing something the user didn't ask for. You're persuading the agent that what the attacker wants is actually the most effective path to what the user wants. The agent believes it's serving its user. It isn't.

"We are actually operationalizing social engineering in the machine world," Anuts said.

What made the briefing notable — and what Anuts flagged as equally important to the exploit itself — was which controls worked. Not AI-native defenses. Least privilege. Segmentation. Hard boundaries. The boring fundamentals that don't require understanding how an LLM reasons. The controls that worked were the ones the AI never got a deciding vote in.

Glascow added the data that grounds this: according to the State of AI Agent Security Report 2026 from Gravitee, no single security control had been deployed across more than 31% of organizations surveyed. IBM's 2026 Cost of a Data Breach report found that 92% of organizations that experienced an AI-related breach had not implemented proper access controls on their AI systems. Read that percentage again. The gap between deploying agents and securing them is not a gap that's closing fast.

The SBOM Problem Is the Same Problem

The panel's discussion of SBOM guidance covered different technical ground but arrived at an identical structural issue. Cataloging risk and acting on risk are not the same thing. The panel discussed new CISA SBOM guidance — framing it as something the panel characterized as a shift from depth requirements to coverage requirements, meaning organizations are now expected to document not just direct dependencies but transitive ones: the dependencies of dependencies, several layers down.

That expanded scope is objectively useful. A vulnerable component buried four layers deep in your software supply chain is still a vulnerable component. But Glascow made the point that without operationalization, an SBOM is overhead — a compliance artifact that requires maintenance and generates no security value unless someone connects it to something.

Anuts put the practical version of this bluntly: when a critical vulnerability drops on a Friday night (and they always drop on a Friday), nobody should be searching a SharePoint folder for a spreadsheet. An SBOM that isn't wired into your vulnerability management program, your threat intelligence feed, and your incident response workflow is a document, not a capability.

The prescription the panel landed on covers both ends of the software lifecycle. At the response end: connect SBOMs to exposure management so that when a CVE drops, you can immediately answer whether you're affected, where, and how exposed. At the development end: use SBOM data as a risk signal when choosing libraries and frameworks, not just as an artifact generated after the fact.

The Checklist Problem

What runs through all three threads — the OWASP list, the SBOM guidance, the Black Hat research — is a consistent failure mode: treating a framework as an endpoint rather than a starting point.

The OWASP list is a taxonomy of known risks. It is not a security program. Anuts put the tabletop exercise framing well: pick a scenario from the list and work through whether your organization could detect it, contain it, and reconstruct what the agent actually did. Those three questions will tell you more about your real security posture than any compliance checkbox.

OWASP's own framing of the list's philosophy, as reported by Help Net Security, captures where this is all heading: the model will be fooled. The question is whether you've built the surrounding system so that when it is, nothing important breaks.

That's not a counsel of despair. It's a more honest operating model than trying to build something that cannot be compromised. Every useful system that touches real users has attack surface. The organizations that come through breaches better aren't the ones that prevented every incident — they're the ones that had practiced responding before it mattered.

The 2026 OWASP list, the gap between practitioner intuition and incident data, the agent identity crisis, the calendar invite that becomes a code execution chain — none of this is a reason to stop deploying AI. It is, however, a fairly clear argument for treating your agents like the privileged accounts they are, before someone else does it for you.