How to Map OWASP LLM Risks to Concrete Controls in Your Stack

OWASP publishes a list of risks, not an implementation plan. The 2025 series gives each risk a definition, examples and prevention strategies (OWASP Top 10 for LLM Applications), and the project overall has grown into the broader GenAI Security Project with a dedicated 2026 edition that maps risks to NIST, MITRE ATLAS, CWE and the OWASP Top 10 for Agentic Applications (OWASP GenAI LLM Top 10 2026, OWASP project page). None of that tells you where in your stack to put the check.

The loop below does. Run it once per risk, per call site where the risk applies.

Step 1: pick one risk and one row from the register. "LLM01 prompt injection" across the whole product is not a work item. "LLM01 against the support chatbot that ingests user-uploaded PDFs" is.

Step 2: choose the enforcement layer. Three layers matter: input handling (constrain what reaches the model), output filtering (constrain what leaves it) and access scoping (constrain what the model can do even when it is fully compromised). The rule of thumb: if the harm happens when text enters the context, the control belongs at input. If the harm happens when text leaves, it belongs at output. If the harm happens because a tool executes, it belongs in permissions, and no amount of prompt wording substitutes. Practitioner testing of guardrails across client deployments found regex input filters catch roughly 60 to 70 percent of injection attempts, LLM-based classifiers catch 89 to 94 percent, and combining both with output validation reaches about 99.1 percent, while system prompt instructions alone fail against deliberate adversarial input (guardrail measurements). Those numbers come from one vendor's four projects, so treat them as a shape, not a benchmark. The shape is what matters: layered controls, none perfect, each covering the previous one's misses.

Step 3: write the control as an assertion a machine can check. "Validate inputs" is not a control. "Reject any request body over 32 KB before tokenization; log the rejection with request ID" is.

Step 4: name an owner and a test. The owner is a person, not a team. The test is a script, a red-team case, a log query or a policy check in CI, and it has a pass threshold.

Step 5: record it on the one-page map. Risk, call site, layer, control, owner, test, status. Ten risks by however many call sites you have. If the map exceeds a page per product surface, you are documenting prose again.

Repeat until each risk has at least one control on the surface where it is enforceable. Some risks need two or three. That is expected.

Input handling is the cheapest layer and the one teams over-trust, because it feels like the familiar web-application boundary. Use it for what it genuinely stops.

Length and shape caps. Reject or truncate oversized inputs before tokenization. OWASP lists variable-length input floods and continuous input overflow as unbounded-consumption examples, and its first mitigation is strict input validation against reasonable size limits (OWASP LLM10). This is also a cost control: a 2 MB prompt costs money before it costs availability.

Encoding and structure checks. If an endpoint expects JSON, validate the schema and reject anything else. Markdown, HTML and base64 in a field that should hold a question are signals worth logging even when you let them through.

Source labeling. For indirect injection, the practical input control is provenance. Wrap retrieved web content, file extracts and tool output in delimiters that name the source, and strip invisible or formatting-hidden text at ingestion. OWASP's vector weakness entry documents exactly this attack, a resume with white-on-white instructions that says to recommend the candidate, passing through extraction into the knowledge base and being followed at query time (OWASP LLM08). The fix is extraction that ignores formatting and detection of hidden content before ingestion.

Allowlists, not blocklists, where the domain permits. A field that must contain one of twelve ticket categories should reject a novel value, not sanitize it. Blocklists of injection phrases are the weakest form: one practitioner writeup shows regex patterns like "ignore previous instructions" and "pretend you" catching low-effort attempts while the remainder use indirect phrasing, multi-turn buildup or encoding tricks (pattern examples).

What input handling cannot do is stop a determined attacker. A prompt-injection attempt can be a perfectly ordinary sentence. Treat input controls as signal collection and resource protection, and place the actual harm prevention downstream.

The most common mistake here is applying the same filtering philosophy to inputs and outputs. Aggressive input filtering can strip the domain terms, code or quoted material the model needs to answer correctly, while some failures only appear after generation (input versus output filtering). Match the control to the trust boundary it protects.

Output filtering is where most of the value sits for disclosure, improper handling and misinformation risks, and it is where false positives bite hardest. The same practitioner measurements note that the worst production failures came from output guardrails that were too aggressive, not too permissive, because blocking legitimate queries destroys trust faster than an occasional bad answer (guardrail measurements). Design for a measured false-positive rate and a review queue, not a hard block on everything uncertain.

Four output controls cover most needs:

Schema validation. If the model must return JSON for a downstream service, validate against a strict schema, reject unknown fields and retry once, then fail. This is the direct control for improper output handling, where unchecked model output reaches another system and causes cross-site scripting, request forgery or command execution (OWASP risk overview). Cloudflare's guidance for the same risk is simply to treat the model like any untrusted user or device under a zero trust model, and validate output before it drives anything.

