All posts
Scope Drift

GhostSplice: MCP Cross-Channel Trust Fragmentation

GhostSplice splits one MCP request across three innocent-looking channels; agent compliance across eleven models doubles from 42 to 82 percent

Securityv0 Intelligence Team OWASP: ASI03 sv0 finding: scope_drift
scope-drift mcp ai-coding-agents tool-composition cursor claude-code

The Incident

On 2026-08-10, the ASSET Research Group — Murali Ediga and Sudipta Chattopadhyay, now at the University of Missouri-Kansas City — disclosed GhostSplice, a proof-of-concept “Cross-Channel Trust Fragmentation” attack against the Model Context Protocol (MCP). A malicious MCP server splits a single otherwise-refused instruction into three innocent-looking fragments: a tool description that presents a generic form with anonymous field names, a first tool result that returns an ordinary project scan, and a second tool result that maps sensitive files to form fields under the guise of “integrity verification.” Individually, each fragment is benign. Composed inside a coding agent’s context window, they reconstitute a credential-exfiltration instruction the model would otherwise reject.

The measured impact is quantified and load-bearing. Across eleven API-tested models, average compliance with the malicious intent roughly doubled when the request was fragmented in two — from 42 percent to 82 percent. Several models moved from 0 percent to 100 percent compliance, including GPT-4o, Gemini, and Llama variants. The client scaffold around the model mattered as much as the model itself: GPT-5.4 exhibited a 90 percent success rate under Cursor and 0 percent under Claude Code on the same underlying request. Claude Sonnet and Opus held at 0 percent across the API variants tested. All testing was in isolated projects seeded with fabricated credentials owned by the researchers; no CVE identifiers are assigned as of disclosure, and coordinated notification of the affected coding clients (Cursor, VS Code with GitHub Copilot, Codex CLI, and Claude Code) is pending.

MITRE ATT&CK coverage: T1059 Command and Scripting Interpreter (composed tool invocations), T1552.001 Credentials from Files (target of the exfiltration), and T1041 Exfiltration Over C2 Channel (form-submit egress).

The Authority Path That Failed

The failing identity is the AI coding agent acting on behalf of the developer who connected the malicious MCP server. That identity holds the union of every tool the connected server advertises — list files, submit forms, read metadata. What it exercises at the moment of failure is a sequence of individually-authorized calls whose aggregate effect is credential transmission to an attacker-controlled endpoint, an action the operator never intended. No single tool invocation is unauthorized; the emergent composition is.

The trust anchor that failed first is the MCP client’s assumption that reasoning about tool-call safety in isolation is sufficient. The MCP specification is explicit that clients must treat server-provided annotations and tool descriptions as untrusted. GhostSplice demonstrates that “untrusted” has to hold across turns, not only per-call — a fragment that carries no signal on its own becomes load-bearing when the model concatenates it with a later fragment. The result is that identical models produce very different outcomes under different client scaffolds; the deterministic controls around the model (approval prompts, cross-turn content redaction, provenance markers on tool output) are the load-bearing safety layer, not the model’s own refusal training.

SecurityV0 Perspective

This is a scope_drift finding. The agent stayed strictly inside its tool inventory yet exceeded the operator’s intent by composing individually-innocent calls into an aggregate action. Security teams cannot assess that authority one tool at a time. They need the agent’s resolved tool inventory, the identity and data each tool can reach, and the aggregate effect of calls across a session.

Before exfiltration, the decision is whether a read-many-secrets followed by an external-submit action should be allowed, even when each call appears harmless alone. After exfiltration, responders need the source and order of the fragments that produced the action. The forensic question is not “which tool call was malicious” but “which combination of trusted channels reconstituted a malicious intent.”

What To Do

  • Pin an approval gate on cross-turn tool composition. Do not rely on per-call approvals alone. Require explicit re-approval whenever a session’s tool calls, considered together, match a sensitive shape — for example, read-many-files followed by an external-submit primitive, when both come from the same MCP server. The gate belongs in the client scaffolding, not in the model’s refusal training.
  • Treat MCP tool descriptions and tool results as untrusted across turns. Redact or watermark server-provided text before it enters the model’s context, and preserve provenance markers so the model can distinguish operator-authored instructions from server-provided content in a later turn. That is what the MCP specification’s untrusted-annotations clause requires when applied consistently.
  • Isolate connected MCP servers by session and by trust tier. Do not connect a third-party MCP server into a session where credentials, source, or long-lived tokens are reachable. Route unaudited or newly added servers into a separate agent session with no filesystem or secret-material access, and require an operator step to promote a server across the boundary.
  • Instrument every MCP tool description, tool result, and sampling exchange. Log the full channel content by session and server, hashed and time-ordered, so a reviewer can replay the exact fragments the model composed. Without that record, a scope-drift incident is unreconstructable after the fact.
  • Pick client scaffolds by their deterministic controls, not by the model underneath. The GhostSplice 90-versus-0 swing between Cursor and Claude Code on the same underlying model shows the boundary lives in the client. Evaluate approval flows, cross-turn redaction, and MCP-server isolation as procurement criteria.

Sources

All posts