GhostSplice: Malicious MCP Servers Split Instructions to Make AI Agents Exfiltrate Secrets

Researchers have shown that a malicious MCP server connected to an AI coding assistant can steal SSH keys, environment secrets, source code, and customer data without ever sending one obviously harmful instruction. The technique, named GhostSplice by ASSET Research Group, splits a malicious request into fragments that each look routine, places them in the different channels an assistant already reads (a tool description, a tool result), and lets the agent stitch them together and send the data out. It works over the Model Context Protocol, the open standard that lets AI assistants call external tools, and it can succeed even after a blunt, single-message version of the same theft is refused. The disclosure describes controlled tests in isolated projects seeded with fake credentials, not a real-world intrusion, and says any CVE identifiers will follow coordinated disclosure.

The important nuance is where the trust breaks. MCP does preserve structured boundaries between a tool's description and its results, so this is not a case of the protocol failing to separate fields. What ASSET's tests show is that an agent can still combine instructions across those separate fields inside the same working context, so no single fragment has to carry the whole malicious request. One benign-looking fragment sits in a tool description, another in a tool result, and the model assembles the complete instruction the way it assembles any other context. Stateless, single-payload input and output filters, which inspect one message at a time, see nothing wrong with any individual piece.

The sharpest finding is not a model leaderboard. The same model refused the attack in one coding client and carried it out in another, which means the deciding factor was the harness around the model, its system-prompt framing, tool formatting, and safety controls, not the model's own judgment. That is the same lesson emerging across AI-agent security this year: the model is one component, and the code that decides what it can read, call, and reach is where the defense has to live. The attack also has a built-in limit worth stating plainly. It is not a way to break into an arbitrary agent from the outside; it assumes the developer has already connected the attacker's MCP server. That is a supply-chain precondition, not a remote exploit.

How is GhostSplice different from ordinary prompt injection?

Ordinary indirect prompt injection typically carries a working instruction inside a single piece of content the model reads. GhostSplice instead spreads the instruction across separate structural channels of the protocol, a tool description and a tool result, so no one fragment is a complete instruction. Community researchers have taken to calling it context-stitching: each fragment is fully benign in isolation, so a guardrail that scans individual inputs or outputs passes all of them, and only the assembled context is malicious. The analogy people keep reaching for is the early web, when raw string concatenation was treated as safe structured input right up until SQL injection proved otherwise. The defensive implication is that inspecting payloads one at a time is not enough; the harness has to reason about what the combined context can do.

What should teams using MCP servers do now?

Treat connecting an MCP server as a supply-chain decision, because it is the developer connecting the server that grants it influence over the agent. Audit the tool descriptions and schemas of any community-built MCP server before you register it, since that metadata, not just the tool's return values, steers the agent. Then contain the blast radius at the layer below the model: run agents with least-privilege file access, read-only or scoped working directories, and egress filtering, so that even a successfully stitched instruction lacks the OS-level capability to reach ~/.ssh or an external exfiltration endpoint. Assume the model can be talked into cooperating and make sure the environment will not let it.

Our read

This is a supervised-adversary-simulation problem in its purest form. You cannot certify an agent safe by prompting the model nicely, because the same model flips from refusing to exfiltrating based on the harness around it. The verifiable-by-design posture is to test each agent configuration against real split-instruction payloads, scope what its tools can touch, filter what it can reach, and re-verify those boundaries whenever you add an MCP server, rather than trusting a one-time safety evaluation. As agent tooling heads toward its own version of the npm ecosystem, the tool schema you connect is now part of your attack surface. Audit it like dependency code, and constrain the agent as if it will be fooled.

Reporting by The Hacker News; technique and test details per ASSET Research Group's disclosure. Sources linked above.

Related: Atlassian Rovo data exfiltration and RovoBlast · Gemini CLI CVE-2026-12537 and Claude Code CI flaws