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

LIMITATIONS.md

@@ -48,6 +48,19 @@ cMCP intercepts tool calls at the MCP protocol boundary. It does not observe or
 **Response injection evasion via novel patterns**
 The response inspector uses pattern-based detection for prompt injection in tool responses. Pattern-based detection has false negatives. A sufficiently sophisticated injection may evade the current pattern list. The pattern list must be maintained and updated by the operator as new injection techniques emerge; see [Compensating Controls](https://cmcp.agentrust-io.com/spec/threat-model/#compensating-controls-operator-responsibilities).
 
+**Cross-channel fusion: no single call is a violation (GhostSplice)**
+Cedar evaluates one tool call at a time. GhostSplice ([ASSET Research Group, July 2026](https://asset-group.github.io/disclosures/ghostsplice/)) splits one instruction across channels a server already owns, so that no channel carries a violating instruction: the tool description advertises a form with fields named `alpha` through `delta` and names nothing sensitive, and a later tool result supplies the mapping from those fields to `.ssh/id_rsa`, `.env` and source files. The harm exists only once the model has fused both in its own context, which is not a place the gateway can read.
+
+Three things follow, and all three are gaps rather than theoretical concerns.
+
+- **The shipped injection patterns do not fire on any GhostSplice channel.** Run the ten patterns in `src/cmcp_runtime/inspection/patterns_v1.json` against the published `deep_scan` result, the `integrity_checker` description, and the sampling disposition, and all three return no match, while a classic tool-poisoning payload matches `xml-system-tag` and `ignore-instructions` in the same run. That 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.
+- **Cedar sees argument values, not their provenance.** `_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", cannot be written as a Cedar policy against the context the gateway builds today.
+- **In a coding-assistant deployment the gateway never sees the read.** The file reads are performed by the client's own filesystem tools, not by an MCP server in the catalog. cMCP observes one call, `integrity_checker(alpha=<blob>, ...)`, with no record that a read happened at all.
+
+What cMCP does carry across calls is `session_max_sensitivity`, a monotonic ratchet that a caller cannot lower. Where the sensitive read *does* go through the gateway, a policy denying external-destination calls above a sensitivity floor will stop the egress leg, and that is a real defence rather than a hypothetical one. It depends on the operator having written that policy, and it does not apply when the read bypasses the gateway, which is the common case for a coding assistant.
+
+Two things this entry deliberately does not claim. The study's compliance figures are an average over eleven models under one costume and one channel split, moving from 42% to 82%; 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 while Claude 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 in which 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.
+
 **APM and telemetry payload capture**
 The TEE prevents plaintext from leaving the enclave to any destination not covered by the egress policy. This protection is structural only when the egress policy explicitly denies APM and telemetry endpoints. If the operator allowlists those endpoints in the Cedar policy, the TEE boundary does not prevent payload capture by the APM agent. A TRACE Claim with an egress policy that permits APM or SDK telemetry endpoints does not provide this protection. Verifiers must inspect the policy bundle hash and confirm the policy excludes those endpoints.