Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free Trial
The Open Worldwide Application Security Project’s newest OWASP Top 10 for LLM Applications includes a change that puts a spotlight on the rise of AI risk.
While prompt injection and the disclosure of sensitive information still hold the top two spots, excessive agency jumped from sixth place in 2025 to third in 2026 (pushing supply chain and data model poisoning risks down to the fourth and fifth slots).
Now part of OWASP’s GenAI Security Project and created by hundreds of AI security experts, the OWASP Top 10 for LLM Applications 2026, provides updated rankings, expanded threat coverage, and new research based on real-world AI security incidents, all organized with the practitioner in mind.
“The guide provides practical explanations, attack scenarios, and actionable mitigations for developers, architects, security teams, and CISOs, while mapping risks to leading industry frameworks including NIST, MITRE ATLAS, CWE, and the OWASP Top 10 for Agentic Applications.”
—OWASP GenAI Security Project
Here are key takeaways from the OWASP Top 10 for LLM Applications 2026 — and why it's time to think beyond security controls.
[ Join webinar: Autonomy, Not Autopilot: Get Real About Agentic SOC ]
Jason Soroko, a senior fellow at Sectigo, said prompt injection remains the top risk because the flaw is fundamentally architectural.
“[With prompt injection], instructions and data share one channel, the context window, and no equivalent of the parameterized query exists to separate them, so every mitigation lowers probability without reaching zero.”
—Jason Soroko
Pete Pickerill, co-founder of Liquibase, said no one has solved the problem. He noted that attackers can now conceal instructions inside images, audio, and documents, adding that every tool that an AI system connects to represents another potential entry point. What’s changed, he said, is the level of risk: Where a manipulated chatbot can produce an embarrassing response, a manipulated agent can take genuinely harmful action.
Jeremy London, director of engineering, AI and threat analytics at Keeper Security, said excessive agency’s rise reflects how organizations are deploying AI. When the list was first created, in 2024, most LLM applications were simple chat interfaces or single-step tools. By 2026, agents had become the norm — systems with persistent memory, tool access, file and API permissions, and the ability to carry out multistep tasks with varying degrees of autonomy, he said.
“The model is not just returning a response. It is taking action, which presents a qualitatively different attack surface.”
—Jeremy London
Larry Maccherone, founder and CTO of Lumenize, is skeptical about excessive agency’s ranking, arguing that a self-repairing system can only exist if the AI is given enough agency to fix itself — a form of recursive self-improvement, with humans providing high-level direction while the machine handles the actual repairs. Clipping an AI system’s agency in the name of safety will limit its ability to find and close its own security gaps, he said, leaving organizations with something less capable and less secure.
“The cure for excessive agency is more agency — pointed at the right thing.”
—Larry Maccherone
New to the 2026 list is the addition of incident data in the ranking process. In the 2026 Top 10 document, the project leaders explained that this and every previous version of the list has been built on judgment, with hundreds of practitioners weighing in on what matters most.
This year, however, the project tested that vote against a record of what has actually gone wrong. The project pulled together records on 7,714 incidents from public vulnerability databases and an AI-harm database, then built classifiers that read them and identified 6,639 that carried enough detail to sort, said Steve Wilson, founder and co-chair of the OWASP GenAI Security Project.
“This was the first time in three years of doing this that we had enough data for it to really weigh into the decision making.”
—Steve Wilson
The first time the list was created, he noted, the risks had been purely theoretical.
Still, the vote was given more weighting — three-quarters of the total — the project leaders said, because the list is a consensus product and a single noisy year of incident data could erroneously override the collective judgment of practitioners. The quarter-weight given to incident data, they explained, is enough to shift an entry by a tier when there’s a wide gap between perception and evidence but not enough to let imperfect data rewrite the list unilaterally — and that balance determines every final ranking in the Top 10.
Differences between belief and evidence can occur, said Advait Patel, a senior cloud security and site reliability engineer and creator of OWASP DockSec, because the two are measuring different things. The community vote reflects what practitioners are worried about and focused on, he said, while the incident data shows what has caused real-world harm. The gap between the two, he said, is where things get interesting.
Prompt injection, for instance, generates relatively few clean public incidents — not because the risk has disappeared, but because so many people are actively working to defend against it, making the low incident count a sign that those defenses are working. Misinformation runs in the opposite direction, he added; teams didn’t rank it highly, yet it appears frequently in the incident record, because a confidently wrong AI answer can now feed directly into downstream tools and code rather than simply appearing in a chat window.
Two categories that had sat at the bottom of the 2025 list, misinformation and unbounded consumption, moved up to the sixth and seventh spots in 2026.
Eilon Cohen, head of security research at Pillar Security, explained unbounded consumption by saying that a single agent request can consume far more than just model tokens. A request might trigger an extended reasoning process, repeated calls back to the model, queries to external APIs, code execution, or new cloud workloads — and a failed step might be retried repeatedly.
“One user request can turn into dozens or hundreds of operations behind the scenes. That creates both denial-of-service and denial-of-wallet risks.”
—Eilon Cohen
Whether the problem is caused by an attacker or simply involves an agent caught in a loop, he said, the result can be an exhausted budget, drained SaaS quotas, occupied cloud infrastructure, and degraded service for everyone else. Rate-limiting the chat endpoint alone is no longer sufficient, he cautioned; organizations need per-user and per-session budgets, limits on agent steps and tool calls, timeouts, concurrency controls, and circuit breakers that can halt abnormal consumption before it spreads to connected systems.
Meanwhile, improper output handling fell from fifth place in 2025 to the bottom of the list in 2026, and system prompt leakage — renamed and rescoped as hidden context exposure — and vector and embedding weaknesses each slipped a notch, from seventh and eighth, respectively, in 2025 to eighth and ninth in 2026.
DockSec creator Patel cautioned against reading the drop of embedding weaknesses as a sign the risk itself had diminished. In fact, he said, the category’s scope expanded this year to include things such as terminal escape sequences and renderers that automatically fetch links.
“It dropped because everything above it got more urgent, not because output handling got safe. It is a relative move on a crowded list.”
—Advait Patel
The project leaders’ core recommendation is to stop trying to build a model that is immune to manipulation and instead improve the surrounding system so that when the model does get fooled — which it will — nothing critical breaks. That posture, they wrote, runs through all 10 entries on the list, and for the first time, the project can back it with evidence rather than asking practitioners to take it on faith.
The OWASP GenAI Security Project’s Wilson said that when the list debuted three years ago, the community had only a general sense of how the models worked, and at the time, prompt injection felt comparable to SQL injection — something that could largely be avoided with sufficient care. That assumption, he said, has proved false; the common wisdom now is that prompt injection is as unavoidable as death and taxes. While frontier model providers continue to improve their models’ resistance to manipulation, he said, attackers are advancing their prompt-injection techniques even faster than the models are learning to detect them.
Dave Hayes, vice president of product at FusionAuth, said the recommendation about the surrounding system is sound because it shifts the problem to a layer that security teams can control. There’s no guaranteeing a model won’t be fooled, he said, because accepting untrusted input is inherent to what it does. But what that model is permitted to do once it’s fooled is a permissions question, and permissions can be made deterministic even when the model itself is probabilistic.
That’s why the real work should happen upstream of the model, he said, ensuring that whatever credential it holds can reach only what it strictly needs, will expire quickly, and can be revoked.
“If a fooled agent can only reach one record instead of the whole database, you’ve turned a breach into a log entry.”
—Dave Hayes
“Every mitigation on the list is about limiting damage after it succeeds,” Liquibase’s Pickerill added. That’s a major shift in mindset, he said, moving from asking how to prevent the model from being tricked to asking what the agent is allowed to change and who verifies its work. For any agent touching production systems, verification needs to happen outside the model itself, he said.
Lumenize’s Maccherone said he agrees with the project leaders’ guidance in principle but worries that the industry will misread it. Most security professionals, upon hearing “Contain the damage,” will just reach for another control: another gate, another approval step, another policy engine standing in front of the agent asking permission. But you cannot inspect your way to a secure agent, he said.
Traditional software behavior is a fixed artifact that can be reviewed, scanned, and signed off on, he explained. An agent’s behavior, by contrast, is generated fresh at runtime with every execution and is never quite identical twice, and you can’t pre-approve behavior that doesn’t yet exist.
The real answer, Macherrone said, is getting better feedback rather than improving control: sensing failures quickly, pinpointing their cause precisely, and letting the system adapt so the same failure doesn’t recur. Security for agents will end up looking a lot more like site reliability engineering than traditional application security. His advice: Stop building guardrails and build a nervous system instead.
The real answer, Macherrone said, is getting better feedback rather than improving control: sensing failures quickly, pinpointing their cause precisely, and letting the system adapt so the same failure doesn’t recur.
Hayes said the OWASP Top 10 for LLM Applications 2026 reads like something compiled for a field that is maturing. Last year’s edition, he said, still held out some hope that a model could be built that would resist being fooled. This year’s update opens by assuming all models will be fooled and so advises teams to build systems where that doesn’t matter much.
That containment mindset is fundamentally an identity and authorization question, he said — asking, “What is this thing, and what is it allowed to do?” Hayes said that if he were a developer working from this list, he’d spend less budget hardening the model’s inputs and more on limiting what the model and its agents can actually reach when they get things wrong — because they will get things wrong, and the list is now built around that reality.
The post-mortems of two compromises by rogue AI agents show that security teams need to focus on guardrails, not the AI model.
Research into an Active Directory takeover with a single AI prompt highlights why organizations need to focus on agentic SOCs.
Traditional SBOMs, signing, and provenance all have blind spots, making them no longer capable of assuring software security.
