OWASP LLM05, improper output handling, is the failure to validate and sanitize what a language model produces before another system uses it. The fix is simple to say: treat model output like untrusted user input. The example below is a composite built for teaching, not a report of a real breach.
What does OWASP say?
OWASP's 2025 entry describes it as insufficient validation, sanitization and handling of model outputs before they reach other components. Because user prompts can influence output, it is like giving users indirect access to additional functionality. Consequences it lists include cross-site scripting, request forgery, server-side request forgery, privilege escalation and remote code execution. Risk rises when the model has excess privileges, is exposed to indirect prompt injection, works with third-party extensions that do not validate inputs, or lacks monitoring.
A worked example
A team adds a chat feature to an internal reporting tool. Users ask questions in plain language, the model writes a SQL query, and the app runs it and shows the answer.
The flaw. The app runs whatever SQL the model returns, using a database account that can write and delete. OWASP lists this pattern directly: LLM-written SQL run without parameterization, and one attack scenario where a chat-driven SQL feature produces a query that deletes tables when a user asks.
How it goes wrong. A user, or text the model read from a document, asks it to "clean up old records". The model returns a delete statement. The app runs it. Nothing in the system checked the output.
The same shape elsewhere. A model reply rendered as HTML runs a script in the browser. A model's file name builds a path that escapes its folder. Output goes to a shell. OWASP's examples cover each.
How do you fix it?
Apply OWASP's mitigations in layers.
- Zero trust for the model. Validate responses before they reach backend functions.
- Least privilege. Give the database account read-only access to the views the feature needs. Then even a bad query cannot delete.
- Constrain the output. Ask for a structured request, such as a report name and filters, and build the query yourself with parameterized statements instead of executing model-written SQL.
- Encode for context. HTML-encode text for web pages, escape for SQL, and never concatenate model output into shell commands.
- Content Security Policy. A strict policy reduces damage from generated scripts in the browser.
- Monitor. Log model outputs and the actions they trigger so you can spot patterns.
- Human approval. For anything that changes data, require confirmation.
What about AI-written code and packages?
OWASP's scenario list also includes AI-generated code that introduces insecure data handling or references hallucinated packages that may be malicious. Treat generated code as untrusted: review it, run code and dependency scanning, and check that every package exists and is the one you intended. Safeguard's CLI and IDE extensions can flag risky dependencies as you code.
What to do
- List every place model output feeds another system: databases, browsers, shells, files, emails, APIs.
- For each, add validation and context-aware encoding.
- Reduce privileges so a bad output cannot do harm.
- Replace model-written queries with parameterized queries built by your code.
- Add logging for outputs and triggered actions.
- Scan code and packages that models suggest before merging.
Quick check
Is improper output handling the same as prompt injection?
No. Prompt injection manipulates what the model produces. Improper output handling is what your system does with that output. They combine badly, but the second is fixed in your code.
Does a safer model solve it?
No. Any model can produce unexpected output, so validate output regardless of the model.
Sources
Last reviewed: 18 October 2026.
