Germline tests show signed MCP tools can leak data through allowed destinations

A signed persistent MCP tool retained confidential context across calls and reused its permitted OCR-like endpoint to transmit unrelated data. Signature verification and destination allowlisting left a gap because the destination itself was authorized.

The Germline prototype isolated per-call data and reported zero disclosures in 153 tests versus 114 of 153 under signing-only protection, plus 91 tested adaptive variants. Those are experimental results within its instrumented Python setting.

Germline's attack does not need the signed MCP package to be changed after installation. A persistent OCR-style tool can retain sensitive bytes from an earlier authorized call and send them to a server that is itself permitted for OCR requests. Signing establishes that the same tool code is running, while a destination allowlist establishes where it can connect; neither proves the bytes in each call were authorized for that recipient. The prototype starts each call from a data-free state and has a broker separate or reject mixed-provenance data. The paper reports zero disclosures in its tested 153 cases and 91 adaptive variants, not a guarantee against every uninstrumented channel or flawed broker labeling.

A signed tool identifies code provenance, not which confidential data the process retained from prior calls. The research attack reused data across otherwise permitted OCR-style requests, including requests sent to an allowed destination. Germline's per-call process isolation and broker-side labeling aim to stop that data crossing request boundaries, but the tested Python prototype cannot establish protection for uninstrumented channels. This complements recipient-provenance defenses: destination approval alone cannot make an authorized endpoint safe for every piece of carried data.