OWASP Top 10 for LLM Applications: What Enterprise MCP Teams Need to Know

The OWASP Top 10 for LLM Applications is a dedicated OWASP list, published in November 2024, that maps the main security risks in large language model applications at both the model and application layers, including prompt injection, sensitive information disclosure, supply chain vulnerabilities, and data or model poisoning. A security team can finish a clean pass through that list, prompt injection tested, output handling validated, sensitive information disclosure checked, and still fail to answer a basic question about its own deployment: has the MCP server their coding agent connects to every day ever been vetted for anything at all? The audit passed. The question it never asked was the one that mattered.

That gap exists because OWASP AI Top 10 is not one document. OWASP’s GenAI Security Project maintains three separate lists, built for three different attack surfaces, and most vendor content, from security blogs to Palo Alto Networks and other major vendors’ own explainers, collapses them into a single undifferentiated “OWASP AI security” reference that leaves enterprise MCP security teams and the people responsible for managing or auditing LLM and agent security checking a box that was never built to cover their actual risk.

Large language model applications inherit a different threat model than traditional software, and that distinction is worth stating plainly before going further. Web application security deals with injection, broken access control, and misconfiguration at the HTTP layer. Generative AI systems introduce the model’s behavior itself, its reasoning, its fine tuning methods, its retrieved context, and the pathways between tools, agents, and MCP servers as the attack surface, which is why AI technologies built on LLMs and AI driven applications built on agents each earned their own OWASP list rather than being folded into the existing web application top 10.

What follows separates the OWASP Top 10 for LLM Applications, Agentic Applications, and MCP, shows which LLM risks transfer into MCP environments and which gaps the MCP Top 10 covers separately, walks through a real vulnerability example, and ties those distinctions to security posture management and how an MCP Gateway like Obot plays a role. For teams securing production AI systems, getting those boundaries right is the difference between a superficial audit and one that actually covers protocol-level MCP risk.

The Three OWASP Lists, and Which One Actually Governs MCP

The OWASP GenAI Security Project is an open source initiative dedicated to identifying, mitigating, and documenting security and safety risks in generative ai technologies, and it publishes three distinct top-10 lists at different levels of maturity; conflating them is the single most common mistake in vendor content on this topic.

The OWASP Top 10 for LLM Applications Covers Model Input and Output, Not Tools

The OWASP Top 10 for LLM Applications, released November 17, 2024 as the 2025 edition, catalogs risks in large language models (LLMs), large language models, and LLM technologies at the application and model level. Its ten categories, LLM01 through LLM10, cover prompt injection, sensitive information disclosure, supply chain vulnerabilities, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. It’s the most mature and most widely referenced of the three, and it was written for the surface where an LLM receives input and produces output, with controls that apply input validation to requests and validate LLM outputs against expected output formats where relevant, not for the protocol layer that connects an agent to external tools.

The OWASP Agentic Top 10, formally the OWASP Top 10 for AI Agents, and published as the OWASP Top 10 for Agentic Applications, was finalized in December 2025 with input from over 100 security researchers and practitioners including contributors from NIST and the European Commission, and addresses risks specific to autonomous behavior: an agent’s goal getting hijacked mid-task, tool misuse, and agentic supply chain manipulation. It sits above the LLM Top 10, addressing what an agent does with its autonomy rather than what a model produces from its input.

OWASP MCP Top 10 is the newest and least mature of the three, an incubator project at version 0.1, currently in Phase 3, pilot testing, according to OWASP’s own project roadmap. It’s narrower and more protocol-specific than either of the other two: ten categories, MCP01 through MCP10, targeting the tool discovery, context passing, and tool invocation layer specifically. Citing it accurately means saying what it is, a beta document still gathering community feedback, not a finished standard. Overstating its maturity would be a bigger credibility problem than the fact that it’s still in draft.

List	Published	Covers	Governs MCP directly
LLM Top 10	Nov 2024	Model input and output risk	No, partial overlap only
Agentic Applications Top 10	Dec 2025	Autonomous agent behavior	Partially, at the behavior layer
MCP Top 10	2025, beta	Protocol-level tool and context risk	Yes, this is its entire scope

