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:

LLM01: Prompt Injection

The built-in Prompt Injection guardrail is powered by Azure Prompt Shield and managed by TrueFoundry, with no third-party keys. It analyses the user prompt and any document or context content separately, so indirect injection hidden in a retrieved document is caught alongside a direct “ignore all previous instructions”. Validate-only. Add it from the Guardrails section:

It runs on LLM Input and MCP Pre Tool, where it looks for injection inside tool parameters. To use your own vendor credentials, AWS Bedrock Guardrails does the same job - enable Prompt Attack, set the action to Block, register it:

LLM02: Sensitive Information Disclosure

Two built-ins cover most of this. PII / PHI Detection finds names, addresses, SSNs, and medical record numbers with configurable entity categories. Secrets Detection catches AWS keys, OpenAI and Anthropic API keys, GitHub and GitLab tokens, JWTs, private keys, database connection strings, and high-entropy strings near keywords like api_key.

Secrets Detection is the one to understand: it is the only built-in running on all four hooks, and each catches a different failure.

‍