OWASP LLM & MCP Top 10 crosswalk
Two OWASP lists describe the risks of running AI in production: the Top 10 for LLM Applications, about the model call, and the MCP Top 10, about the tool call underneath it. This page maps both to controls that can sit on the request path, and says plainly where they cannot.
OWASP Top 10 for LLM Applications 2026 · OWASP MCP Top 10 (2025)
The LLM rows follow the 2026 edition, published by OWASP on 3 August 2026, and were re-graded against its scope on 19 October 2026. The 2026 edition renumbered eight of the ten entries, renamed System Prompt Leakage to Hidden Context Exposure, and widened Prompt Injection, Supply Chain, Data and Model Poisoning and Improper Output Handling. Older pages and articles that cite LLM07 or LLM09 mean the 2025 entries: see the 2025 numbering below.
The MCP rows were checked on 29 August 2026. The MCP list is a beta release (v0.1) with a full release due October 2026 — entry ids and titles may still change, and this page is re-checked when it lands. Read the primary sources rather than this summary.
What this is not
Neither list is a standard you can comply with. Both are catalogues of risk, so there is nothing to be certified against and no score to achieve. Anything that offers you an "OWASP compliance rating" is selling you something that does not exist.
A request path cannot address every entry. Several of the twenty are about how a model or a dependency was built, which happens long before a request arrives. Saying so is the point of the page — a crosswalk that claims full coverage is not a crosswalk, it is a brochure.
Where controls can act: the LLM Top 10
Each row says what the control needs before it does anything. A row that depends on something you supply, or on a setting that is off by default, is graded by that condition, not by its best case.
| Entry (2026) | Distribution | In plain terms | What a governed request path can do |
|---|---|---|---|
| LLM01 Prompt Injection | Both; the ML classifier and the semantic guard are Enterprise | Someone hides instructions in the input — typed, retrieved, returned by a tool, or inside an image or audio | Partial. Injection detection on the text of a request, and on MCP tool arguments and results (Enterprise). Logs by default; refuses under BLOCK. Image and audio content is not scanned, so the cross-modal attacks this edition added are not covered |
| LLM02 Sensitive Information Disclosure | Both; TOKENIZE is Enterprise | Personal or confidential data reaches the model, or comes back in a reply | Detection with default LOG, BLOCK, REDACT, and Enterprise TOKENIZE, on requests and replies |
| LLM03 Excessive Agency | Enterprise; key scopes and tool allow-lists in both | The system can do more than it should be able to | Approval gates, agent permissions, loop detection and session kill. Off until you set them, except API-key scopes |
| LLM04 Supply Chain | Both, for model allow-lists | A compromised model, dependency or plugin — or a model artifact that is not what it claims to be | Partial. Policy can pin which models a workspace may call, and registered MCP servers are pinned to what they run. The bundled injection classifier ships inside the product. A classifier model loaded from a path you configure is not yet checked against a hash. Model provenance and your own dependencies are a build and procurement control |
| LLM05 Data and Model Poisoning | Neither | Training or tuning data is tampered with, including through fine-tuning | Nothing. It happens before a request. The gateway does not serve fine-tuning endpoints, so a fine-tuning upload cannot go through it — and one sent straight to a provider is not governed: what the gateway does not govern |
| LLM06 Unbounded Consumption | Both for rate limits and size limits; Enterprise for budgets and agent loops | Spend or load runs away | Size limits, timeouts and circuit breakers by default. Rate limits, budgets, per-call limits and loop stops when set |
| LLM07 Misinformation | Enterprise | The reply asserts things nothing supports | Only when the caller sends sources. Grounding is off by default, and checks a reply only against the source documents its request carries. With no sources the reply is not checked, and in this version nothing counts or labels such a reply. The default embedding is a fast lexical one: set the neural embedding for a semantic comparison. Nothing checks a reply with no sources |
| LLM08 Hidden Context Exposure | Both | Context the user should not see — the system prompt, tool definitions, retrieved documents, memory — comes back out | Partial. A reply is compared with the request's system prompt, on streamed replies too; a reworded leak can pass. Tool definitions, retrieved documents and memory are not compared |
| LLM09 Vector and Embedding Weaknesses | Both for embedding calls; Enterprise for the semantic cache | Retrieved or cached data leaks between users, or embeddings are abused | Partial. Embedding requests run the same request checks as chat (PII, injection, policy), and the semantic cache is isolated per workspace. Your vector store and retrieval are not covered |
| LLM10 Improper Output Handling | Both | A reply is passed to another system — a browser, a database, a terminal, a code base — without being checked | Partial. Output schema validation, and sanitisation of script, SQL and server-side-request patterns. Terminal escape sequences and insecure generated code, both added in this edition, are not checked |
Where controls can act: the MCP Top 10
Not included in DVARA Open Source.
| Entry | In plain terms | What a governed request path can do |
|---|---|---|
| MCP01 Token Mismanagement & Secret Exposure | Credentials sit somewhere they should not | Credentials held per workspace — encrypted, or as a reference to your vault — and rotated with a grace window rather than a cutover |
| MCP02 Privilege Escalation via Scope Creep | An agent acquires capability it was never meant to have | Partial. Per-workspace allow-lists of servers and tools, and policy deciding which may be called at all. A report per workspace sets the tools granted beside the tools used: tools nobody called in 90 days, and tools first used long after they were granted. The report is evidence for a person; it removes nothing. A workspace can also hold a new tool on a server it already approved until someone approves it (off by default) |
| MCP03 Tool Poisoning | A tool's description or output manipulates the agent | Partial. Tool descriptions are scanned when they are synced, and a description or schema that changes after approval is held until it is approved again. A risk hint that contradicts what the tool does, such as a delete tool marked read-only, is flagged for review. Injection detection on tool arguments and responses |
| MCP04 Software Supply Chain Attacks | A compromised dependency changes agent behaviour | Partial. A local (STDIO) server is pinned to what it runs: the program or script file, a package at an exact version, or an image digest, checked before every start. A remote server can be pinned to its TLS key, checked on every connection. A mismatch is not started or called, and the server is held until it is approved again. The server's reported name and version are pinned too, and a server registered from the MCP catalog records where it came from. Not covered: a package with no exact version or an image by tag (shown as not pinned), the packages a pinned package depends on, and the registry itself |
| MCP05 Command Injection | Untrusted input becomes a command that runs | Partial. Argument scanning and tool policy. The system that executes the command is not ours |
| MCP06 Intent Flow Subversion | Injected context redirects the agent from its goal | Partial. Injection detection, plus loop detection across the session |
| MCP07 Insufficient Authentication & Authorization | Nobody checks who is calling | Every call carries a workspace identity, each hop is authorised, and on-behalf-of tokens carry the delegation |
| MCP08 Lack of Audit and Telemetry | You cannot reconstruct what happened | A signed, hash-chained record of every call, per-call telemetry, and export to your SIEM. The record never holds a tool's arguments or results, so it cannot leak them; the cost is that it cannot show what was sent: what the MCP audit record keeps. Signed checkpoints with your own keys are not there yet |
| MCP09 Shadow MCP Servers | Servers running outside anyone's governance | Partial. The registry is the allow-list, but only for traffic that goes through it. For the rest, an offline scanner you run reads MCP client config files and dependency files, and Flightdeck compares what it found with the registered servers: shadow MCP servers. It finds what is written down, not what runs. See the limit below |
| MCP10 Context Injection & Over-Sharing | Context leaks between tasks, users or agents | Partial. Scanning on arguments and responses, and workspace isolation of stored context. A tool result can be cut down to the fields a workspace lists for that tool before it reaches the model: keep only the fields a tool needs. Off by default, and set tool by tool; plain-text results cannot be trimmed |
The limit worth stating twice
A control point sees what goes through it. That is the whole mechanism, and it is also the boundary: a team that calls a provider directly, or wires up a tool server nobody registered, is invisible to it. MCP09 Shadow MCP Servers is therefore only half-answerable by any gateway — it can guarantee that governed traffic reaches approved servers, and it cannot tell you about traffic that never arrived. For MCP tool servers DVARA narrows the gap from the other side: a scanner run on developers' machines or repositories lists the servers written into their MCP client config files, and Flightdeck shows which of them are not registered. A server nobody wrote down, or a machine nobody scanned, is still invisible.
Closing the other half is a network and procurement question: egress policy, credential issuance, and knowing which teams hold provider accounts. No product setting substitutes for it.
The model APIs DVARA does not serve at all, and what that leaves ungoverned, are listed in what the gateway does not govern. What each control does when a dependency is down is in what fails open and what fails closed.
The entries nothing on the request path reaches
LLM05 (Data and Model Poisoning), most of LLM04 (Supply Chain), MCP04 and — for the executing system — MCP05. These are about what was built, trained and installed, not about what a request does. They belong to code review, dependency scanning, model provenance and procurement. For MCP04 the Gateway pins what a registered MCP server runs or which key it presents, and holds a change for approval. That catches a server that was swapped after you approved it; it does not tell you whether what you approved was safe, so it does not replace checking what you install.
They are listed here because a crosswalk that quietly omits its own gaps is worse than none: the gaps are where you need a different control, and that is the useful thing to know.
The 2025 numbering
The 2025 edition used different numbers for eight entries. If a document, an audit finding or an older version of this page cites a 2025 id, this is where it went:
| 2025 | Title in 2025 | 2026 |
|---|---|---|
| LLM01 | Prompt Injection | LLM01 |
| LLM02 | Sensitive Information Disclosure | LLM02 |
| LLM03 | Supply Chain | LLM04 |
| LLM04 | Data and Model Poisoning | LLM05 |
| LLM05 | Improper Output Handling | LLM10 |
| LLM06 | Excessive Agency | LLM03 |
| LLM07 | System Prompt Leakage | LLM08, renamed Hidden Context Exposure |
| LLM08 | Vector and Embedding Weaknesses | LLM09 |
| LLM09 | Misinformation | LLM07 |
| LLM10 | Unbounded Consumption | LLM06 |
Which of these you should look at first
The Production AI Readiness Checklist asks fifteen plain questions and turns the gaps you report into a short action list. It takes about five minutes, needs no email, and your answers stay in the browser.
It is a self-assessment, not a test: it records what you believe about your own controls and does not examine them.