Worth knowing before citing the LLM Top 10 by category number: the numbering isn’t stable across editions. Insecure Plugin Design, a standalone entry in the 2023 release describing how malicious inputs can exploit insecure plugin designs, tricking a model’s plugins into unsafe external calls or unvalidated data handling, was removed in the 2025 update and its concerns distributed across LLM03 Supply Chain and LLM06 Excessive Agency. Model Theft was removed the same way, folded into LLM10 Unbounded Consumption, which itself expanded from the older, narrower Model Denial of Service category to also cover uncontrolled, resource heavy operations that drive up cost rather than only crashing a service; Model Denial of Service happens when excessive queries overload model resources, and rate limiting is a standard mitigation for unbounded consumption. And Improper Output Handling, which security teams may still remember by its 2023 name, Insecure Output Handling, at LLM02, dropped to fifth in the 2025 reordering, not because the underlying risk weakened, but because prompt injection and sensitive information disclosure were judged more critical to lead with. A team citing “LLM02” from memory in 2026 is very possibly citing a category that hasn’t held that number in over a year.

Where the LLM Top 10 Actually Transfers to MCP Risk

Not every LLM Top 10 category is relevant to an MCP deployment. Mapping all ten onto MCP risk with equal weight, the way some vendor content does, isn’t thoroughness. It’s a way of avoiding the harder judgment call about which ones actually matter here.

Prompt Injection Transfers Directly to MCP

Prompt injection is the one that transfers cleanest. LLM01, the top-ranked risk in the owasp llm top 10 2025 release, was written around untrusted user input reaching the model, and a tool response returned through an MCP server is exactly that, even though the category predates MCP tool outputs becoming a mainstream injection vector. Worth keeping the two variants straight: direct prompt injection occurs when an attacker’s instructions arrive through the same channel a legitimate user would use, while indirect prompt injection arrives through retrieved context or external source material before it reaches the model, which is what a compromised MCP tool response actually is. OWASP’s own guidance is blunt about the fix either way. A system prompt is not a secret and was never a security boundary. These prompts often contain business logic and should not be treated as a secure boundary. Malicious instructions delivered through either channel steer the model regardless of what the system prompt says.

Supply Chain Risk Transfers One Layer Removed

Supply chain risk transfers too, just one layer removed. LLM03 was written for compromised models, third party models, and third party components in the supply chain, along with the need for an up to date inventory; a third-party MCP server is the same kind of dependency, sitting between the organization and whatever code actually executes when a tool gets called, and compromised dependencies can lead to security breaches and system failures.

Then there’s LLM06, Excessive Agency, the closest single anchor point in the entire list for MCP risk. A system granted more excessive functionality, permission, or autonomy than it needs is not a hypothetical. It’s the exact description of an MCP server with scope nobody trimmed after the initial approval.

Training Data Poisoning Stays Upstream, Improper Output Handling Doesn’t

Two categories transfer only conditionally. LLM04, Data and Model Poisoning, mostly doesn’t, and it’s worth being precise about why rather than forcing a connection. Data poisoning targets training data a model learned before it ever made a tool call, tampered training data that degrades accuracy and decision-making, or that a model memorizes and reproduces as verbatim fragments later, and the whole category gets grouped under model poisoning for exactly this reason. A malicious competitor trying to damage a model’s reputation through poisoned training data is playing entirely upstream of MCP, and the standard fix, sanitizing data before training, has nothing to do with tool governance. LLM05 is the opposite case. Improper output handling transfers directly whenever an MCP tool’s output flows to a downstream system without validation, and it also means validating LLM outputs against expected output formats before downstream use, since unvalidated output reaching a shell, a database query, or a rendered page can trigger remote code execution, server side request forgery, or stored cross-site scripting, the same failure mode insecure output handling described under its old 2023 name, just with a tool call standing in for the vulnerable code path.

One more category deserves a specific mention rather than getting lumped into “doesn’t transfer”: LLM09, Misinformation. LLMs can produce factually incorrect results or hallucinations, and that’s normally treated as a model-quality problem, not a security one. It stops being purely a quality problem the moment a hallucinating agent decides which MCP tool to call or what parameters to pass it, especially when those actions involve sensitive data. A model that confidently fabricates a file path, a customer ID, or a belief about what a tool actually does, then acts on that fabrication through a real tool call, has turned a hallucination into a downstream action with real consequences. The mitigation still lives mostly at the model level, grounding, retrieval verification, confidence calibration, but the blast radius is an MCP-layer problem once the hallucination reaches a tool call instead of staying in a chat window.

The rest genuinely don’t transfer, and saying so plainly is more useful than pretending otherwise. LLM02, LLM07, and LLM08, sensitive information disclosure, system prompt leakage, and vector and embedding weaknesses, stay squarely at the model level. Sensitive information disclosure is built around a model exposing sensitive data, including personally identifiable information or confidential data from its training or context, a large language model problem, not a tool-authorization one. System prompt leakage is about the model’s own instructions getting extracted. Vector and embedding weakness issues stem from insecure vector databases and misconfigured access on embedding data, corrupting retrieval augmented generation pipelines. None of it describes what happens when an agent reaches an external tool through MCP. An organization auditing its attack surface against these three specifically is auditing the wrong layer.

