Foretheta Research

No single channel carries the injection, so no scanner sees it

17 September 2026 · Foretheta · mcp · injection

What happened

I was reading a preprint on arXiv that split one credential-exfiltration payload across two or three MCP input channels, the tool description, the tool result, and a sampling message, so that no single channel contained a complete injection [1]. Models that refused every single-channel version, at 0% compliance, exfiltrated data at up to 100% once the same payload arrived in two pieces [1].

The study ran over 15,000 trials across 12 frontier models, three production clients, and six payloads, and names GPT-4o, Llama 70B, Composer 2, and Haiku 4.5 among the models that went from full resistance to full compliance under two-channel fragmentation [1]. The authors also tested seven third-party MCP security tools and three prompt-based defenses. All seven tools failed to detect fragmented payloads, while the prompt defenses worked on some models and not others [1].

Why it happened

You would expect a model that rejects an injection in one channel to reject it when it is split, because the harmful instruction has not changed. The mechanism the authors describe is that all three channels land in one context window with no privilege separation, so the model reassembles fragments that each looked benign into one instruction and acts on the whole [1].

The scanner result follows from the same fact. A scanner that inspects a tool description on its own is inspecting the wrong unit. The attack does not exist in the description, or in the result, or in the sampling message. It exists once the pieces are assembled in context, and none of the seven tools looked there. That is my reading of why every one of them missed it, and it is enough breadth across vendors that I would not treat this as a quirk of one model.

What we would change

The check has to sit after assembly rather than before it.

1. Log the full context the model actually received on every tool call: descriptions plus results plus any sampling messages, together, as one record. This is the unit the attack lives in, so it is the unit detection has to run on.
2. Run injection detection over that assembled text, not over each channel as it arrives.
3. Diff the tool descriptions that reached the model against the set approved at install time. A description that changed between approval and use is a finding on its own, whatever it says.

The paper's VS Code case, where a sampling system-prompt override injected persistent instructions through the MCP implementation [1], is the one I would write the first test for, because it is the channel most teams do not know they have.

Where this shows up in our work

Channel classification and assembled-context logging are the core of MCP and Tool-Use Hardening, and the install-time description diff is one of the regression tests we hand over at the end of it.

References

If this reads like your system, the Agent Security Architecture Review is where we would start.