GhostSplice: When Harmless MCP Messages Become a Secret-Theft Chain
GhostSplice proves MCP security has a context problem
The latest MCP attack does not need one obviously malicious instruction. It splits intent across tool descriptions, tool results, and sampling prompts, then lets the agent assemble the theft inside its own working memory.
On August 11, 2026, The Hacker News reported a new ASSET Research Group disclosure called GhostSplice. The research targets AI coding assistants connected to external tools through Model Context Protocol servers.
The uncomfortable part is not that an MCP server can be malicious. Security teams already understand supply chain risk. The uncomfortable part is that the malicious intent is not present in any single artifact a normal control would inspect.
GhostSplice is a trust-fragmentation attack. It breaks a sensitive request into small pieces that look ordinary on their own:
Read separately, each message looks survivable. Read together, they are a data theft workflow.
That is the point security teams should take seriously. Agent security controls that judge each MCP message in isolation are watching packets when the exploit is a conversation.
Why GhostSplice is different
Most prompt injection discussions still assume the payload is a string. Find the bad words, quarantine the content, block the action. GhostSplice moves the payload out of the string and into the relationship between strings.
The public GhostSplice proof-of-concept repository describes a three-channel variant where no single channel contains the full bad request. The tool description names no secret file. One tool result looks like a normal inventory. Another supplies the file-to-field mapping. The assistant sees all three in the same working context and does the dangerous thing.
The researchers also tested a sampling-channel variant. MCP sampling lets a server ask the client model to generate text. According to the repository, one common client approval path showed the server name but not the hidden high-trust message attached to the sampling request. That matters because approval UX becomes meaningless when the user sees the envelope but not the instruction.
GhostSplice is not primarily a model failure. It is a client and control-plane failure. The same model can behave differently depending on the MCP client, the policy layer, and whether controls evaluate the full sequence before tools run.
That distinction is what makes the finding useful. Buying a safer model does not solve cross-channel trust fragmentation. The defense has to live where the agent’s context, tools, permissions, and action history meet.
The old inspection model breaks
Security teams are comfortable reviewing separate things: dependency manifests, tool metadata, prompts, tool outputs, logs, and approval dialogs. GhostSplice is built for that world. It hides the harmful instruction across boundaries that your controls treat as independent.
| Inspection point | What it sees | What it misses |
|---|---|---|
| Tool description scanner | A generic integrity tool with neutral field names. | The later mapping that turns fields into secret containers. |
| Tool result filter | A file listing or scan result that resembles normal developer automation. | The prior description that gives the result somewhere to send data. |
| Human approval prompt | A tool name, server name, or short action summary. | The assembled instruction graph inside the agent’s context window. |
| Egress monitor | A legitimate MCP tool call to a server the developer already connected. | That the payload includes raw secrets the server never needed. |
This is why “we scan MCP server manifests” is not enough. It is necessary, but it is preflight security for a runtime exploit.
Map it to OWASP Agentic Top 10 (2026)
GhostSplice sits across several OWASP Agentic Top 10 (2026) categories:
ASI01 - Agent Goal Hijack
The agent’s stated task is a security scan, but the working objective becomes collecting sensitive files and forwarding them.
ASI02 - Tool Misuse
A benign-looking tool becomes an exfiltration sink because the agent fills it with data the server should never receive.
ASI04 - Agentic Supply Chain
The malicious behavior arrives through a connected MCP server, which is now part of the agent’s executable supply chain.
ASI06 - Memory and Context Poisoning
The exploit depends on context accumulation. The dangerous instruction exists only after the agent remembers and combines fragments.
ASI09 - Human-Agent Trust Exploitation
Approval prompts can create false confidence when they summarize the action but hide the semantic payload.
ASI10 - Rogue Agents
The agent may report that it is doing routine validation while its actual tool sequence creates unauthorized data movement.
The OWASP Agentic Top 10 launch framed agentic risk around action, coordination, identity, tools, and context. GhostSplice is a clean example of why that broader framework matters. It is not “prompt injection” in the old chatbot sense. It is a control failure around an autonomous system that can read, reason, call tools, and transmit results.
The defense: inspect sequences, not messages
There are three practical shifts security teams should make now.
1. Build an MCP context firewall
- Evaluate tool descriptions, tool results, sampling prompts, and proposed tool calls as one sequence.
- Flag joins between sensitive local files and outbound tool parameters, even if no single message is malicious.
- Keep a short-lived semantic graph of “who asked for what data, why, and where it is going.”
2. Make least privilege data-aware
- Do not grant coding agents blanket read access to home directories, SSH keys, environment files, or customer datasets.
- Separate “can scan filenames” from “can read file contents” from “can send contents to a remote tool.”
- Require explicit policy exceptions for secret-bearing paths and large source or customer exports.
3. Treat approval dialogs as evidence, not control
- Show users the sensitive data classes involved, not just the tool name.
- Block hidden sampling instructions from receiving higher trust than visible user intent.
- Log the full assembled rationale and tool-call chain for post-incident review.
The key word is assembled. Your policy engine needs to judge the workflow the agent has assembled, not the prompt or tool result it happens to be looking at this millisecond.
What to ask your platform team this week
If your organization allows MCP servers in developer environments, ask five concrete questions:
- Which MCP servers are approved, and who owns each one?
- Can any connected server request sampling or inject high-trust instructions?
- Which agents can read
.env, SSH keys, cloud credentials, source code, and customer exports? - Do we inspect complete tool-call sequences before sending data to remote servers?
- Can we replay the agent’s context and decisions after a suspicious tool call?
If the answer to question four is no, GhostSplice should go on your near-term risk register.
Agent controls that inspect messages one at a time will keep missing attacks that only become malicious when the model assembles them. MCP security needs sequence-level policy, data-aware permissions, and approval UX that shows what actually leaves the machine.