Log poisoning: adversarial log lines hijack LLM security-ops pipelines 96% of the time

A preprint posted to arXiv as 2605.24421 and picked up in security briefings on July 30 puts a number on something most teams running LLMs in security operations already suspected. Adversarially crafted log content achieves up to 96% prompt-injection success against LLM-augmented security-ops workflows, and 38% even when the model's output is constrained. The attack surface is the log line, the victim is the summary or alert the model writes from it, and the person who acts on the poisoned summary is your SOC analyst.

What the paper measured

The setup is the pattern every SOC, SIEM and SOAR vendor is shipping this year: an LLM reads raw or lightly parsed logs, produces a summary, a triage recommendation or an alert, and a human or an automation acts on the result. The attacker controls some of the log content, which is trivially true for anything that logs user-supplied strings: user agents, usernames, HTTP paths, error messages, file names, DNS labels.

The paper reports that crafted lines in that stream can hijack the model's task, up to 96% of the time in the unconstrained case. Constraining output, for example forcing a fixed schema or a limited set of verdicts, cuts that to 38%, a real reduction and still a catastrophic number for an unattended control.

Why the pipeline is blind

The right diagnosis is that these pipelines are provenance-blind. Classic log tooling was built to parse, index and correlate. It never had to answer the question "is this string trying to talk to the reader", because the reader was a regex. Once the reader is a model, every field an outsider can write into becomes an instruction channel, and nothing in the pipeline tracks where a given token came from.

This is the same failure I described in prompt injection through a smart home, moved into the one environment where the consequences are worst. A poisoned summary does not just mislead. It can suppress an alert on the very intrusion that wrote the log line, and it can steer an automated playbook toward the wrong host.

A log pipeline with an LLM at the end is a chat interface with your attacker, and the attacker gets to type first.

A threat model that fits

• Every log field an external party can influence is untrusted input. That includes fields you think are structured. A username is a string.
• The model is a component that follows instructions from its input. Assume it will, and design as if the attacker knows the prompt.
• Output is only as trustworthy as the least trustworthy input. One adversarial line in 10,000 makes an adversarial summary.
• Unattended actions are the blast radius. Anything a SOAR step does without a human is what the attacker actually targets.

What to build

• Provenance tags. Carry a source classification through the pipeline and render it in the prompt. Untrusted fields go in a delimited, quoted block the system prompt explicitly describes as data, never as instructions.
• Constrained output, then validate it. The 38% figure says schemas help and are not enough. Enforce the schema outside the model with a validator that rejects free-text fields entirely on automated paths, the approach in output validation guardrails.
• Two-model disagreement. Run the summary twice with different prompt framings or different models and route disagreements to a human.
• Canary lines. Inject your own known adversarial lines into the stream and alert when the model's output changes in response.
• Red-team the pipeline, not the model. The tests in LLM security red-teaming apply, but the payload delivery is a log line, so your test harness writes logs.
• Keep the human on the alert path. For now, an LLM summary should raise priority, never lower it, and should never close a ticket alone.

The honest gap

This is a preprint. I have not seen a peer review, the models and prompt templates behind the 96% and 38% figures determine how far they generalize, and the summary I read does not say which SIEM products or open-source pipelines were tested. Treat the numbers as an upper bound on a plausible configuration, not as a measurement of your stack. The right response is to run the canary test on your own pipeline this week and get a number you can defend.