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 (2025) · OWASP MCP Top 10 (2025)
Checked 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. Four 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
| Entry | Distribution | In plain terms | What a governed request path can do |
|---|---|---|---|
| LLM01 Prompt Injection | Both; semantic/classifier options depend on configuration | Someone hides instructions in the input to make the model do something else | Injection detection before the model |
| 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 |
| LLM03 Supply Chain | Neither | A compromised model, dependency or plugin | Nothing. This is a build and procurement control |
| LLM04 Data and Model Poisoning | Neither | Training or tuning data is tampered with | Nothing. It happens before a request |
| LLM05 Improper Output Handling | Both | A reply is passed to another system without being checked | Output schema validation and sanitisation |
| LLM06 Excessive Agency | Enterprise | The system can do more than it should be able to | Approval gates, agent permissions, loop detection, session kill |
| LLM07 System Prompt Leakage | Both | The system prompt comes back out in a reply | Partial. The reply is compared with the request's system prompt, on streamed replies too from 1.8.4; a reworded leak can pass |
| LLM08 Vector and Embedding Weaknesses | Enterprise for semantic cache | Retrieved or cached data leaks between users | Partial. Workspace cache isolation; external retrieval is not covered |
| LLM09 Misinformation | Enterprise | The reply asserts things nothing supports | Grounding detection only when the caller supplies sources |
| LLM10 Unbounded Consumption | Both for rate limits; Enterprise for budgets and agent loops | Spend or load runs away | Rate limits, budgets, per-call limits, and loop stops |
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 four entries nothing on the request path reaches
LLM03, LLM04, MCP04 and — for the executing system — MCP05. These are about what was built and what was installed, not about what a request does. They belong to code review, dependency scanning, model provenance and procurement. For MCP04 the Gateway now 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.
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.