I originally published this article on LinkedIn.
We’re starting to point AI assistants at our security logs. The catch nobody says out loud: a lot of that log data is written by attackers.
So I ran an experiment to answer one question — if an attacker hides an instruction inside a log field, does it survive the trip through a real Microsoft Sentinel pipeline all the way to where an AI would read it?
Short answer: mostly, yes. And the thing that decides whether it survives isn’t the platform, it’s how the connector is built.
1. The problem
Think about what lands in a SIEM: user-agents, URLs, referrers, attempted usernames, filenames, command lines. Much of it is chosen by whoever is knocking on the door. If an attacker can slip text into a field that an AI later reads while investigating an alert, they can try to smuggle instructions into that text — an authority-sounding aside telling the assistant a source is already cleared and the alert is a false positive, for example.
Because the malicious text rides inside the very evidence the model is meant to analyse, a recent paper gave it a name: log-substrate prompt injection. That paper defined the category and showed the attack works against an LLM reading logs, but it used synthetic, simplified logs, and it did not test what happens once those logs pass through a real ingestion pipeline with transformations and normalization.
That gap is where I work day to day. I build data connectors for Microsoft Sentinel, which means I write the exact transformations a payload would have to survive. So I set out to measure it on the real thing.
2. What the pipeline does to a log line
In Sentinel, a planted string passes through a few stages before an assistant reads it:
- An ingestion-time transform (a small KQL step the connector author controls) can rename, truncate, extract, or repack fields.
- Storage writes the record to a table, where field size limits are far larger than any injected instruction.
- Normalization presents the data in a common schema at query time.
- A tool hands selected fields to the model as plain text.
None of these stages is designed to sanitise free text. My hypothesis: survival would be high by default, but the transform stage — since it reshapes text — might destroy payloads as an accident of how it’s written.
3. How I tested it, safely
Everything ran in a disposable, isolated workspace in its own resource group — not a live SOC, and not a data-lake workspace — so no planted test string could persist or touch anything real.
I deployed six versions of the ingestion transform, all writing to one table, to compare head-to-head:
- T0: verbatim pass-through (the control)
- T1: truncation (cap field length)
- T2: extract-to-subfield (keep just the browser token from the user-agent, drop the rest)
- T3: selective projection (keep a couple of fields, drop the others)
- T4: flatten and also keep a raw copy (a common over-retention habit)
- TT: a non-destructive trust-tagging defence I wrote
Then I sent a battery of benign, synthetic instruction-style probes across the field types attackers actually control, in several forms: plain text, URL-encoded, base64, zero-width-character obfuscated, and whitespace-obfuscated. Deliberately no real, tuned exploits — these are research probes, not weapons. A payload “survived” if its instruction was still semantically present at the end, measured in a way that saw through cosmetic obfuscation.
4. What I found
(Provisional figures; the final version uses the clean deduplicated run.)
Bottom line: injected instructions mostly survive. Overall, 73% arrived semantically intact. By default, the pipeline is a delivery route, not a filter.
Survival by transform pattern:
| Transform | Survival | Note |
|---|---|---|
| T0 — verbatim (control) | 85.7% | — |
| T1 — truncation | 85.7% | no meaningful reduction |
| T2 — extract-to-subfield | 47.6% | down ~38 points |
| T3 — selective projection | 47.6% | down ~38 points |
| T4 — flatten + raw copy | 85.7% | no reduction |
| TT — trust-tagging | 85.7% | non-destructive by design (see below) |
The connector’s transform is the lever. Transforms that reshape data hard (T2, T3) knocked survival down by nearly 40 points — not on purpose, but because chopping a field to its useful token, or dropping it, takes the injected text with it. Faithful transforms let almost everything through. Whether an injection survives is decided by how the connector is written, well before any AI is involved.
Two smaller findings: truncation didn’t help (real payloads are tiny next to field size limits), and I saw no accidental “decode” of encoded payloads in this run — worth re-testing against parsers that explicitly decode.
5. The defensive angle
Because transform design is the lever, you can deliberately write one that defends. That’s the TT pattern. It’s non-destructive: it keeps the raw field for forensics, but also adds a provenance marker noting which fields are attacker-controllable (so anything downstream can be told to treat them as data, never instructions) and a lightweight flag when instruction-like tokens appear in the evidence (turning the attack into something you can alert on). Its job isn’t to shred the payload — it’s to label it so the layer that reads it knows not to trust it.
If you author Sentinel connectors: know whether your transform preserves attacker-controlled free text verbatim (most do), and if that data will ever reach an AI assistant, tag it.
6. What this does and does not prove
Proven: planted instructions survive the real Microsoft Sentinel ingestion pipeline at high rates, and the connector’s transform design controls that rate.
Not proven, on purpose: that an AI assistant actually obeys a surviving payload. Demonstrating influence on a live, acting assistant is the higher-risk stage, and I kept it out of any production-connected environment. So the honest headline is “these payloads reach the reader intact,” not “AI SOCs can be hijacked.”
Other limits: I focused on web/proxy-style sources and one parser; the detection heuristic is a seed, not a tuned detector; and these are synthetic probes, so real phrasing may differ.
Credit where due: this builds directly on the “Poisoning the Watchtower” work that named log-substrate prompt injection. My contribution is narrow — moving the measurement onto a real vendor pipeline and showing connector transform design is a control surface. If you’re building AI into a SOC, that’s the part worth acting on.