OWASP LLM05: Improper Output Handling (Formerly LLM02): Enterprise Guide

Most enterprise application security programmes are set up to defend against user-supplied input. LLM-integrated applications introduce a second, harder-to-see input source: the model's own output. OWASP LLM05:2025 Improper Output Handling — renamed from LLM02:2023 Insecure Output Handling — is the risk class that covers what happens when the enterprise trusts that second source enough to pass it downstream without sanitisation. It is the risk class most often responsible for turning a prompt-injection incident into a real breach.

The 2023 → 2025 Taxonomy Shift

If you are working from OWASP LLM Top 10 documentation from 2023 or 2024, the risk is called LLM02: Insecure Output Handling. In the 2025 edition it was renamed and renumbered:

• LLM01:2025 — Prompt Injection (unchanged in position)
• LLM02:2025 — Sensitive Information Disclosure (new occupant of slot LLM02)
• LLM03:2025 — Supply Chain
• LLM04:2025 — Data and Model Poisoning
• LLM05:2025 — Improper Output Handling (renamed from Insecure Output Handling, moved from LLM02)
• LLM06:2025 — Excessive Agency
• LLM07:2025 — System Prompt Leakage
• LLM08:2025 — Vector and Embedding Weaknesses
• LLM09:2025 — Misinformation
• LLM10:2025 — Unbounded Consumption

Two practical implications. First: if your policy or SOC 2 evidence references "LLM02 Insecure Output Handling", update the language — that risk is now LLM05:2025 Improper Output Handling. Second: the newly-arrived LLM02:2025 (Sensitive Information Disclosure) is a different risk — model output revealing PII, credentials, or training data — and needs its own controls independently of LLM05.

What LLM05 Actually Is

OWASP's definition: "insufficient validation, sanitization, and handling of the outputs generated by large language models before they are passed downstream to other components and systems." Parsed carefully:

• "Outputs generated by large language models" — any string the model produces, whether it is displayed to a user, consumed by a tool, or interpolated into another system's input.
• "Passed downstream to other components and systems" — the failure is in what happens after the model returns text. A model that produces a string like <script>alert('xss')</script> has done nothing wrong; the LLM05 defect is if the enterprise's application then puts that string inside an HTML page without escaping it.
• "Insufficient validation, sanitization, and handling" — the enterprise's downstream code assumed the string was safe. It was not.

The vulnerability is not in the model. It is in the application code that trusts the model's output the same way it might trust its own generated content — and the same way a decade of security engineering has trained developers not to trust user-supplied strings.

Why LLM05 Is What Turns Prompt Injection into a Real Breach

Prompt injection (LLM01) is the trigger. LLM05 is the amplifier. Consider the failure chains in the most-cited enterprise incidents:

• CVE-2025-32711 (EchoLeak) — Microsoft 365 Copilot, June 2025. Prompt injection via HTML-commented instructions inside a retrieved email caused Copilot to construct an image URL pointing to an attacker-controlled endpoint. The exfiltration channel was Copilot's rendering of the image URL — a downstream URL-fetch operation on model output that lacked destination allow-listing. The LLM05 defect: output containing a URL was passed to a network fetcher without egress validation. Our prompt-injection enterprise guide covers the full incident.
• Rendered-HTML incidents. Any LLM-integrated product that renders model output as HTML — chatbots showing formatted responses, agent products rendering intermediate steps, docs assistants pasting model output into rich text editors — is vulnerable to XSS if that rendering does not sanitise. An attacker-influenced prompt yields attacker-influenced HTML; the enterprise's renderer executes it.
• Command execution via tool calls. Agent frameworks that let a model construct shell commands, SQL queries, or code to execute have LLM05 exposure at every hop where the model's output becomes an interpreter's input. RCE via crafted model output is a documented attack pattern in the 2024–2026 red-team literature.
• SSRF via constructed URLs. Where a model constructs a URL that the application then fetches (for retrieval, for verification, for rendering), the model can be prompted to construct URLs to internal cloud metadata endpoints (the AWS instance-metadata IP 169.254.169.254, or the GCP metadata.google.internal hostname), to internal services, or to attacker-controlled destinations for data exfiltration.

