Your Log Fields Are a Prompt Injection Channel

Bolting a language model onto alert triage is the most common AI project in security operations right now. Feed it the alert, feed it the surrounding logs, ask for a summary and a verdict. It demonstrably saves analyst time, which is why it spread so fast.

Here is the part that gets skipped in the demo. A large fraction of the fields in a security log are written by the attacker. The user agent is attacker-controlled. The requested URL is attacker-controlled. The DNS query, the attempted username, the POST body, the TLS SNI, the HTTP referer. When you paste that log into a prompt, you are not passing the model evidence about an intruder. You are passing the model text the intruder wrote.

What the research actually tested

A paper published on arXiv in May 2026, Poisoning the Watchtower: Prompt Injection Attacks Against LLM-Augmented Security Operations Through Adversarial Log Content by Rohan Pandey and Archit Bhujang, puts numbers on this. The authors build a four-class taxonomy of what they call log-substrate attacks and evaluate them against GPT-4o-mini.

• Direct override (S1). The log field simply contains an instruction telling the model to ignore what it was asked to do.
• Persona hijack (S2). The content reframes who the model is, so it answers as something other than an analyst assistant.
• Context manipulation (S3). The content reshapes the surrounding narrative so the model draws the attacker's preferred conclusion from real evidence.
• Obfuscated payloads (S4). The instruction is encoded or disguised to survive naive filtering.

The headline finding is that summarization is the highest-risk task, and context manipulation is the most effective class against it: 96% injection success with no defenses, falling to 38% even with constrained output. Across the whole evaluation, average injection success drops from 26.6% under naive prompting to 11.8% under the strongest defense the authors tested.

Two of those numbers matter more than the big one. First, 38% is what survives a real mitigation. Second, 11.8% is not zero, and it is the number you would be living with after doing the work.

Why summarization is the dangerous task

There is an intuition that summarization is the safe thing to hand an LLM. It is not making a decision, it is just condensing. That intuition is backwards here.

Summarization is dangerous precisely because its output is trusted and rarely re-checked. An analyst who reads "repeated failed logins from a known scanner, no successful authentication, low priority" is unlikely to go back and read the raw events. The summary is the analyst's picture of what happened. If attacker-controlled text can shape that picture, it does not need to defeat a detection rule. It only needs to make the human decide the detection was noise.

Note the persona hijack result as well: 68% suppression of malicious logs without defenses. Suppression is the outcome to care about. A model that hallucinates an extra alert wastes time. A model that quietly drops the one that mattered produces exactly the failure mode nobody notices until the post-incident review.

What this means if you are running an LLM in the SOC

This is not an argument against AI-assisted operations. It is an argument for treating log content as untrusted input to the model, which is the same discipline the industry already applies to log content as untrusted input to a parser or a web console.

• Separate evidence from instructions structurally. Pass fields as structured data with explicit boundaries rather than pasting raw log lines into the prompt body. The model should never have to infer where the evidence stops and the instruction starts.
• Constrain output. The paper shows it works, taking 96% down to 38%. Force a schema. A model that can only return a fixed set of fields has far less room to be redirected.
• Never let the summary be the only artifact. Keep raw events one click away and make it normal to look. If the summary is the sole basis for a disposition, injection converts directly into a missed intrusion.
• Watch for suppression, not just for wrong answers. Sample dispositions where the model recommended closure and check them against the raw events. Suppression is the class that hurts and it does not announce itself.
• Do not let the model take actions. Summarize and rank, yes. Isolate a host or close a case, no, not on a prompt whose inputs an attacker writes.

The uncomfortable framing is worth stating plainly. For twenty years the industry has told developers that concatenating attacker-controlled strings into an interpreter is the original sin, and built injection defenses accordingly. LLM-augmented triage does exactly that, with the security team's own logs as the payload, and the interpreter is a model that cannot reliably distinguish data from instruction.

Sources

Rohan Pandey and Archit Bhujang, "Poisoning the Watchtower: Prompt Injection Attacks Against LLM-Augmented Security Operations Through Adversarial Log Content", arXiv:2605.24421, submitted 23 May 2026. Figures cited above are from the authors' evaluation against GPT-4o-mini; results on other models may differ.