LLM05 improper output handling: what to log and alert on

For OWASP LLM05, improper output handling, log every point where model output crosses into another system, record whether validation passed, and alert on rejections and unusual patterns. The risk is not the model's words. It is what your code does with them: render, query, execute or forward.

What does LLM05 actually say?

OWASP defines improper output handling as insufficient validation, sanitization and handling of model outputs before they are passed to other components. Because model output can be steered by prompt input, OWASP says this is similar to giving users indirect access to extra functionality. Consequences it lists include cross site scripting and request forgery in browsers, and server side request forgery, privilege escalation or remote code execution in backends.

OWASP also names conditions that raise impact. Two are about visibility: "insufficient monitoring and logging of LLM outputs" and "absence of rate limiting or anomaly detection for LLM usage". This article is about those two.

Where are the handoffs?

Draw them before you log anything. In a typical application, model output goes to one or more of these sinks:

• A browser, as text, Markdown or HTML.
• A database, as a query or a filter value.
• A shell, interpreter or file path builder.
• An API or tool call with arguments the model chose.
• An email or message template.
• Another model, in a multi step agent.

Each sink has a different failure and a different log line.

What to log

For each handoff, record fields that let you reconstruct the event without storing more sensitive text than you need.

• A request identifier that ties the user input, model call and sink together.
• The sink name and the context it expected (HTML, SQL parameter, file path, tool argument).
• The validation or encoding step applied, and its result: passed, modified, or rejected.
• For modified output, a count of what was changed, not necessarily the content.
• For tool calls, the tool name, the argument schema check result, and the identity the call ran as.
• A hash and length of the raw model output, with the full text kept under access control for a short, defined period.
• The model, version and system prompt version in use.

Redact personal data before it reaches general logs. Logs of model output can contain whatever users typed.

What to alert on

OWASP recommends logging and monitoring to detect unusual patterns in output. Practical alert rules follow from that:

• Any rejection by an output validator, as a rate against baseline.
• Output that reaches a sink with a context mismatch, for example free text arriving where a number was expected.
• Tool calls with arguments that fail schema checks, or tools the user's role should not reach.
• A sudden rise in output length, or in links and file paths inside output.
• Browser content security policy violation reports from pages that render model output.
• Parameterized query errors on code paths fed by a model.
• A single user or session triggering many rejections.

Start with counts and ratios. Tune after a month of data, so alerts reflect your traffic.

Prevention still comes first

Logging detects. It does not replace controls. OWASP's mitigations are to treat the model as any other user with a zero trust approach, validate what comes back, use context aware output encoding, use parameterized queries for anything involving model output, and apply a strict content security policy. It points to the OWASP ASVS for validation and encoding guidance.

What to do

1. Map every sink that receives model output, including other models.
2. Add a validation step per sink with an explicit context, and log pass, modify and reject.
3. Give tool calls the least privilege identity and check arguments against a schema.
4. Turn on content security policy reporting for pages that render model output.
5. Create alerts on rejection rate, schema failures and output size shifts.
6. Set a retention period for raw output and restrict who can read it.
7. Review a sample of rejections weekly and feed what you learn back into validators.

Quick check

Sources

• OWASP Top 10 for LLM Applications, LLM05:2025 Improper Output Handling
• OWASP Application Security Verification Standard

Last reviewed: 18 October 2026.