The pattern in each case is the same: the model produced attacker-influenced output, and the enterprise's application passed it to a downstream system without treating it as untrusted.

The Defence: Treat LLM Output as User Input

The mitigation is one sentence and every downstream integration point should implement it: every LLM output is untrusted user-supplied input. Apply the exact same downstream sanitisation the enterprise already applies to any string that entered the system through a form field, an API parameter, or a request body. In practice:

• HTML rendering — output-encode before displaying. Use a Content-Security-Policy that blocks inline script execution. Never innerHTML; always safe DOM APIs.
• URL construction and fetching — allow-list destinations. Block internal IPs and metadata endpoints. Log every model-constructed URL that gets fetched.
• Database queries — never string-interpolate model output into SQL. Use parameterised queries. If the model must produce query fragments, produce structured JSON that your code translates to safe queries, not raw SQL.
• Shell commands and code execution — do not interpolate model output into shell strings. If code execution is a legitimate feature (a code-interpreter product, for instance), sandbox it — a fresh container per invocation, minimal permissions, no network egress by default.
• File paths — validate against a fixed allow-list of directories. Never let the model produce paths that traverse out of a designated workspace.
• Downstream tool invocations — where the model decides which tool to call and with what arguments, validate the arguments against the tool's schema before invocation. Reject arguments that fall outside expected ranges.

The Agentic Case Is Harder

The controls above are straightforward for a single-turn chatbot. They are dramatically harder for a multi-step agent, because every intermediate step introduces a new LLM05 surface. Consider an agent that:

1. 1Reads a customer request (external input — untrusted).
2. 2Retrieves a document (external input — untrusted).
3. 3Calls a database tool (model output → tool input — LLM05 surface).
4. 4Reads the tool result (external input — untrusted).
5. 5Calls a URL fetcher (model output → tool input — LLM05 surface).
6. 6Reads the fetched content (external input — untrusted).
7. 7Composes a final response for the user (model output → HTML renderer — LLM05 surface).

Every hop where model output becomes tool input is an LLM05 surface. Every hop where external content becomes model context is a prompt-injection surface. The composite risk is not additive; it is multiplicative, because a prompt injection at step 2 can influence tool calls at steps 3 and 5 and the final output at step 7.

Testing regimes that only evaluate the final user-visible response miss the interior surface entirely. Red-teaming an agent, per the framework in our AI red teaming enterprise guide, needs to instrument and inspect every intermediate hop.

Where LLM05 Sits in a Governance Framework

For enterprise leaders mapping OWASP LLM Top 10 items into their governance frameworks:

• Under NIST AI RMF — LLM05 belongs in the MEASURE function (measuring output-handling controls) with MANAGE-function tracking of remediation.
• Under ISO/IEC 42001 — LLM05 belongs in the technical controls under Annex A operation, with evidence requirements around output-sanitisation testing and code review of downstream integration points.
• Under EU AI Act — for high-risk AI systems, an LLM05 vulnerability that could result in harm to health, safety, or fundamental rights is a defect requiring notification under the Act's post-market monitoring obligations.

What Leaders Should Be Asking

• For each production LLM-integrated application, list every downstream sink for model output. HTML renderers, URL fetchers, database calls, shell commands, tool invocations, file operations. Anywhere model output becomes another system's input.
• For each sink, describe the sanitisation applied. If the answer is "we trust the model output" the sink is an LLM05 defect regardless of what OWASP category number is fashionable this year.
• For agentic workloads: what is the interior surface, and how is it tested? Instrumentation of tool-call arguments and tool-call results is now table stakes for any agent product an enterprise operates.
• How does the security team's existing input-validation review process cover LLM output as an input source? In most enterprises, application security reviews are wired to check inputs from users and integrations, not from models. That gap needs to close.

The Underlying Point

Improper Output Handling is the least glamorous item on the OWASP LLM Top 10 and the one most often responsible for the difference between "the model said something odd" and "we have a data breach". The rename from LLM02:2023 to LLM05:2025 has confused documentation, not the underlying risk. The controls have not changed: treat every model output as untrusted user input, apply the sanitisation the enterprise already applies to any other user input, and instrument the interior of agentic workloads so the sanitisation actually runs where the risk lives.