OWASP released the LLM Top 10 2026 on August 6, 2026, at Black Hat USA. This third edition of the list is the most significant methodological overhaul since the project launched in 2023. For every enterprise security team deploying AI systems, the question is not whether to update your control baseline, but which changes to prioritize first. This guide covers the complete 2025-to-2026 delta, the agentic and multimodal expansion, the nine-framework cross-walk, and a 90-day response plan grounded in the incident data that shaped the new rankings.
Key Takeaways
- OWASP analyzed 7,714 real-world AI security incidents to produce the 2026 rankings, blending incident data (25% weight) with practitioner vote (75%)
- Excessive Agency climbed from number 6 to number 3, with both vote and incident data agreeing that agentic deployments are where real production damage lands
- Unbounded Consumption rose from number 10 to number 6, reflecting that AI inference costs are now a material business risk, not just an availability concern
- Improper Output Handling fell from number 5 to number 10, not because the risk is resolved, but because output sanitization has become standard application security practice
- The 2026 list explicitly adds multimodal inputs (images, PDFs, audio), MCP servers, and memory persistence injection to the scope of multiple entries
- OWASP formally separates "LLM as component" (this list) from "LLM as actor" (OWASP Agentic Top 10); agentic deployments require both lists simultaneously
- The vote and incident data diverged most sharply on Misinformation: incident records placed it far higher than practitioners voted, and OWASP notes the 2026 placement is "probably still conservative"
How OWASP LLM Top 10 2026 Was Built: 7,714 Incidents and a Methodology Overhaul
Every prior edition of the OWASP LLM Top 10 relied primarily on practitioner community votes to establish rankings. For the 2026 edition, the working group added a second signal: real incident data drawn from AI-harm repositories and public vulnerability databases.
The dataset contained 7,714 real-world AI security incidents. Of these, 6,639 had sufficient detail for classification and weighting. The final ranking uses a 75/25 split: 75% practitioner community vote and 25% incident data.
This matters for three reasons.
First, the vote represents forward-looking expert judgment about what is likely to cause harm. The incident record represents what has already caused harm. Blending both produces rankings that reflect practitioner experience and empirical frequency together.
Second, where vote and data diverged, OWASP flagged the disagreement explicitly. These divergences are the most informative part of the 2026 release. They reveal where security practitioner intuition and real-world attack patterns have not yet aligned.
Third, the methodology sets a precedent. Future editions will continue expanding and refining the incident dataset, which means each subsequent list will be more empirically grounded. Security teams should treat OWASP LLM Top 10 rankings as increasingly evidence-backed rather than expert-opinion-only.
The 2026 release also formalizes a scope boundary that was implicit in prior editions. The OWASP GenAI LLM Top 10 covers "LLM as component": vulnerabilities in applications where an LLM is one processing layer in a larger system. The OWASP Top 10 for Agentic Applications (first published December 2025) covers "LLM as actor": vulnerabilities specific to systems where the LLM drives autonomous multi-step plans. When your deployment uses agents with tool access, persistent memory, and execution rights, both lists apply simultaneously.
If you are updating your AI security posture from the 2025 version of this list, see our OWASP LLM Top 10 guide for the prior baseline before reading the delta analysis below.
2025 vs. 2026: The Complete Entry-by-Entry Comparison
| 2026 Rank | Entry Name | 2025 Rank | Change | |-----------|-----------|-----------|--------| | LLM01 | Prompt Injection | 1 | Held; scope expanded to multimodal, memory persistence, agentic blast radius | | LLM02 | Sensitive Information Disclosure | 2 | Held; strongest vote-data agreement of any entry | | LLM03 | Excessive Agency | 6 | Up 3; biggest upward move; vote and data both agreed | | LLM04 | Supply Chain Vulnerabilities | 3 | Down 1; MCP tool servers added to scope | | LLM05 | Data and Model Poisoning | 4 | Down 1; fine-tuning subversion explicitly absorbed | | LLM06 | Unbounded Consumption | 10 | Up 4; second-biggest climb; cost exhaustion validated as operational risk | | LLM07 | Misinformation | 9 | Up 2; biggest vote-data divergence in the list | | LLM08 | Hidden Context Exposure | 7 | Down 1; renamed from System Prompt Leakage with broader scope | | LLM09 | Vector and Embedding Weaknesses | 8 | Down 1; multi-tenant leakage added to scope | | LLM10 | Improper Output Handling | 5 | Down 5; biggest fall in list history |
The widest single-edition position swings in this list's history: Improper Output Handling fell five places, Unbounded Consumption rose four. These are not cosmetic adjustments. They reflect a fundamental rebalancing of the risk landscape as AI deployments have matured from single-turn API integrations into full agentic systems with persistent state, tool access, and autonomous decision authority.
The Four Biggest Position Shifts: What Each Means for Your Security Program
Excessive Agency Rises to Number 3
Excessive Agency occurs when an LLM is granted more functionality, permissions, or autonomy than its task requires. The 2026 framing identifies three root causes: excessive functionality (access to tools the task does not need), excessive permissions (tools with read-write access when read-only would suffice), and excessive autonomy (acting without human approval on high-stakes actions).
This is the first entry where vote and incident data fully agreed on the ranking. That agreement is significant. In production agentic deployments, Excessive Agency is where real financial and operational damage is landing. An agent with standing write access to a CRM, email system, or cloud resource can cause material harm if its instructions are manipulated through any of the injection vectors above it in the list.
In practice, we see this pattern frequently: teams scope an agent's tool access broadly during development to speed iteration, then ship to production without restricting permissions to what the production task actually requires. The agent can read and write to resources that a successful injection could weaponize, even though the intended task only required read access.
Controls: Principle of least privilege for all tool grants. Just-in-time ephemeral tokens rather than standing permissions. Human-in-the-loop gates for any action that modifies external state. Authorization enforcement outside the model, in deterministic systems the model cannot override.
Unbounded Consumption Rises to Number 6
This entry was called "Model Denial of Service" in the 2023 list. The 2025 list renamed it Unbounded Consumption to capture the full scope: unrestricted inference enabling service degradation, runaway API costs creating economic harm, and repeated queries enabling model theft through behavioral reconstruction.
The rise from number 10 to number 6 reflects one practical reality: AI inference costs are now a material operational line item at enterprise scale. A misconfigured rate limit on an LLM endpoint is not just an availability risk. It is a budget risk. We have seen production deployments accumulate five-figure API charges over a weekend due to a missing token limit on a single endpoint. Token-flood attacks and recursive context expansion compound this. An attacker who can cause unbounded consumption does not need to breach your systems to cause harm.
Controls: Input length restrictions, per-user rate limits, resource quotas with hard stops, cost alerting at defined thresholds, automated circuit breakers that disable endpoints at the budget ceiling, and query pattern monitoring for recursive or unusually long context patterns.
Misinformation Rises to Number 7 Despite Expert Skepticism
Practitioners voted Misinformation near the bottom of the list, historically treating it as a safety concern rather than a security vulnerability. The incident record placed it near the top. OWASP's own framing on the 2026 list: "The incident data says Misinformation is probably still placed conservatively."
The divergence reflects a lag in security practitioner mental models. Most security teams think of misinformation as a user experience issue: the model gives a wrong answer, the user is misled. The incident data tells a different story. When an LLM produces a confidently incorrect answer in an agentic pipeline, that answer can trigger automated workflows, business decisions, or API calls before any human reviews it.
In one documented pattern from the 2026 incident dataset, a model in a financial processing pipeline produced a plausible but incorrect regulatory classification. The output propagated through an automated decision system and was only caught during a downstream audit, not at the point of model output. The error had been in the production pipeline for eleven days.
Controls: Retrieval-augmented grounding tied to verified source documents, citation verification before automated workflow triggers, human review gates for high-stakes decisions, confidence scoring surfaced to downstream systems before they act on model output.
Improper Output Handling Falls to Number 10
The biggest fall in this list's history does not mean Improper Output Handling is solved. Output passed unsanitized to terminal emulators, browsers, databases, or shell interpreters remains dangerous. The scope actually grew in 2026: the entry now covers terminal and IDE sinks that render ANSI escape sequences (which can trigger code execution) and client renderers that auto-fetch external resources referenced in model output, creating an exfiltration channel. CVE-2023-32786, a documented LangChain server-side request forgery via improper output handling, illustrates the real impact of this class.
The fall reflects that standard application security now treats output sanitization as baseline behavior. Teams deploying LLMs in 2026 are more likely to have input-output pipelines that sanitize content than teams were in 2023. The gap is narrowing, but it is not closed. The entries that rose were the ones outpacing defenses; Improper Output Handling fell because defenses are catching up faster than attackers are innovating in this class.
Controls: Treat all model output as untrusted data regardless of source model. Sanitize before any downstream sink. Validate against expected schema or format. Sandbox rendering environments. Block auto-fetch of external resources from model output.
Agentic and Multimodal Expansion: The New Attack Surface
The 2026 list addresses a significant expansion in what counts as a valid LLM deployment, and what counts as a valid attack vector against one.
Cross-Modal Injection Under LLM01
The 2026 Prompt Injection entry explicitly covers adversarial instructions hidden in images, audio files, PDFs, and video. A malicious instruction embedded in a JPEG that an LLM-powered document processor reads is treated as an injection vector equivalent to a text-based attack. This matters because most existing defenses, including text classifiers and keyword filters, do not operate on image or audio content at all. Cross-modal injection is described in the 2026 document as "increasingly viable and mostly undefended."
A common pattern we see in enterprise deployments: teams add LLM document analysis to a workflow, apply their existing text-based injection filters to the user-provided query, but do not apply any filtering to the document content the model reads. The injection arrives in the document, not the query, and bypasses every defense the team has built.
Memory Persistence Injection Under LLM01
When an agent writes adversarial instructions to persistent memory or a RAG corpus, the damage does not expire after a single session. Research on long-term memory poisoning in persistent LLM agent systems records injection success rates approaching 98% in tested configurations. Unlike ephemeral context injection, memory persistence injection compounds: every future interaction that reads from the poisoned store inherits the malicious instruction set.
This is a distinct attack class from standard prompt injection, requiring distinct controls. Ephemeral injection affects one response. Memory injection affects every future response that draws on that memory. The attacker's work scales across sessions without additional effort.
MCP Servers Under LLM04
Every new Model Context Protocol server connection adds a surface the model reads without a trust boundary enforced at the protocol layer. Analysis of public MCP servers has found that 5.5% carry tool-poisoning flaws, 43% carry command-injection vulnerabilities, and 36.7% of over 7,000 MCP servers analyzed are potentially vulnerable to server-side request forgery.
The MCPTox benchmark, which tested 45 live MCP servers and 353 authentic tools, recorded attack success rates above 60%, with the highest at 72%. The March 2026 LiteLLM compromise is the highest-profile supply chain example: a single poisoned PyPI package exposed more than 40,000 AI pipelines in 40 minutes.
For teams deploying MCP-connected agents, see our MCP security enterprise guide for detailed hardening steps. MCP supply chain risk now appears explicitly in OWASP LLM04, and the control requirements are distinct from traditional software supply chain controls.
Agentic Blast Radius Across Multiple Entries
The 2026 framing introduces "agentic blast radius" as a concept that touches LLM01, LLM03, LLM04, and LLM06. In a multi-step agentic plan, a single injection at step one can propagate through all subsequent steps. A single supply chain compromise in a tool used by an agent can affect every task that agent executes. A single excessive permission can be exploited at any point in a plan. The practical implication: security controls designed for single-turn LLM API calls are insufficient for agentic systems where one failure compounds across an entire plan.
Teams building or deploying agentic systems should treat the OWASP LLM Top 10 and the OWASP Top 10 for Agentic Applications as complementary documents. The LLM list covers the model layer; the Agentic list covers the orchestration and autonomy layer. You need both.
To evaluate your exposure across these agentic attack vectors, you can run a Securetom scan to map which OWASP 2026 entries apply to your current AI deployment posture.
The 9-Framework Cross-Walk: Which Team Uses Which Framework
One of the most useful additions in the 2026 document is Appendix A, which maps every LLM Top 10 entry to nine security and AI governance frameworks. Understanding which framework your team already uses determines which mapping is most immediately actionable.
For compliance and governance teams: NIST AI 600-1 is the primary mapping. NIST AI 600-1 is NIST's Generative AI Profile, covering risk management for GenAI systems specifically, distinct from the broader NIST AI RMF. If your organization is working toward NIST AI RMF alignment, both the AI 600-1 and the broader RMF mappings are relevant. EU AI Act obligations also flow through NIST AI 600-1 for organizations using it as their primary risk framework.
For SOC and detection teams: MITRE ATLAS is the primary mapping. ATLAS catalogs real-world adversary tactics and techniques against AI systems, using the same structure as MITRE ATT&CK. If your SOC already uses ATT&CK for threat detection rules and incident triage, the ATLAS mapping lets you extend that logic to AI-specific threats without rebuilding your detection playbooks from scratch.
For AppSec and development teams: OWASP CWE mappings and the OWASP GenAI Data Security guidance (DSGAI) are most directly applicable. These translate LLM Top 10 entries into the vulnerability classification language AppSec teams already use in code review, SAST tooling, and security testing workflows.
For cloud security architects: The CSA AI Controls Matrix (AICM) maps LLM Top 10 entries to cloud security controls. If your organization uses the CSA Cloud Controls Matrix for cloud configuration baselines, the AICM extends that coverage to AI workloads without requiring a separate governance framework.
For risk and vendor management teams: The OWASP AI Vulnerability Scoring System (AIVSS) provides a scoring methodology for AI-specific vulnerability severity. This enables consistent severity rating when evaluating third-party AI components, which is particularly relevant for Supply Chain (LLM04) and Vector and Embedding Weaknesses (LLM09) findings.
The practical approach for most enterprise security teams: do not try to implement all nine frameworks simultaneously. Pick the one your team already uses, apply its LLM Top 10 mappings first, and treat the others as cross-reference material for audit cycles or vendor discussions. The BeyondScale AI security assessment maps findings against NIST AI 600-1 and MITRE ATLAS by default, with cross-reference to the other seven frameworks on request.
What the Vote-vs-Data Divergence Reveals About Enterprise Risk
The places where practitioner votes and incident records diverged are more informative than the rankings themselves. They show where security intuition has not yet caught up with attacker behavior.
Misinformation (vote placed it low, data placed it high): Practitioners categorize misinformation as a safety problem, not a security problem. Incident records show that automated systems acting on wrong model output create measurable business harm. The gap will close as more agentic deployments reach production and security teams begin seeing the downstream effects of incorrect model output in automated pipelines.
Prompt Injection staying at number 1 despite incident data ranking it lower: The incident data reflects a world where teams have invested in injection defenses, reducing the frequency of successful attacks that make it into public databases. Expert vote preserved the number 1 position based on forward-looking risk: most defenses are still insufficient for cross-modal and memory persistence vectors now in scope. The vote is correct on this one.
Excessive Agency at number 3 by full agreement: This is the rare case where vote and data aligned completely. Both signals say the same thing: when AI agents have more authority than their task requires, real damage follows. This should be a high-priority control for any team with production agentic deployments.
The OWASP framing that defines the 2026 edition: "The model will be fooled. The question is what happens when it is." This shifts the security design question from "how do I prevent injection" to "what can an attacker accomplish if injection succeeds." Least-privilege tool grants, human-in-the-loop gates, and authorization enforcement outside the model are the controls that answer the second question.
Your 90-Day OWASP LLM 2026 Response Plan
Not all ten entries require the same urgency. The entries with the most significant position changes, the strongest empirical backing, and the highest blast radius in agentic deployments should move first.
Days 1 to 30: Immediate Controls for Highest-Impact Entries
LLM01: Prompt Injection audit
Enumerate every external input your LLM receives: user messages, retrieved documents, tool outputs, API responses, emails, PDFs, images. Each is a potential injection vector. For agentic systems, map how a successful injection at each input source could propagate through the downstream plan. Prioritize inputs that could reach persistent memory or trigger high-authority tool calls.
Specific action: treat all retrieved content, including RAG documents, tool call responses, and web content, as untrusted input. Do not rely on the model to distinguish adversarial from benign content. Apply a secondary, isolated evaluation layer for inputs from external sources.
LLM03: Excessive Agency inventory
List every tool your AI agents can call. For each tool, answer three questions: does the current task require this tool? Does the tool have write access when read-only would suffice? Does the tool execute without human approval? Revoke any permission that fails this test. Implement just-in-time ephemeral tokens for tools that must retain access.
For any tool that can modify external state (write to databases, send emails, make API calls, execute code), verify that authorization is enforced in a deterministic external system, not by the model itself. A model that can self-authorize an action provides no protection when that model is under adversarial instruction.
LLM04: Supply chain audit of MCP servers
If your deployment uses Model Context Protocol servers, audit each one for tool-poisoning configurations and outbound request controls. Verify that no MCP server has unbounded access to internal network ranges or cloud metadata endpoints (169.254.169.254 for AWS, 169.254.169.254 for Azure). Pin MCP server versions and hash-verify configurations on each deployment. Treat each MCP server as an untrusted external system until it passes an explicit audit.
For broader MCP server hardening, refer to our MCP security guide for configuration-level controls.
LLM06: Cost and consumption controls
Set token limits per request, per user, and per session. Configure cost alerting at 50%, 75%, and 100% of your budget thresholds. Add circuit breakers that disable endpoints automatically when the 100% threshold is reached. Monitor for recursive context expansion patterns and unusually long input sequences, which are the primary indicators of a token-flood attack.
Days 31 to 60: Defense Depth for Mid-Tier Entries
LLM02: Sensitive information audit
Review every system prompt and tool definition for embedded credentials, API keys, or sensitive configuration data. These belong in a secrets manager with runtime injection, not in prompt text. Add output guardrails that scan model responses for PII and credential patterns before they reach end users or downstream systems.
LLM05: Data and model poisoning controls
For RAG pipelines, treat every ingested document as untrusted input requiring content inspection before indexing. Add write-access controls to knowledge bases: write operations should require the same authorization level as privileged system operations. Implement provenance tracking for indexed content so you can identify and remove poisoned entries when discovered.
For fine-tuned model deployments, add a pre-deployment red-team step specifically designed to probe for backdoor triggers. Datasets used for fine-tuning should be treated as an attack surface, not a trusted input.
LLM08: Hidden Context Exposure review
The rename from "System Prompt Leakage" signals scope expansion. Review not just your system prompt but every element of hidden context: business logic, tool schemas, retrieval pipeline details, internal API names, embedded configuration values. Each element that leaks provides attackers with information that makes injection attempts more targeted and Excessive Agency exploits more specific.
A practical test: use a prompt injection probe to ask your deployed application to describe its tool list, permissions, and configuration. If the model responds with accurate internal details, you have an LLM08 exposure.
Days 61 to 90: Systematic Coverage and Monitoring
LLM07: Misinformation controls for automated workflows
If your deployment uses model output to trigger automated business decisions, add a confidence or grounding check before the trigger point. A citation verification step (does the model's assertion trace back to a retrieved source document?) significantly reduces ungrounded output from triggering automated actions. This does not require a separate AI model; a deterministic lookup against your retrieval corpus is sufficient for most workflows.
LLM09: Vector and embedding security
Audit tenant isolation in your vector database. In multi-tenant RAG deployments, a misconfigured similarity search can return results from adjacent tenant stores. Enforce isolation at the protocol layer, not only the application layer. Log all retrieval operations and alert on anomalous access patterns across tenant boundaries. Treat cross-tenant retrieval anomalies with the same urgency as cross-tenant data access in a traditional database.
LLM10: Output handling baseline verification
Even though Improper Output Handling fell to number 10, verify that your output pipeline sanitizes content before passing it to any downstream sink: terminal, browser, database, or shell. This is particularly relevant for deployments that use model-generated code or commands. Run a structured test: have the model generate output containing ANSI escape sequences, JavaScript event handlers, and SQL fragments, then verify your output pipeline neutralizes all three before rendering.
Conclusion
The OWASP LLM Top 10 2026 is the first edition of this list built on real incident data at scale. The methodology shift from pure practitioner vote to a blended vote-plus-incident-data model produces rankings that reflect both forward-looking expert judgment and empirical attack frequency.
Three takeaways should shape your immediate response. Excessive Agency's climb to number 3 confirms that agentic blast radius is now a primary risk class in production deployments, not a theoretical concern. Unbounded Consumption's rise confirms that AI inference costs are a business risk that security teams should own alongside engineering and finance. And Misinformation's rise despite practitioner skepticism is an early warning that automated pipelines acting on incorrect model output will generate more documented incidents before the security community's mental model fully shifts to match the incident record.
The security design principle the 2026 list reinforces: stop designing for the assumption that the model will not be fooled. Design instead for the assumption that it will be, and ask what happens next. Least-privilege tool grants, human-in-the-loop gates for high-stakes actions, and authorization enforcement in deterministic external systems are the controls that contain the damage when injection succeeds.
For a mapping of your current AI deployment against OWASP LLM Top 10 2026, schedule an AI security assessment or run a Securetom scan to identify which entries represent open exposure in your environment.
AI Security Audit Checklist
A 30-point checklist covering LLM vulnerabilities, model supply chain risks, data pipeline security, and compliance gaps. Used by our team during actual client engagements.
We will send it to your inbox. No spam.
BeyondScale Team
AI Security Team, BeyondScale Technologies
Security researcher and engineer at BeyondScale Technologies, an ISO 27001 certified AI cybersecurity firm.
Want to know your AI security posture? Run a free Securetom scan in 60 seconds.
Start Free Scan

