Match each OWASP LLM Top 10 risk to the control that addresses it

Match pairs·Medium·4.0 · 0·~2 min·Asked atForethought Lambda Labs Stripe

Attempt it

Drag each answer to line up with its matching prompt

LLM01 prompt injection

Rate limiting, query throttling, and watermarking on hosted endpoints

LLM05 improper output handling

Input rail with injection classifier plus quarantined processor pattern

LLM02 sensitive information disclosure

PII redaction on input and output, prompt cache scrubbing

LLM06 excessive agency

Output schema validation and parameterised calls to downstream systems

LLM09 misinformation

Citation required output rails and confidence display in the UI

LLM10 unbounded consumption

Tool allowlist, argument validation, human confirmation on irreversible actions

The **OWASP Top 10 for LLM Applications** lists the most consequential security risks in LLM applications. Each risk has a canonical control that targets it directly: - **LLM01 (prompt injection):** an attacker's text overrides the system prompt. Control: input rails with injection classifiers (Llama Prompt Guard, Lakera, Microsoft Prompt Shields) plus the dual-LLM pattern when external content meets tool use. - **LLM02 (sensitive information disclosure):** the model leaks PII, secrets or proprietary data. Control: PII redaction on input and output, plus scrubbing of prompt caches and embedding stores. - **LLM05 (improper output handling):** downstream systems run model output as code, SQL or HTML. Control: schema validation before use and parameterised queries; never concatenate output into shell commands or SQL. - **LLM06 (excessive agency):** the agent calls tools it should not, with arguments it should not pass. Control: tool allowlist, argument validation and human confirmation on irreversible actions. - **LLM09 (misinformation):** users trust wrong output without checking (overreliance). Control: citation-required output rails and confidence display. - **LLM10 (unbounded consumption):** attackers flood the service, run up cost, or query it to clone the model. Control: rate limiting, query throttling, watermarking and extraction detection.

**Each risk in the OWASP Top 10 for LLM Applications maps to a specific class of control.** Pairing them correctly builds defence in depth instead of a single-classifier deployment. **LLM01 (prompt injection).** Direct injection comes in the user message. Indirect injection arrives through retrieved content. Controls are layered: **input rails** (Llama Prompt Guard, Lakera Guard) at the edge, **retrieval rails** on untrusted documents, and the **dual-LLM (quarantined processor)** pattern, which keeps the tool-calling model away from untrusted content. **LLM02 (sensitive information disclosure)** covers PII, secrets and proprietary data. Controls: **PII redaction** on input (Presidio, custom regex) and output, **cache scrubbing**, and access control on retrieval. **LLM05 (improper output handling)** is about what happens *after* the model emits. Output concatenated into SQL, shell, HTML or an API call can exploit the downstream system. Controls: **output schema validation**, **parameterised queries**, and treating model output as untrusted user input. **LLM06 (excessive agency).** The model has tools, the tools have power, and the model can be tricked into using that power. Controls: **tool allowlist**, **argument validation** and **human confirmation** on irreversible actions. **LLM09 (misinformation)** includes overreliance: users acting on wrong output without checking. Controls: **citation-required output rails** and **confidence display** in the UI. **LLM10 (unbounded consumption)** covers denial of service, runaway cost and model extraction through the API. Controls: **rate limiting**, **query throttling** and **output watermarking**.

TL;DR

Six OWASP LLM risks pair with six controls: input rail plus dual-LLM (LLM01), PII redaction (LLM02), output validation (LLM05), tool gating (LLM06), citations (LLM09), rate limits (LLM10).

Memory aid

Easy to grasp

