LLM Output Log Injection Prevention: Keeping Model Output Out of Your Logs and SIEM

Where model-generated text enters the logging pipeline

Prompts, model responses, tool call arguments, tool results, retrieved content and error messages commonly end up in application logs, audit trails and SIEM indexes. Teams often regard these as internal data because the application produced them. That assumption is the root problem.

OWASP defines log injection as untrusted data included in an application log message. Its example is an attacker injecting CRLF characters to create an additional entry that appears to come from a different user. OWASP also says event data from a different trust zone may be missing, modified, forged, replayed or malicious, and must always be treated as untrusted. Model output belongs in that category. Its content can be shaped by user prompts, retrieved documents and tool results, and prompt injection can steer it in ways the application owner did not intend.

Four categories of content matter for logging. The first is line and delimiter injection: CR, LF and field separators that split one record into several or shift field boundaries. OWASP references CWE-93 for CRLF injection in unstructured log formats and notes that some frameworks do not treat this as a vulnerability, so a library fix should not be assumed. The second is forged fields, where model text imitates keys, values or user identifiers inside a structured record. The third is control and escape sequences, such as ANSI codes, that can alter how terminal viewers display a line. The fourth is markup, script or instruction-like text that a dashboard may render or an automated consumer may interpret. OWASP's treatment of improper output handling lists XSS, CSRF, SSRF, privilege escalation and remote code execution as outcomes when model output reaches another system unvalidated. An LLM-assisted triage tool reading stored log text faces the same prompt injection problem as any other model reading untrusted data.

Where to apply each control, and what each placement costs

Controls can sit at several stages. The trade-offs below follow from how each stage works. Earlier placement protects more consumers but sees less context about how the data will be used. Later placement knows the destination but leaves every earlier stage exposed.

• Execution path: Acts on an individual interaction or tool call before content continues. Can allow, redact or block. Requires policy definitions and adds a step to the request path.
• Application logger: A structured encoder escapes values at write time. Closest to the source and cheap, but covers only the services that use it.
• Log shipper: One enforcement point for many services. It handles records that arrive already formed, so it cannot recover the original field intent.
• Parser or normalizer: Strict schema mapping rejects or quarantines malformed records. Overly permissive parsing can turn forged text into trusted fields.
• SIEM storage and dashboards: Output encoding at render time stops script and markup effects. It does not change what rules and searches see in the stored text.
• SOAR and LLM-based assistants: Treat log text as data, not instructions, and limit what automation can do. OWASP notes that filtering reduces but does not eliminate prompt injection.

Runtime enforcement compared with after-the-fact review

Encoding and schema validation protect the integrity of the log format. They do not decide whether a given output should have been produced, returned or acted on. A sanitized record of a harmful tool call is still a record of a harmful tool call.

Reviewing logs after the fact has two limits. First, the raw record is only as trustworthy as the path that wrote it, and a log containing unfiltered model output can itself contain forged or altered content, which weakens its value as evidence. Second, review happens after the output has already reached users, tools and downstream systems. Enforcement in the execution path acts on the individual interaction or tool call before that point. The decision is allow, redact or block, and the decision itself is recorded alongside what was acted on and why. That record describes what the control did, which is a stronger basis for an investigation than a transcript of unfiltered text.

This does not replace pipeline-level controls. OWASP is explicit that input and output validation reduce the attack surface without eliminating it, and that pattern-based filters can miss indirect injection. Keep encoding and schema validation in the pipeline as the layer that still works when a policy misses something. Add privilege minimization and human confirmation for high-risk actions, which OWASP describes as checkpoints injection alone cannot bypass. Document the residual risk you accept.

There is also a tension to resolve deliberately. Data minimization works against forensic completeness. If you retain raw content for investigations, record the justification, restrict access, and treat the store as holding untrusted text.

Practical next steps

Begin with the inventory, because it shows which of the stages above you actually operate. Fix the logger first by moving to structured output with an escaping encoder, then tighten parsing so forged fields are rejected rather than normalized. Decide which interactions and tool calls warrant enforcement in the execution path, usually those that call external systems, write data or feed automated response. Then check what your SIEM dashboards render and what your detection and assistant tooling treats as instructions.

Trussed has run continuously in production at a regulated enterprise for over 18 months, with customers across insurance, pharma, healthcare and education. If you are weighing enforcement in the execution path against pipeline-only controls, the evaluation criteria above are a reasonable basis for a technical conversation.