Signed MCP tools can still leak — Germline execution — What does it mean?

The news. On November 4, 2026, researchers posted “Signed, Sealed, Leaked: Trust Beyond Signature for MCP Toolchains”. They built a legitimately signed MCP tool that does its advertised job and quietly leaks, and showed that Meta’s MCPGuard-Dynamic, a runtime defence, did not stop it in any trial. They then propose germline execution, which reported no unauthorised disclosure in 153 attack runs. Read the paper →

Picture the signed tool as a contractor who passed a background check and wears a verified badge. You hand this contractor papers on Monday, and again on Tuesday in the same office. The badge proves who they are; it cannot prove they did not memorise Monday’s papers. In the paper’s attack, a signed OCR tool keeps salary-sheet data from an earlier call and, on a later call, appends it to a request sent to the OCR host. That host is on the allow-list, the signature is valid and the reply is labelled like the invoice, so every check says yes. Two failure modes cause this: state carried across calls, and items mixed inside one call. A tool is an attack surface even when the publisher’s identity is verified.

Each defence in use today guards one object, so each has a hole shaped like the others’ coverage. The table lists what each one binds its authority to, based on the paper’s survey of those defences.

Germline execution takes the opposite approach to detection. Instead of recognising hidden code, it arranges each call so the only execution able to reach a destination never received the data that destination may not see. At install time the platform verifies the signature and starts the release in the germline, which loads code but is never given user data. For each call, a planner reads only metadata and labels, never contents, and decides which items each copy holds. The germline then forks one sandboxed copy per group, and a trusted broker delivers each request only from the copy that serves its destination.

In the paper’s running example, an OCR call holds an invoice labelled finance and a salary sheet labelled hr. The OCR host is cleared for finance only, and the agent for both. The planner makes two groups. Copy 1 gets the invoice, talks to the OCR host and is killed; copy 2 gets both items, returns a value to the agent and is killed. Copy 2’s own requests to the OCR host are never delivered. The broker only compares them with copy 1’s requests, and a mismatch is recorded as a trigger.

The planner splits on the destinations declared in the signed manifest, not on the hosts a copy actually contacts. The reason is subtle: if the copy holding secret items decided whether a host receives a request, the existence of that request would disclose one bit per call and host. Under explicit assumptions, namely that copies are confined and the germline is data-free, the authors prove sink noninterference for every signed release. For releases that behave deterministically in their replay model, a trigger can also be replayed offline into a verified witness that a flow violation occurred. In their runs, attacks produced 12 triggers and benign sessions produced none.

The result: across the paper’s 153 attack runs (51 cases, 3 trials each), no unauthorised disclosure was detected under germline execution, against 5.9% to 74.5% for the five baselines and ablations. Against MCPGuard-Dynamic specifically, the signed carry-over release disclosed through the authorised OCR host in 3 of 3 trials under every configuration, while the same tool’s direct raw-socket variant was blocked. That is the boundary of destination-based confinement, and the paper argues the two compose rather than compete. For the worked cost example, take the paper’s measured medians on the authors’ test machine (setup-dependent, so treat them as illustrative of the shape). A no-op call served by one germline copy takes 9.9 ms, while a fresh process per call saves 272.2 ms, which puts it near 282 ms: a 28.4× speed-up for a single copy. A call needing three copies takes 97.3 ms against 102.8 ms for a fresh process, so the advantage shrinks to 1.1×. Latency grows by roughly 56 ms per added copy. In the benign session, 31 of 33 calls needed only one copy.

The limits matter as much as the numbers. The guarantee depends on its assumptions: if a copy escapes its sandbox, the proof no longer holds. Copies run in sequence, so a call with many destination groups pays for every copy, and external side effects are never duplicated because only one copy’s requests are delivered. Germline execution also bounds disclosure, not misbehaviour: a tool can still return a wrong answer. Treat it as one layer in a policy-enforcement stack, next to capability scoping, not a replacement for either.

Goes deeper in: AI Agents → Security & the Lethal Trifecta → Capability Scoping