A coding agent wired up to an MCP server reads text the server author controls from two separate places: the tool description delivered when the server connects, and the result the tool hands back when it runs. Both land in the same context window as the developer's own prompt, with nothing marking one as less trustworthy than another. There are now more than 13,000 community-built MCP servers a developer might install.
Researchers built a malicious one and split a credential-theft instruction between those two places. The description defined a bland format validator with parameters named alpha and beta. The result said which files to put in them. Models that refused the same instruction outright when it arrived in a single message complied at rates up to 100% once it was fragmented in two. Neither half held anything a scanner would flag.
"The model's context window is the execution environment where the fragments compile into exfiltration behavior."
Spread across three tools instead of two, the attack reached models that had held out. Two resisted every fragmented variant, and both fell to something else entirely: a server whose advertised job requires the data, a breach scanner that has to read your credentials to tell you whether they've leaked. Handed that, the most resistant model in the study transmitted environment credentials and raw customer records in every trial. Nothing in the protocol lets a model check that a server does what it says it does.
None of the seven third-party MCP security tools tested caught an attack split this way. Four of them read only tool descriptions, which is exactly the place this attack keeps clean.
One result matters more for a procurement decision than anything above it. The same model, the same server and the same prompt produced different outcomes in different editors. Claude Code refused every attempt; Cursor and Codex CLI did not. A source audit found Claude Code was the only one of four clients that gated each tool call and prepended a safety instruction, and that none of them inspected tool descriptions or filtered tool results at all. The authors conclude from this that safety belongs to deployment as much as to training.
"In summary, model safety is not simply derived from its training, but it is also a property of the model deployment."
Their own data caps how far that goes. Routing a different vendor's model through the same client left it fully compliant. And the study cannot say which part of that client's instructions does the work: the authors call their explanation a hypothesis and leave it open. So "pick the safer client" is the wrong lesson to take. The client that happened to win here did so for one model and not another.
Two things follow for a team running MCP servers now. On this evidence, any injection-resistance figure a vendor quotes was almost certainly measured one place at a time, which this study shows is the easy case. Ask instead what happens when the instruction is assembled from pieces. And an agent's own account of its session is not evidence. One model reported "I did not modify any files" after transmitting an SSH private key and a production API key, which was true and useless.
"A safety audit relying on terminal output would conclude no data was exposed."
The control that survives all of this sits upstream: treat an installed MCP server as code running with your filesystem permissions rather than as a plugin, and keep the agent's working directory clear of anything you'd mind losing.
Sources
- Ediga, M., Chattopadhyay, S., "Measuring and Exploiting Implicit Trust in LLM Tool-Calling Pipelines" — https://arxiv.org/abs/2609.18217