What the MCP Top 10 Covers That the LLM Top 10 Structurally Can’t

This is where the actual depth lives, and it’s protocol-level failure, not model-level failure, which is exactly what the LLM Top 10 was never positioned to catch.

Start with the gap that opened this article. MCP08, Lack of Audit and Telemetry, describes limited telemetry from MCP servers and agents that leaves an organization unable to reconstruct what happened after something goes wrong. Closing it means tool-call-level audit trails, not model-output logging dressed up to look like coverage of a layer it never touched.

MCP09 names a pattern every platform team recognizes once someone says it out loud: Shadow MCP Servers. Unapproved instances spun up by developers for convenience, operating outside formal security governance, the same story as shadow IT with a new name. Catching this is a discovery problem before it’s an enforcement problem. Something has to find what’s already running on developer machines before any policy can govern it.

MCP02, Privilege Escalation via Scope Creep, is quieter and slower. Permissions inside a server expand over time until an agent holds more capability than anyone explicitly granted, and nobody notices because no single approval was ever wrong on its own. Per-tool access control, scoped at the individual call rather than the session, is the only structural answer that catches drift instead of just the initial grant.

MCP07, Insufficient Authentication & Authorization, is a distinct failure from excessive agency even though the two get conflated constantly. Excessive agency is a scope problem, a server allowed to do more than it should. MCP07 is a verification problem, a server or agent that never properly confirmed who it was talking to in the first place.

Tool poisoning, MCP03, might be the single MCP-specific risk with the clearest real-world precedent. Rug pulls, schema poisoning, tool shadowing, an adversary compromising the tools or outputs a model depends on. MCP tool poisoning requires no exploit at all when a previously trustworthy server simply updates its own tool definitions after approval. That’s the whole attack. Registration-time scanning before a server is discoverable at all is the direct countermeasure, and the open-source MCP Gateway and Registry project is the clearest public example done openly: three Cisco AI Defense scanners run against every asset at registration, disabling anything that fails before an agent can ever connect to it.

One more thing worth flagging, because it’s the kind of detail that only shows up if the primary source actually got read rather than summarized secondhand. OWASP’s own MCP Top 10 page currently contradicts itself. The summary table labels MCP06 “Intent Flow Subversion.” The detailed section on the same page, further down, labels the identical entry “Prompt Injection via Contextual Payloads.” That’s not a knock on the project. It’s exactly what a beta document under active pilot testing looks like, and it’s worth knowing before anyone cites MCP06 by a name that might not survive the next revision.

👉 Obot helps enterprises operationalize MCP governance with centralized control, observability, and secure connector management. Try Obot today.

Where CVE-2026-32211 Sits Across All Three Lists

CVE-2026-32211, a missing-authentication flaw Microsoft rated CVSS 9.1 in the Azure MCP Server, is a useful test case for exactly this framework, because it makes the disambiguation concrete instead of abstract.

It doesn’t fit the LLM Top 10 cleanly. It’s not a prompt injection issue, LLM01, and it’s not improper output handling, LLM05. The model behaved exactly as designed. The vulnerability lived entirely outside what that list was built to evaluate.

It fits the MCP Top 10 precisely, under MCP07, Insufficient Authentication & Authorization: an MCP server that failed to properly verify identity before handing over data. A security program that ran a thorough LLM Top 10 audit and called its MCP layer covered would have had no mechanism for catching this, because the vulnerability sat in a category that audit was never scoped to check.

Security Posture Management for an Enterprise MCP Team

Running one audit and calling the AI security program complete is the practical mistake this framework is meant to prevent. Mitigation strategies that secure LLMs work through at the model level, training data hygiene, output filtering, access control on pre-trained models, are necessary but not sufficient once agents start reaching MCP tools. The LLM Top 10 covers the model surface, where strong access controls on training data, fine-tuning pipelines, and output filtering do most of the work. The MCP Top 10, with its beta status noted honestly rather than hidden, covers the protocol surface, where least privilege access for every registered tool and continuous threat intelligence on which servers have changed since approval matter more than model-level filtering ever will. A mature program tracks both, deliberately, rather than conflating them into a single checklist that ends up covering neither surface completely.

That includes being honest about what citing a still-beta OWASP project means. A security posture management program that references the MCP Top 10 accurately, version 0.1, incubator status, still gathering pilot feedback, is more credible than one that either ignores it because it isn’t finished or cites it as if it were a ratified standard. Critical controls get adopted before they’re perfect. Pretending otherwise is the actual credibility risk, not the beta label itself.

