OWASP Top 10 for LLM Applications 2026: What It Means for Production AI Systems

OWASP published the 2026 edition of its Top 10 for LLM Applications in early August, and the useful part isn't the list itself. It's what moved and why. The taxonomy keeps the same ten slots, LLM01 through LLM10, but the ordering changed enough to be worth reading closely. Excessive Agency jumped from sixth place to third, and Unbounded Consumption climbed from tenth to sixth. Improper Output Handling fell from fifth all the way to tenth. OWASP's own account of how the 2026 list was built describes a rank based mostly on community and expert judgment, weighted at roughly three-quarters. That rank was checked for the first time against a corpus of real-world incident reports, which carried the remaining quarter of the weight.

How OWASP Calculated the Ranking

That's worth being precise about: a category's position is a blend of practitioner consensus and incident review. It is not a direct measurement of how often each risk gets exploited in the wild. Prompt injection holding first place despite a comparatively thin incident record is itself evidence of that gap. It's a gap between what the data shows and what the field still judges most dangerous. Read with that caveat, the movement still points somewhere useful. The risks tied to autonomy, tool access, and runaway resource consumption have gained enough weight in that combined judgment. Flat prompt-filtering advice no longer covers the ground it used to.

What the Ranking Signals

That reordering is also a reasonable proxy for how production AI systems have changed since the 2025 list. Two years ago, most of what people meant by "LLM security" was a chatbot answering questions with some retrieval behind it. What's shipping now is closer to a system: an LLM with tool access, a set of MCP servers exposing internal APIs. It also includes a vector store holding proprietary documents. It also carries enough autonomy to take actions without a human confirming every step. The 2026 categories cover the same conceptual ground as before, but the guidance underneath them has shifted. It moves away from "watch what goes into the model and what comes out of it." The new guidance is closer to assuming the model will be fooled some of the time. It calls for designing the system so that being fooled doesn't automatically translate into a costly outcome. That's the core shift underlying the whole update.

How Production AI Systems Changed

It's worth being precise about scope before going further, since OWASP's GenAI Security Project now maintains three related documents that are easy to conflate. The Top 10 for LLM Applications, the one this article is about, treats the model as a component: something that receives input and produces output. It asks what can go wrong at that boundary. A separate Top 10 for Agentic Applications, numbered ASI01 through ASI10, covers what happens once that model becomes an actor. That actor has memory, delegated credentials, and the ability to chain actions across many steps. A third document, the MCP Top 10, is narrower still. It focuses specifically on the tool-connection protocol layer between an agent and the external systems it calls.

Which OWASP List Applies

If you're building anything with meaningful agent autonomy or MCP-based tool access, this article is a reasonable starting point. But it isn't a substitute for those two more specialized lists. Where the LLM Top 10's guidance runs into the edge of what it can meaningfully say about agent behavior, that's a signal. It usually means it's time to go look at the Agentic or MCP lists instead.

Prompt Injection Hasn't Been Solved, and the List Says So

Prompt injection holds LLM01 for the third consecutive edition, and the 2026 update mostly widens what counts. Cross-modal attacks are now explicitly in scope, meaning instructions hidden inside an image or an audio clip that text-based filtering never looks at. The underlying problem hasn't changed since 2023. A model processes instructions and untrusted data through the same channel, with no equivalent of a parameterized query to separate the two. Direct injection is a user typing something adversarial. Indirect injection is more consequential in production: an email, a web page, a retrieved document, or a tool's return value carries the payload. The person interacting with the system never typed anything unusual at all.

Why Prompt Sanitization Is Not Enough

The advice to "sanitize the prompt" doesn't hold up against this. There's no reliable way to distinguish an instruction from data when both arrive as the same token stream. No filter list keeps pace with how many ways there are to phrase the same instruction. Treating the system prompt as a security boundary is a related and equally common mistake. A system prompt is a strong steering signal, not an access control mechanism. A sufficiently motivated attacker, with enough turns or enough context to work with, can get a model to deprioritize instructions. Those instructions were never enforced by anything outside the model itself.

