A valid signature does not stop an MCP tool from leaking: Germline execution gives each call only its cleared data, with zero disclosures in 153 attack runs

A gap sits between signing and runtime restriction: an MCP tool that passes signature verification and performs its advertised function can still smuggle data it should not see into a request to a policy-allowed destination. Earlier defences bound authority to other objects: a signature binds the publisher, MCPGuard-Dynamic-style confinement binds the process and the destination hosts it may reach, and agent information-flow control such as FIDES and CaMeL binds labels to tool replies. In MCPGuard-Dynamic's own runner, a signed OCR tool, pool, keeps items from the HR and board calls and appends them to the next request to the authorised OCR destination, disclosing in every trial under all seven configurations; in the same run, a raw-socket transfer to an unlisted host was blocked in every trial under the eBPF-enabled configurations.

Germline execution does not judge whether tool code is trustworthy; it controls which data the code can see, running each call in disposable copies forked from a data-free germline process, each receiving only the data its destination may see, with the copies discarded after the call. A Plan step groups consumers and declared destinations by view, the germline forks one sandboxed copy per group, and state crosses calls only through per-horizon slots held outside the copies. No canary disclosure was detected in 153 attack runs of the scripted matrix, against 5.9–74.5% for baseline defences and an ablation; none was detected for any of 91 generated variants, while an egress allowlist of this class stopped the 71 that send to an attacker-owned host and none of the 20 that send to a policy-allowed host.

The demonstrated setting is a single user's home-directory test world on one machine, holding labelled PDFs, two SQLite databases, a code repository, mail drafts and credential files, with a fresh random canary per protected item per trial; the prototype runs unmodified Python MCP servers on stock Linux without kernel changes, and 780 calls returned the same output as the unprotected servers, with the sole exception of the clock value returned by get_current_time. The authors list concurrency, throughput, many resident releases and cloud-hosted services as future work.

Every zero-disclosure result is scoped to the authors' own corpus and canary oracle, and the generated-variant corpus was produced by the authors, so it does not show how common such code is. Remote tools cannot be forked and receive prevention only through worst-case reply labels, at a utility cost; a release that reads the CPU cycle counter still cannot disclose but its divergences stay unverified; covert timing and microarchitectural channels lie outside the assumptions; and the dampening policy carries no guarantee, since an adversary can reset the penalty with an update.