Think of a list of common kitchen accidents and the right safety device for each. Cut yourself when chopping? Use a sharp knife and a guard. Burn yourself on a hot pan? Wear oven mitts. Poison the dish because the chef trusted a spoiled ingredient? Smell and taste it before serving. Eat raw eggs and get sick? Cook properly. Someone steals your secret recipe? Lock the recipe book. Each accident has a matching safety device that targets that specific risk. Mixing them up means using oven mitts to prevent food poisoning. The OWASP LLM Top 10 works the same way: ten common threats, each paired with the canonical control that addresses it directly.

Key concepts

Safety & Guardrails

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

The OWASP Top 10 for Large Language Model Applications is the industry-standard threat taxonomy for LLM security. Treating it as a checklist where each item has a canonical control is the basis of any disciplined safety review. The common failure mode is to deploy one classifier (say, an input safety filter) and assume it addresses multiple items. It does not. Each item has its own structural defence at its own layer.

The OWASP Top 10 is a threat-model catalogue. The matching controls are the defence-in-depth playbook. Each item has one canonical control, and production stacks deploy all of them.

LLM01 prompt injection and LLM05 improper output handling

LLM01: where the injection comes from

Direct injection arrives in the user message. Indirect injection arrives in retrieved content (documents, webpages, emails, tool outputs). They share a name because the underlying mechanism (adversarial text that hijacks the model's behaviour) is the same, but the attack surface is different.

LLM01 control: layered defence

The canonical control combines two layers:

Input rail (Llama Prompt Guard, Lakera Guard, Microsoft Prompt Shields). It catches the obvious direct-injection patterns at the edge. It is cheap and fast, and runs on every request.
Retrieval rail (strip instruction tokens from documents, drop unauthorised retrievals) plus dual-LLM / quarantined processor pattern (the tool-calling model never reads untrusted content directly). Together they close the indirect-injection gap that filtering alone cannot cover.

A team that deploys only one of these is exposed on the other vector. Both are mandatory for agentic stacks that touch external content.

LLM05: the downstream trust problem

LLM05 is misunderstood as 'unsafe content in the response'. It is not. LLM05 is about what downstream code does with the model's output. If the response is concatenated into a SQL query, executed as shell, parsed as JSON without validation, rendered as raw HTML, or fed into another API as a parameter, the model has become a code-execution channel.

LLM05 control: treat the model as untrusted

The canonical control is to apply the same security hygiene you would to any user-supplied input:

Validate output against a strict schema (Zod, Pydantic, JSON Schema with additionalProperties: false).
Use parameterised queries for any database call constructed from model output.
Escape for the target sink (HTML encode, SQL escape, shell quote).
Never eval model output and never let it directly drive system-level actions without an intermediate validated representation.

This is downstream-code hygiene more than LLM-specific safety. A team that ships an LLM product without this discipline is one prompt-injection away from a full SQL-injection-class incident.

LLM02 sensitive information disclosure and LLM06 excessive agency

LLM09 misinformation and LLM10 unbounded consumption

Composition with NeMo's five-rail decomposition and operational priority

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

The OWASP GenAI Security Project publishes the Top 10 for LLM Applications 2025 with prevention and mitigation strategies for each entry.
Amazon Bedrock Guardrails bundles controls for several entries: a prompt-attack filter (LLM01), sensitive information filters with PII masking (LLM02) and contextual grounding checks (LLM09).

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does the OWASP Top 10 map onto NeMo Guardrails' five rail types?

LLM01 (direct) → input rail; LLM01 (indirect) → retrieval rail; LLM02 → input and output rails plus prompt-cache isolation; LLM05 → output rail with schema validation plus downstream code hygiene; LLM06 → execution rail with allowlist and confirmation; LLM09 → output rail plus product UX. The rail decomposition gives an architectural surface for each item.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Picking a generic control (an input filter) and assuming it addresses multiple OWASP items. Each item has a specific defence. Using one control for all of them breaks the defence-in-depth model.

60 second bullets to scan on the way to the call.

The six OWASP items in the mapping and their canonical controls
Why LLM01 needs both input rail and dual-LLM

Primary sources. Browse if you want the original framing.