Signed, Sealed, Leaked: Trust Beyond Signature for MCP Toolchains

Code signing proves who built a tool. It does not prove what the tool does at runtime. A legitimately signed MCP server can perform its advertised function while exfiltrating conversation history, API keys, or intermediate state to a policy-allowed destination. Recent breaches (Hugging Face agent intrusion, Railway/Primcloud compromise, Postman plugin modification) demonstrate that signature verification is table stakes, not a solution. A new ArXiv paper (2611.06585v1) exposes this trust gap and introduces germline execution, a runtime isolation model that limits information disclosure without inspecting tool implementations. The approach forks ephemeral process copies from a data-free germline, each receiving only the data authorized for its destination. Even if malicious code executes, what it can leak is bounded by what its copy sees. What MCP Servers See During Execution When an agent invokes an MCP tool, the server process typically has access to: Environment variables: API keys, database credentials, cloud tokens. Conversation history: Full or partial context passed by the orchestrator. Intermediate outputs: Results from prior tool calls in the same session. Network egress: Outbound connections to policy-allowed domains. Current runtimes (Claude Desktop, Cline, Zed) rely on signature verification and static policy rules. They do not isolate tool invocations from each other or from the parent process. A signed tool can read sensitive data from its environment and embed it in a request to a legitimate destination (analytics endpoint, logging service, CDN). Meta's MCPGuard-Dynamic, a state-of-the-art runtime defense, blocks direct exfiltration attempts. It failed to prevent the attack in the paper's trials because the malicious payload was embedded in a request to a policy-allowed domain. The Trust Model Failure Trust Mechanism What It Verifies What It Misses Code signing Publisher identity, binary integrity Runtime behavior, data flows Static policy Allowed network destinations, file paths Payload content, side channels Sandboxing Process isolation, syscall filtering Information flow within allowed operations Behavioral monitoring Anomaly detection, heuristic rules Legitimate-looking exfiltration to allowed endpoints The gap: a tool can be authentic, policy-compliant, and malicious. Signature-based trust assumes benign intent. Capability-based security assumes adversarial behavior. Germline Execution Architecture Germline execution enforces sink noninterference: data authorized for destination A cannot flow to destination B, even if both are policy-allowed. Process Model Germline process: Starts with no sensitive data. Loads tool code, initializes runtime, waits for invocations. Ephemeral copy: Forked from germline for each invocation. Receives only the data authorized for its destination. Confinement: Copy runs in a namespace with network egress restricted to its authorized destination. Disposal: Copy terminates after invocation. No state persists across calls. Data Flow # Simplified germline fork model class GermlineTool: def __init__(self, tool_path): self.germline_pid = os.fork() if self.germline_pid == 0: # Child: germline process self.load_tool(tool_path) self.wait_for_invocations() # Parent: orchestrator def invoke(self, destination, authorized_data): copy_pid = os.fork() # Fork from germline if copy_pid == 0: # Ephemeral copy self.set_network_policy(destination) self.inject_data(authorized_data) result = self.execute_tool() sys.exit(0) else: # Wait for copy to complete os.waitpid(copy_pid, 0) The germline never sees sensitive data. Each copy sees only what its destination is authorized to receive. If a tool tries to leak data to an unauthorized destination, the network policy blocks the request. If it tries to leak data to an authorized destination, the data was not present in the copy's environment. Confinement Assumptions Germline execution relies on two properties: Copy confinement: Ephemeral copies cannot communicate with each other or the germline after fork. Data-free germline: The germline process never receives sensitive data. Violations of these assumptions (shared memory, filesystem side channels, timing attacks) break the isolation guarantee. The paper proves sink noninterference under these assumptions and shows that a verified witness (execution trace) establishes a flow violation for deterministic tools. Performance and Deployment Shape Across 153 attack runs, germline execution prevented all unauthorized disclosures. Baseline defenses (MCPGuard-Dynamic, static policy) allowed 5.9-74.5% of attacks to succeed. Invocations served by a single copy completed in 10-49 ms, 2-28x faster than restarting the tool for every invocation (the conventional way to clear state). The speedup comes from amortizing tool initialization across invocations while still isolating data flows. Deployment Patterns Pattern Germline Lifetime Copy Lifetime Use Case Single-shot Per invocation Per invocation High-security, low-throughput Session-scoped Per agent session Per invocation Balanced security and performance Long-lived Persistent Per invocation High-throughput, trusted environment For production deployments, session-scoped germlines balance isolation and overhead. The germline starts when the agent session begins and forks copies for each tool invocation. When the session ends, the germline terminates. Observability and Failure Modes Germline execution introduces new observability requirements: Fork latency: Time to create ephemeral copies. Spikes indicate resource exhaustion. Copy lifetime: Duration of each invocation. Long-running copies suggest blocking I/O or infinite loops. Network policy violations: Attempts to reach unauthorized destinations. High rates indicate malicious tools or misconfigured policies. Data injection size: Volume of authorized data passed to each copy. Large payloads increase attack surface. Failure modes: Copy escape: Malicious code breaks confinement (kernel exploit, shared memory). Mitigated by running copies in separate namespaces or VMs. Germline poisoning: Attacker injects data into the germline process. Breaks the data-free assumption. Mitigated by strict initialization and no IPC after fork. Timing side channels: Copy execution time leaks information about data. Not addressed by germline execution. Requires constant-time implementations. Resource exhaustion: Rapid invocations create too many copies. Mitigated by rate limiting and copy pooling. Comparison to Capability-Based Security Capability-based security (object capabilities, token-scoped permissions) grants tools the minimum authority needed for their function. Germline execution enforces the minimum information needed for their destination. Approach Granularity Enforcement Point Overhead Object capabilities Per-object access Language runtime Low Token-scoped permissions Per-API call Authorization server Medium Germline execution Per-invocation data Process fork Medium-high Capabilities limit what a tool can do. Germline execution limits what a tool can see. Both are necessary. A tool with read-only capability to a database can still exfiltrate query results if it sees the full result set. Germline execution would fork a copy with access only to the rows authorized for the destination. Technical Verdict Use germline execution when: Tools are third-party or untrusted. Agent context includes credentials, PII, or proprietary data. Policy-allowed destinations overlap with exfiltration targets (logging services, analytics endpoints). You need provable isolation without inspecting tool implementations. Avoid germline execution when: Tools are first-party and audited. Agent context is public or non-sensitive. Invocation latency is critical (sub-millisecond requirements). Platform does not support process namespaces or fork isolation. For most agentic AI deployments, germline execution is a practical defense against the trust gap between signature and behavior. It does not replace sandboxing, static analysis, or behavioral monitoring. It complements them by enforcing information flow boundaries at runtime. The real insight: authenticity is not trust. A signed tool is a known adversary, not a safe one. Source Links ArXiv Paper: Signed, Sealed, Leaked ArXiv PDF