Controls Outside the Model

The direction OWASP points toward, and the one worth taking seriously, is architectural. Since injection can't be reliably prevented at the text layer, the system around the model needs to bound what a successfully injected model can do. That means bounding which tools it can invoke and what those tools are scoped to touch. It also means bounding what happens downstream of anything it outputs. That's a design constraint on the whole application, not a prompt-engineering task.

What the Model Knows That It Shouldn't Say

Sensitive Information Disclosure keeps its second-place ranking, and its cause is straightforward. LLMs are trained on and prompted with a mix of legitimate and sensitive data. Outputs aren't cleanly separable from the training or context that produced them. The practical failure mode in production systems is less about the model spontaneously reciting training data. It's more about applications feeding it things it shouldn't have access to in the first place. Examples include customer PII pulled into a support-bot context window and credentials embedded in a system prompt for convenience. Another example is a RAG pipeline retrieving documents the current user isn't authorized to see. In each case the model is handed the material as if authorization had already been checked.

Hidden Context Exposure

2026 also folds in a category that used to be scoped much more narrowly. What was System Prompt Leakage in the 2025 list is now Hidden Context Exposure at LLM08, and the rename reflects a real widening of scope. A system prompt was never the only thing worth protecting. Retrieved policy text, tool schemas, role definitions, refusal logic, and workflow rules are all non-user-facing content that gets assembled into a model's context at runtime. All of it is discoverable through the same kind of probing that used to be aimed only at extracting the system prompt. An attacker doesn't necessarily start by asking for something obviously sensitive. They map the application first, asking what tools exist, what a refusal looks like, and how the model describes its own permissions. Each answer narrows the space for a precise, application-specific attack later.

What Must Stay Out of Model Context

The engineering implication is the same one that applies to credentials generally. Nothing that would be damaging if extracted belongs in a system prompt or in any context assembled dynamically during a session. That includes an API key, an authorization rule, or an internal role name that maps to a privilege level. That's because the operating assumption now has to be that hidden context is not reliably hidden.

The Category That Moved the Most

Excessive Agency climbing from sixth to third is the single biggest ranking change in the 2026 edition. It tracks a real shift in what LLM applications do. A model that only answers questions has a bounded blast radius. A model that can call tools, query a database, or send an email lacks that same bounded blast radius. So does one that can invoke an MCP server that reaches into internal infrastructure. And the risk isn't hypothetical: prompt injection and excessive agency compound each other. An injected instruction is only as dangerous as what the compromised model is permitted to do next.

MCP Expands the Execution Surface

MCP has become an increasingly common way for agents to reach external systems, and it introduces its own version of a familiar problem. Each MCP server is effectively a plugin with its own execution surface. An agent connected to several of them at once has a correspondingly larger attack surface if any single server is compromised or subtly malicious. That's because tool descriptions and schemas from one server are often treated as trustworthy input by the agent orchestrating calls across all of them. This is a supply chain and identity problem as much as a prompt security one: every MCP server an agent talks to is a dependency. Every tool call is an action taken under some identity, ideally a scoped, short-lived one rather than a standing credential shared across every session.

Why Approval Alone Is Not Enough

Human-in-the-loop approval is the control everyone reaches for here, and it's necessary but not remotely sufficient on its own. Approval fatigue is real: an agent that asks for confirmation before every action trains its human reviewers to click approve without reading. A single overly broad approval, "yes, sync the calendar," can be interpreted by the agent as license for a chain of steps. The human never saw those steps individually. Approval also has to happen at the right layer. Authorizing an agent to use a tool at configuration time is not the same thing as authorization. Real authorization means approving the specific action it's about to take with that tool right now, in the moment. Permission scoping that's checked once at setup and never revisited tends to accrete over time. Eventually the agent's effective privilege bears no relationship to what it was originally granted.

Enforcing Authorization at Invocation

