docs(limitations): name cross-channel fusion, and check it against the shipped patterns

[imran-siddique]

What

Adds a Cross-channel fusion: no single call is a violation (GhostSplice) entry to LIMITATIONS.md, under "What cMCP does not prevent".

GhostSplice (ASSET Research Group, July 2026) splits one instruction across channels a malicious server already owns. The tool description advertises a form with fields alpha through delta and names nothing sensitive; a later tool result supplies the mapping from those fields to .ssh/id_rsa, .env and source files. No channel carries a violating instruction. The harm exists only once the model has fused both in its own context.

Cedar evaluates one tool call at a time, so this is a case the gateway cannot reach, and the limitations file did not say so.

The check, which anyone can rerun

Running the ten patterns in src/cmcp_runtime/inspection/patterns_v1.json against the three published GhostSplice channels, with a classic tool-poisoning payload as the control:

patterns loaded: 10 version 1.0.0
  deep_scan result (GhostSplice channel 2)      -> NO MATCH
  integrity_checker description (channel 1)     -> NO MATCH
  sampling DISPOSITION (channel 3)              -> NO MATCH
  CONTROL: classic tool poisoning               -> ['xml-system-tag', 'ignore-instructions']

This is not a tuning problem. Each fragment is a grammatical, harmless sentence, so there is no pattern to write that does not also match ordinary tool output. The existing "Response injection evasion via novel patterns" entry says patterns have false negatives, which is true and not the same claim.

Three specific gaps, named

• The shipped patterns do not fire on any channel, above.
• _build_cedar_context passes arguments through _cedar_safe as opaque values. Nothing records that the bytes in alpha are a file the agent read because a previous tool's result told it to. The control the researchers prescribe, "never let values from one tool's output flow untouched into another tool's arguments", is not expressible against the context the gateway builds today.
• In a coding-assistant deployment the file reads go through the client's own filesystem tools, not an MCP server in the catalog, so the gateway never observes the read at all.

What the entry also says, in our favour and against it

session_max_sensitivity is a monotonic ratchet a caller cannot lower, so where the sensitive read does traverse the gateway, a policy denying external-destination calls above a sensitivity floor stops the egress leg. That is a real defence. It requires the operator to have written that policy, and it does not apply when the read bypasses the gateway.

Two claims the entry deliberately does not make: the 42% to 82% figure is an average over eleven models under one costume and one channel split, and several models complied with the blunt single-instruction version too, so "models refuse until you split it" is not accurate as a general statement. And although Sonnet 4.6 and Opus 4.6 held at 0% across every split in the tabulated configuration, the same write-up reports a separate run where Sonnet called the tool and redacted the obvious secrets while still returning proprietary source with a live key inside it. Model choice is not a control.

Scope

Documentation only. docs/limitations.md is a --8<-- include of the root file, so it picks this up with no second edit.