Where Obot Fits for AI Agents Reaching MCP Tools

Obot’s MCP Gateway is positioned specifically against the MCP Top 10 categories mapped above, not against the LLM Top 10 broadly, because that’s not the layer Obot governs. OWASP LLM risks like prompt injection and output handling are closer to the runtime detection tools that operate at the model and session level. What Obot does is close the protocol-level categories: a built-in curated MCP catalog for registration-time vetting against MCP03, fine grained access control scoped to individual tools against MCP02, and tool-call-level audit logging against MCP08, all independent of whatever LLM-level controls sit above it.

Obot is open-source under the MIT license, self-hostable on Kubernetes or Docker, or available as a managed service, same product either way. It brokers OAuth server-side so raw credentials never reach MCP servers directly, and offers enterprise identity integration with Okta and Microsoft Entra in the Enterprise edition, both addressing MCP07 directly. Obot does not detect prompt-injection at the model level, and does not replace an organization’s existing LLM Top 10 program, but is instead the infrastructure layer for the protocol surface that program was never built to see.

Where This Leaves You

Three lists, ten risks apiece for the two finished ones, three different jobs. An enterprise MCP team that only tracks the LLM Top 10 has a real, useful, well-documented application security program covering security risk at the model layer, and it is checking a box that was never built to cover the layer where an agent actually reaches a tool. Attackers manipulate whichever layer is left unguarded, and outputs generated by a perfectly governed model still travel through an MCP server that a model-level audit was never scoped to check. The MCP Top 10 is younger and less finished, and it’s the one aimed directly at that gap. Citing it honestly, beta status and all, is a stronger security posture than treating the LLM Top 10 as complete coverage it was never designed to be.

Get Started with Obot

Try Obot for free · Get a demo · Read the docs

FAQ

What is OWASP in cyber security?

OWASP, the Open Worldwide Application Security Project, is a nonprofit foundation that publishes vendor-neutral, community-maintained security standards and awareness documents. It’s best known for the original OWASP Top 10 for web applications, and its newer GenAI Security Project extends that same community-driven model to AI-specific risk, producing the LLM, Agentic Applications, and MCP top-10 lists covered in this article.

What is OWASP Top 10?

In its original and most widely known form, the OWASP Top 10 is a list of the most critical security risks facing web applications, things like broken access control and injection flaws, last updated as OWASP Top 10:2025. It’s a different document from the OWASP Top 10 for LLM Applications discussed here, built for a different attack surface, the HTTP layer rather than a model’s reasoning and tool access.

How often is OWASP Top 10 updated?

The classic web application OWASP Top 10 has historically updated roughly every three to four years. The OWASP Top 10 for LLM Applications moves faster, released in 2023 and updated to its current 2025 edition in November 2024, about 14 months later, reflecting how quickly LLM and agentic attack patterns have been changing. The OWASP MCP Top 10 is newer still and hasn’t reached a first stable release yet.

How to use OWASP for an MCP deployment?

Don’t run a single audit against a single list and call AI security complete. Use the LLM Top 10 to evaluate model-level risk, prompt injection, output handling, training data integrity, use the Agentic Applications Top 10 for autonomous behavior risk, and use the MCP Top 10, with its beta status noted honestly, for the protocol-level risk of what an agent can reach and do through a tool. All three inform a security program. None of them substitutes for the other two.

Does the OWASP LLM Top 10 cover MCP-specific risks?

Partially. LLM01 Prompt Injection, LLM03 Supply Chain, and LLM06 Excessive Agency transfer meaningfully to MCP risk. LLM02, LLM07, and LLM08 are largely model-level concerns that don’t. No category in the LLM Top 10 was written with MCP’s tool discovery and invocation layer specifically in mind, since MCP wasn’t a mainstream attack surface when the list was drafted.

Is the OWASP MCP Top 10 an official, finished standard?

Not yet. It’s an OWASP incubator project at version 0.1, currently in Phase 3, pilot testing, according to OWASP’s own published roadmap. Citing it as a finalized standard would overstate its maturity. Citing it as a beta document that already names ten real, well-described MCP risk categories is accurate and still useful for a security program.

Which OWASP list should an enterprise MCP team check first?

Start wherever the actual gap is. If model-level controls, prompt injection defenses, output validation, are already mature, the MCP Top 10 categories around registration-time vetting, audit trails, and shadow server discovery are usually the larger unaddressed risk, since almost no vendor content covers that layer with real depth yet.