The controls that work for LLM05 improper output handling are the ones you already use for untrusted user input: validate, encode for the destination, parameterize queries and limit what downstream code may do. Asking the model politely to behave is not a control, because the output can be shaped by whoever controls the prompt.
OWASP defines the risk as insufficient validation, sanitization and handling of LLM outputs before they are passed to other components. This post sorts the controls into those that hold and those that only feel safe. It is defensive and uses no working payloads.
Why is this a separate risk from prompt injection?
Prompt injection is about getting bad instructions into the model. Improper output handling is about what your application does with the answer. OWASP notes that since LLM content can be controlled by prompt input, passing it unchecked to another component "effectively" gives users indirect access to extra functionality. The result can be XSS, CSRF, SSRF, privilege escalation or remote code execution.
It also differs from overreliance, which concerns trusting the accuracy of outputs. Here the concern is safe handling even when the output is perfectly on topic.
Where does it go wrong?
OWASP lists five common patterns:
- Output passed to a shell or to functions such as exec or eval.
- Generated JavaScript or Markdown rendered by a browser.
- Generated SQL run without parameterization.
- Output used to build file paths without sanitization.
- Output placed in email templates without escaping.
Its scenarios include a summarizer that processes a page containing hidden instructions, and a chat feature that turns a request into SQL that is executed without review. Note the last scenario: code generated by a model may introduce injection flaws or suggest packages that do not exist, which an attacker could register.
Which controls work?
- Zero trust for the model. OWASP says to treat the model as any other user and validate responses before they reach backend functions.
- Context aware output encoding. HTML encoding for web content, SQL escaping for queries. Encode before output reaches a user, to stop JavaScript or Markdown from executing.
- Parameterized queries. For every database operation involving model output, use prepared statements. The model supplies values, never query structure.
- Strict Content Security Policy. It reduces the damage if something slips through into a page.
- Least privilege. The tool or extension the model calls should hold only the rights it needs, and sensitive actions should need human confirmation.
- Logging and monitoring. OWASP recommends monitoring outputs for unusual patterns.
- Schema validation. If the output should be a number or one of five enum values, parse it as that and reject anything else.
Which controls do not work on their own?
- System prompt instructions. "Never output HTML" is a request, not enforcement.
- Keyword blocklists. Encodings and alternate spellings get around them, so they are at best a signal for logging.
- Asking a second model whether the first answer is safe. It can be useful as an extra signal, but it is the same kind of component with the same weakness. Do not let it replace deterministic checks.
- Trusting the model because it is internal. The input to that model may not be.
This is judgment drawn from the OWASP guidance, which puts its weight on validation, encoding and parameterization.
What to do
- Map every place model output flows: browser, database, shell, file system, email, other services.
- For each destination, choose the encoding or parsing rule and apply it in code.
- Replace string built SQL and shell commands with parameterized or argument list forms.
- Remove exec and eval from any path model output can reach.
- Cut the privileges of every tool the model can call, and gate destructive actions.
- Add a Content Security Policy to pages that render model output.
- Log output and tool calls so you can investigate.
- Test with your own security team using inputs that try to break each destination, in a staging environment.
Quick check
Is output filtering enough?
No. Filtering helps, but OWASP's core advice is validation, destination specific encoding and parameterized queries.
Does this apply to generated code?
Yes. OWASP notes generated code can expose data, introduce SQL injection or suggest nonexistent packages, so review and scan it like any other code.
Sources
Last reviewed: 18 October 2026.