The more defensible pattern is enforcement at the point of invocation. That means least-privilege, narrowly scoped tools, plus authorization checks tied to the specific user and action rather than just the agent's identity. It also means hard limits on the scale or reversibility of what a single action can do. Human approval should be reserved for the genuinely irreversible steps, with enough specificity in what's being approved that a reviewer can meaningfully evaluate it.

Supply Chain, Poisoning, and the Dependencies You Didn't Choose Directly

Supply Chain risk at LLM04 has always covered pretrained models pulled from public hubs and fine-tuning datasets of uncertain provenance. It also covers third-party plugins or frameworks that sit in the request path. What's changed is that MCP servers now belong on that same dependency list. A team that would never install an unvetted npm package into production behaves differently with agents. That same team will often connect an agent to a third-party MCP server with much less scrutiny. That's despite the server being able to execute code and return data that gets treated as trusted context. It can also update on its own schedule outside the application's own release process. Provenance and version pinning, the same discipline applied to any other third-party dependency, apply here too.

Data and Model Poisoning

Data and Model Poisoning at LLM05 sits one step upstream of that. It covers manipulated training data, fine-tuning data, or embedding data that introduces a backdoor, a bias, or degraded behavior. That behavior doesn't show up until a specific trigger condition is met. The 2026 edition folds fine-tuning subversion into this category rather than treating it separately. That matches how most teams consume external data: less through raw pretraining and more through fine-tuning on a vendor's dataset. It can also mean building a RAG index over documents whose provenance nobody has closely examined.

Resource Abuse Beyond a Simple Rate Limit

Unbounded Consumption moved up four places. The reason is that request-per-second throttling, the standard defense when this category was mostly about denial of service, doesn't address what agentic systems do wrong. Consider an agent stuck in a reasoning loop, or a tool call that triggers a chain of further tool calls. A task that quietly reruns itself after a transient failure is another example. Any of these can burn far more in tokens and API spend than any traffic spike would. None of it looks like abuse from a network monitoring perspective, because every individual request is legitimate.

Application-Level Resource Controls

The controls that address this sit closer to the application logic than the network edge. They include token quotas and per-run budgets, hard spending ceilings rather than soft alerts, and recursion limits on agent loops. What's needed are circuit breakers that halt a task when it crosses a cost or iteration threshold, rather than one that only fires on volume.

When the Output Is Wrong and Something Downstream Believes It

Misinformation carries more weight in 2026 than its ninth-place ranking in 2025 suggested. The reason is architectural rather than about the model getting smarter or dumber. Confident, wrong output stopped being purely a user-facing quality problem once that output started getting consumed by something other than a human. Consumers now include another agent in a pipeline and a downstream workflow that acts on the model's claim about system state. They also include a business process that treats the response as a fact rather than a probabilistic guess.

What RAG Actually Mitigates

RAG is the standard mitigation offered here, and it's worth being precise about what it does. Retrieval-augmented generation doesn't prevent hallucination; it changes what gets hallucinated about. Grounding a model in retrieved documents reduces the odds it invents something from nothing. But it does nothing to guarantee the retrieved documents are current, correct, or even relevant to the specific question. A model can be confidently wrong while citing a real but outdated or mismatched source. That failure is arguably harder to catch than one that's plainly fabricating an answer. That's because the citation itself reads as credibility.

Validating Downstream Decisions

The mitigation that matters is downstream. Anything consuming model output as a factual input to a decision needs a way to distinguish a grounded, sourced claim from an ungrounded one. That's true whether the consumer is a human or another automated step. Irreversible actions shouldn't be triggered on the strength of an LLM's unverified assertion alone.

Retrieval Is Its Own Attack Surface

Vector and Embedding Weaknesses gets less attention than the risks above it. It moved down only one position in the 2026 reordering, from eighth to ninth. That says less about this risk fading and more about how much ground the categories above it gained. RAG systems introduce a retrieval layer that has its own failure modes independent of the model doing the generating. Poisoned content can be engineered to score highly on similarity search and get retrieved into a legitimate query's context. That's a more targeted version of data poisoning, aimed specifically at the retrieval path rather than training. Embedding models themselves can be manipulated to distort what counts as similar. This degrades retrieval quality in ways that are hard to detect, because the system still returns confident-looking results.

