OWASP Checked Its AI Risk Rankings Against 6,600 Real Incidents And The Surprises Are All Below The Model

The OWASP Top 10 for LLM applications has functioned as a de facto industry standard since its first release. Every AI security product on the market maps back to it. But until this cycle, the rankings came entirely from expert judgment and community debate. For the first time, the working group has a corpus of more than 6,600 reported AI incidents to check that judgment against. The community vote landed close to last year's list. The incident data did not.

That gap is the story, and for anyone building on a database it points somewhere specific. The incidents are not clustering around model behavior. They cluster around the architecture the model is wired into: the tools it can call, the permissions it inherits across a chain of actions, the database roles it runs under, and an identity layer for agents that barely exists yet.

Rock Lambros is Director of AI Security and Governance at Zenity, an AI agent security company, and co-leads the 2026 update of the OWASP Top 10 for LLMs alongside Steve Wilson. He's a core team member of the OWASP Agentic Security Initiative, CEO of the advisory firm RockCyber, and a contributor to the OWASP GenAI Security Project. Across 30 years in security, including CISO roles at MarkWest Energy and Marathon Petroleum and network security leadership at eBay and General Dynamics, he has watched organizations confuse documentation with protection, and he thinks AI is repeating the pattern one layer down from where most teams are looking.

"If you're using MCP tooling and MCP connections, how are you protecting those connections? How are those connections permissioned and privileged? And inside of the database, how are your permissions and roles laid out as well?"

The vote and the data disagree

Lambros built a data model to classify the 6,600 incidents and match them against the ballot the working group had already cast. The mismatch was immediate.

"The community vote aligned pretty close to last year's list," he says. "And the data just does not align so well."

He is careful about why. Not everything gets reported. Prompt injection sets off downstream failures that get filed under other categories, so an incident that started as an injection can surface in the record as sensitive information disclosure or system prompt leakage. The way a breach gets labeled in the field rarely maps onto a standards taxonomy, an industry-wide gap that a new cross-organization effort called MOSAIC, spanning OWASP, NIST, SANS, and the Cloud Security Alliance, is now trying to close with shared terminology on the open-source OpenCRE platform.

Prompt injection is not a bug you patch

The reason the data keeps pointing past the model is that the model's front door cannot be locked. Prompt injection is the most hotly debated entry on the list every year, and Lambros is blunt about where that debate now sits.

"Prompt injection mathematically cannot be prevented," he says. "It's been proven by several papers, most recently one from NIST."

He means the mathematical proof NIST published in June, which extends Kurt Gödel's incompleteness logic to AI guardrails: no finite set of rules is universally robust against adversarial prompts, so there is always another prompt that defeats the set. The paper's own recommendation is to stop treating guardrails as a one-and-done control and move to continuous red teaming and recovery.

The operational consequence is what matters for builders. A system prompt is not a control, it is a suggestion, and the model treats it as one.

"If you're just relying on your system prompt, that's a fallacy," Lambros says. "It's still generative AI, which means it's stochastic and not deterministic in nature, which means it takes that system prompt as a suggestion. And as the context of what you're doing expands, that suggestion gets weaker and weaker."

He calls the failure mode context rot. The longer the conversation or the workflow runs, the less the original instruction holds, which is exactly why the read-only crowd has been arguing that the only guardrail that reliably holds is the one below the model's reasoning, in a layer the model cannot talk its way around.

The enforcement moves down the stack

If the prompt cannot enforce anything, enforcement has to live where the actions land, and the first place they land is the tool layer, where the incident data stops being abstract. When security researchers at Knostic scanned the internet for exposed Model Context Protocol servers, the connective tissue between agents and real systems, they found 1,862 of them, then manually sampled 119.

All 119 answered a tools/list request and enumerated their internal tools without asking who was calling. Not most. Every one. The cause is a default, not carelessness: the MCP specification, especially in early versions, does not require authentication, and reporting on the scan found production systems among the exposed with write access to financial databases and CRM platforms.

For Lambros the fix is layered defense with no single point of trust. "If you're using MCP tooling and MCP connections, how are you protecting those connections? How are those connections permissioned and privileged? And then inside of the database, how are your permissions and roles laid out as well?" he says.

The database is the layer with the most mature primitive. Postgres has shipped row-level security since version 9.5 in January 2016, row-by-row control over which roles can see or modify data, enforced by the engine rather than the application. It has sat in core for a decade, and agents are what finally need it, because of the inheritance problem Lambros describes.

"Let's say an agent is making the third action in a chain of actions, but it doesn't need the permissions for action one and two, but it inherited both of those," he says. "Then it could be way over-permissioned and decide to do things that it shouldn't do."

This is the conclusion practitioners keep reaching as agents get write access to production, that the perimeter has to move down to the database itself. The Postgres ecosystem has started moving its defaults to match. Supabase now splits credentials by privilege, a low-privilege publishable key safe to ship in client code and an elevated secret key for backend use that carries Postgres's BYPASSRLS attribute and skips row-level security entirely.

Its guidance is pointed about inheritance: use a separate secret key per backend component, so a leaked credential forces one rotation rather than a full-blast-radius reset, and its gateway mints a short-lived token per request, the closest thing in production to the scoped, time-bound permission Lambros says agents need.

The bound comes down to whether the autonomy is warranted at all. "If the agent doesn't need to have autonomy, then you don't need an agent. You need a bunch of if-then-else statements," he says.

Identity is the next wall

The layer underneath all of it does not exist yet. Service accounts and traditional non-human identity were built for static workloads, not for an agent that has to prove who it is, who it is acting for, and what it is scoped to do in a given window.

"We need an entirely new identity model for agents," Lambros says. "There are legitimately over a hundred draft proposals in IETF right now for agent identity standards."

The volume is real and the drafts are concrete. One OAuth extension for on-behalf-of user authorization adds a requested_actor parameter to name the specific agent and an actor_token to authenticate it, so the access token records the full delegation chain from human to agent to client. A Transaction Tokens for Agents draft carries an actor context and a principal context deep into a service graph, keeping the agent and the human behind it legible across hops.

Others extend the WIMSE workload-identity architecture to agents outright. Lambros reads the count as a signal in both directions: serious attention, and a lot of noise before anything settles. Underneath it sits the oldest problem. "It always boils down to data," he says. "Understanding where your data lives and whether it's going into a free model that's training on it, that doesn't change with AI."

What to ship before you ship

For a solo developer putting an LLM feature on a database without a security org behind them, Lambros narrows it to one move: use AI in the defense, not just as the thing you defend against. AI-generated code "still generates notoriously non-secure code unless you know how to prompt it and put the harness around it," he says, so he wants LLM-based scanning paired with deterministic static analysis in the pipeline before code reaches the repo. "Until we solve that gap, you're always going to need a combination of both," he says.

That is the throughline from a spreadsheet of 6,600 incidents to a developer's pull request. The defense-in-depth discipline that has governed production software for decades did not get rescinded when the model showed up. It inherited a new attack surface, the model's own reading of its instructions, and a new floor where the real controls have to live. Row-level security, scoped keys, short-lived tokens, and an identity that names the actor are the database fundamentals, finally being asked to hold a line the prompt never could.