OWASP LLM Top 10 (2025): Which Risks a Gateway Actually Fixes

What the OWASP LLM Top 10 actually is

The OWASP Top 10 for Large Language Model Applications is a consensus list of the most critical security risks in LLM-backed software, maintained by the OWASP GenAI Security Project. The current version is the 2025 list at genai.owasp.org/llm-top-10. The v1.1 list from 2023/24 is still archived there and still widely quoted - so if a post mentions Model Theft or Overreliance, it is describing the retired version.

The 2025 list as OWASP publishes it:

What changed shows where attention moved. System Prompt Leakage and Vector and Embedding Weaknesses are new. Model Denial of Service became the broader Unbounded Consumption. Insecure Plugin Design folded into supply chain and excessive agency as tooling settled around protocols like MCP. Model Theft dropped off entirely.

Where each control actually lives

This is the part most write-ups skip. The Top 10 lists risks, and a risk is not a product feature. Four belong to the inference path, where a gateway sits. Three belong to application code. Three belong to pipelines a gateway never sees.

Four squarely in scope, three partials, three needing an owner elsewhere. If your AI security framework has a gateway row for LLM04 and LLM08, that row is decorative.

A gateway covers LLM01, LLM02, LLM06, and LLM10 well because all four are request-path problems: they happen the moment a prompt goes out or a tool fires, which is the only moment a gateway sees. The rest were decided weeks earlier, in a training run or an indexing job.

Where teams get this wrong

Treating the list as a compliance checklist. OWASP publishes a risk taxonomy with mitigation guidance, not a certification. There is no OWASP LLM Top 10 audit and no body that issues a pass. A matrix claiming all ten are “covered” by one tool is written to survive a meeting, not an attack.

Putting output validation in the wrong place. LLM05 is about what your application does with model output. A gateway can flag that a response contains os.system or an unescaped script tag. It cannot stop your service feeding that string into a shell. The control belongs where output is consumed; the gateway check is defence in depth.

Assuming injection detection is prevention. Detection is a classifier, classifiers have false negatives, and attackers iterate against them. The durable mitigation for LLM01 is to assume injection occasionally succeeds and make that survivable - which is really an LLM06 problem. Narrow the tool surface and a successful injection reaches a model with nothing dangerous to call.

Ignoring LLM10 as a billing concern. An agent stuck in a loop is a denial-of-service against your own budget, and high-volume querying is how model extraction works. It is the easiest entry to close, and the most commonly left open.

Want to see which of these you can close today?

Attach a guardrail group to a single model and watch it fire in Request Traces.

Get started free

How this works in TrueFoundry

TrueFoundry’s AI Gateway implements these controls as guardrails on hooks in the request path. There are four, and which risks you can address depends on which hook you are on.

For LLM requests: input, before the prompt reaches the model, and output, after it responds.

For MCP tool calls: mcp_pre_tool, before the tool executes, and mcp_post_tool, after it returns.

Those MCP hooks make the owasp mcp question tractable. Guardrails run on every tool call separately - five tools in a row means five sets of checks. A pre-tool failure means the tool never runs; a post-tool failure withholds the result.

Each guardrail has an operation mode - validate inspects and can block, mutate also rewrites - and an enforcement strategy covering violations and guardrail errors:

‍