Authorization Inside the Retrieval Query

The access control question is worth the most engineering attention, because the common implementation pattern quietly depends on a second control working correctly every time. Multi-tenant systems that run the vector search first and then filter results by tenant afterward aren't leaking data by default. If that downstream filter is implemented correctly, another tenant's records get pulled into the retrieval step internally. But they are stripped out before they reach the model, the application's output, or the user. The exposure is the dependency itself: a sufficiently specific query can pull another tenant's data into the similarity results. Everything after that point relies on the filter being present, correctly scoped, and never bypassed. That means the whole authorization guarantee is only as strong as that one downstream check.

Stronger Tenant Isolation

Enforcing authorization as part of the retrieval query itself removes that dependency rather than adding a second layer behind it. Unauthorized records are never pulled into the candidate set in the first place. Hard namespace or index-level separation per tenant is one solid way to get there, though not the only one. The underlying requirement is that retrieval authorization shouldn't rest entirely on a single downstream filter. There needs to be a fallback in case that filter is missing, misconfigured, or bypassed. Treating every retrieved chunk as untrusted input is the more general version of the same principle. It's the same posture applied to anything else a model reads before responding.

The Category That Fell the Furthest

Improper Output Handling dropped from fifth place to tenth, the largest fall in the 2026 reordering. It's worth being clear that this reflects relative severity elsewhere on the list, rather than this risk disappearing. Output handling failures happen when a model's response gets passed to a downstream system. That system might be a database query, a shell command, a browser rendering context, or another API. That happens without the same validation any other untrusted input would receive. The mistake that keeps recurring is treating "the AI said so" as a reason to skip a validation step. That step would obviously apply to user input from any other source.

Treating Model Output as Untrusted Input

A model's output is still just a string or a JSON object produced by a probabilistic process. This includes structured output and the arguments it hands to a tool call. It deserves exactly the scrutiny any unvalidated external input gets, before it's allowed to execute, render, or query anything. Filtering the output for obviously bad patterns catches the cases someone thought to test for. It misses the ones that don't look like an attack until they're already running somewhere they shouldn't be.

Reading the List as a System, Not a Checklist

The categories above connect more than a flat top-ten format usually suggests. Prompt injection is the entry point; excessive agency and improper output handling are what determine how much a successful injection costs. Hidden context exposure and sensitive information disclosure are both about what a probing attacker can learn before or during an attack. Vector weaknesses, poisoning, and misinformation are all versions of the same underlying issue. That issue is a system trusting content it retrieved or generated without verifying where that content came from. None of this is OWASP's own framing; it's this article's reading of why the categories cluster the way the 2026 reordering suggests. OWASP's actual contribution is the taxonomy, the incident-informed ranking, and the mitigation guidance attached to each numbered category.

A System-Level Reading of the Top 10

Treating an LLM application's security as an engineering conclusion means seeing it as an emergent property. It emerges from identity, authorization, validation, and resource boundaries around a component that will occasionally be fooled. It's one this article is drawing from the pattern, not a claim OWASP makes on its own behalf.

Where This Fits for SiegePal

SiegePal's work in this space includes LLM integrations, MCP server development, and generative AI applications built around structured LLM output. It also includes multi-agent architecture for cybersecurity use cases and cloud-native AI deployment. That background shapes the engineering perspective in this article, particularly around where MCP and agent tool-calling boundaries need to sit. It does not imply any specific client engagement, finding, or incident behind any individual point made above. More on that work is on our AI engineering page.

References

• OWASP GenAI Security Project, `OWASP` Top 10 for `LLM` Applications 2026 (August 2026)
• OWASP GenAI Security Project, `OWASP` Top 10 for Agentic Applications 2026 (December 2025)
• OWASP GenAI Security Project, GenAI Security Industry Framework Crosswalk
• OWASP GenAI Security Project, Glossary