Encoding for the destination. Model output rendered into HTML gets encoded, output passed to SQL goes through parameterized queries, output passed to a shell never goes to a shell.

PII redaction and disclosure checks. Run a detector for account numbers, identifiers, credentials and personal data on the response before it leaves. This backs up LLM02, sensitive information disclosure, which covers PII, financial details, health records, confidential business data and credentials appearing in output (OWASP LLM02). Note OWASP's own caveat that system prompt restrictions on returning sensitive data may not be honored and can be bypassed, which is why the check has to be code.

Groundedness and action gating. For answers that drive decisions, require citations to retrieved sources and refuse when none exist. For anything that triggers a transaction, require human confirmation. Misinformation is a risk because credible-looking wrong output gets acted on, so the output layer is also where you gate the action.

A worked example makes the tradeoff concrete. Suppose your disclosure detector flags candidates on name plus account-number patterns. On a support corpus where 3 percent of legitimate answers quote a masked account reference, a naive block rule will reject 3 in 100 good answers. Tune the detector to require full, unmasked number formats plus a second identifier, and route the residual to a review queue with a 2 percent threshold before escalation. You get almost all the risk reduction without strangling the product.

Output filters need the same governance as any security control: versioned, with logged trigger rates, reviewed when the rate moves. The NHI guidance on validation and filtering urges teams to standardize where validation happens and monitor how often filters fire, because guard logic spread across ad hoc code paths drifts and becomes un-auditable (filtering governance).

Assume input and output controls fail on a bad day. Access scoping is what makes that day boring. It covers excessive agency, the parts of disclosure that come from over-broad reads, and vector cross-tenant leakage.

Per-tool credentials. Each tool gets its own identity with the minimum permissions its job needs. The document reader gets read on the user's documents, not read on the whole repository. OWASP's excessive agency entry lists the over-privileged-database-identity pattern first among its permission examples (OWASP LLM06).

Per-user data boundaries. Tools that act "for" a user must act as that user, not through a shared service account. This is the same entry's fifth example: an extension scoped to read the current user's document store that actually connects with a privileged account holding everyone's files. The fix is credential-per-user or, where that is impractical, mandatory row-level filters applied in the retrieval code, not the prompt.

Least-privilege API keys. Provider keys are often shared across teams, which erases individual accountability (LLM access control). Issue one key per person or service, cap spend per key, and rotate on schedule.

Task-scoped authorization. Research on a least-privilege framework for tool-calling agents proposes authorizing an agent through a role for the current task rather than a flat list of permanently granted tool permissions, and reports that this approach cut simulated permission confirmations by 43.4 to 89.4 percent versus per-tool prompting while mitigating privilege-escalation attacks (MiniScope paper). The paper is a design reference, not a product recommendation, but the decision rule is portable: grant the permissions the task needs, and for high-impact actions require explicit approval or a role that expires with the task.

Tenant partitioning in vector stores. Shared vector databases without strict logical partitioning leak embeddings across tenants, and embeddings are not inherently anonymized, so inversion can reconstruct source text (OWASP LLM08). A practical summary of the same risk lists permission-aware vector databases, dataset partitioning and classification tags as the mitigations (RAG security overview). Check for the query-time filter: if a retrieval query does not include the tenant or user identifier as a mandatory predicate, the control is missing regardless of what the schema says.

A checklist for the scoping review:

The map is the deliverable that turns ten risks into ten work items with names on them. Keep it to one page per product surface and one row per control.

Risk | Call site        | Layer     | Control (assertion)                   | Owner    | Test                        | Status
LLM01| chat.support     | output    | Refuse actions w/o user confirm        | A. Patel | case inj-07 blocks send      | pass
LLM02| report.summarize | output    | Redact acct numbers + 2nd identifier   | R. Okafor| sample set FPR < 2%          | open
LLM06| agent.inbox      | access    | Read-only mailbox token per user       | A. Patel | attempt delete returns 403   | pass
LLM08| rag.docs         | access    | Tenant filter mandatory in retrieval   | M. Chen  | cross-tenant query returns 0 | open
LLM10| all endpoints    | input     | 32 KB body cap, 429 over quota         | R. Okafor| load test: 0 5xx under flood | pass

Two conventions make the map durable. First, pin the edition: the 2025 list and the 2026 list use different numbers and, in the 2026 edition, prompt injection moves to a different position and hidden context exposure replaces system prompt leakage in the numbering, with new risks such as misinformation and unbounded consumption also reordered (comparison of editions). Record which edition you mapped against and when you will re-check. Second, keep the test column executable. A status of "pass" should mean someone can rerun the test.

Coverage rule: every risk in your chosen edition gets either a control row or a written, signed acceptance of the residual. Silence is not acceptance.

If the mapping exercise shows you have one team owning every layer, or that identity plumbing for tools does not exist yet, that is a good point to get an outside read on sequencing. A free 30-minute discovery call is a reasonable place to pressure-test your map against someone who has built the same layers.