A Signed AI Tool Can Still Leak Data to an Approved Destination

When the destination is legitimate

AI agents use Model Context Protocol (MCP) servers to work with documents, databases and other services. Those servers can be authenticated and restricted to approved files and network destinations. But an approved destination is not necessarily approved to receive every document available to the tool.

In the November 4 preprint Signed, Sealed, Leaked: Trust Beyond Signature for MCP Toolchains, Yichiet Aun and colleagues demonstrate malicious routines inside legitimately signed tools that still perform their advertised functions. Their attack does not require forging a signature: the publisher signs the malicious bytes along with everything else.

One example, called pool, retains confidential material from earlier calls and appends it to a later, authorised optical character recognition request. An OCR service cleared to receive a finance invoice thereby receives HR and board material too. Another failure mode needs no retained memory: a single call can contain differently classified items, which malicious code mixes into one outgoing request.

What the guard actually guarantees

The researchers tested Meta’s MCPGuard-Dynamic across seven configurations in its own runner, using three trials per configuration and attack variant. The session involved six calls handling HR, board, finance and public material.

Configurations with MCPGuard’s eBPF enforcement blocked a direct raw-socket transfer to an unlisted host. However, pool and a permitted-file attack called smuggle disclosed data through the authorised OCR destination in every trial under all seven configurations.

The paper explicitly describes this as a boundary of destination-based confinement, not an implementation vulnerability in MCPGuard. Deciding where a process may connect is different from deciding which items it may send there. In a separate shared-harness comparison, pool was the matched attack: germline execution produced no detected disclosure in its three trials. The authors’ own smuggle release was inactive in that particular session, so its zero there is not evidence of prevention.

Give each execution only its permitted data

The proposed defence, germline execution, changes the execution environment rather than trying to recognise malicious code.

A clean parent process loads the tool but never receives user data. For each invocation, a planning step examines public metadata, data labels, recipient clearances and declared destinations—not document contents. It creates disposable copies with only the information their assigned destinations or consumers may see.

For example, an OCR-facing copy receives an invoice but not a salary sheet. A separate copy serving an agent authorised for both can receive both. A trusted broker delivers OCR requests only from the OCR-facing copy; requests from the more privileged copy are compared, not forwarded.

Copies are destroyed after execution. Necessary persistent state must pass through broker-managed storage separated by clearance, with labels covering stored information. Consequently, state kept only in ordinary process memory does not survive between calls.

Planning from declared destinations matters: if secret-bearing code could decide whether a destination’s copy existed, the presence or absence of a request could itself reveal a secret bit.

What the experiments measured

The main scripted evaluation covered five tool servers and 51 attack cases, each repeated three times: 153 attack runs per runtime. Protected items carried fresh random markers, and an external detector checked whether those markers reached unauthorised test recipients, including through several encodings.

No marker disclosure was detected under germline execution. A confinement-plus-information-flow baseline disclosed in 51 of 153 runs; restarting the process for every call disclosed in 15. An ablation retaining disposable execution but removing destination-specific splitting disclosed in nine. Every runtime completed all 99 benign steps.

A separate, author-generated corpus contained 91 validated malicious variants. Germline execution again had no detected disclosure across three trials. A destination-allowlist baseline stopped the 71 variants targeting unlisted hosts, but none of the 20 targeting allowed hosts. This was not an independent benchmark or a measurement of real-world attack prevalence.

Speed, evidence and boundaries

Single-copy benchmark calls took approximately 10–49 milliseconds, 2–28 times faster than starting a fresh process for every invocation—not faster than an ordinary persistent tool. A three-copy summarisation call took 97.3 milliseconds, only slightly below the fresh-process comparison’s 102.8 milliseconds.

The authors also present a conditional noninterference proof: delivered requests cannot depend on item contents outside the destination’s permitted view. It assumes correct confinement, a data-free parent, trusted broker and policy, public routing metadata, and controlled handling of replies. Timing and microarchitectural channels are outside that guarantee.

A separate replay mechanism can establish flow violations for releases deterministic within its replay model; prevention does not depend on detecting them. Remote tools cannot be forked and instead receive conservative reply labels, which blocked some legitimate public posts in testing.

These are preprint findings from a controlled, single-user testbed. The defence addresses confidentiality, not whether an otherwise permitted action is desirable: a harmful command containing no secret data still requires action controls.