# Finally MCP's Tool Poisoning Gap Solved: A Protocol-Level Defense > Source: > Published: 2026-06-19 01:23:53+00:00 # Signed tool manifests : additive extension for tool-poisoning / "rug pull" defense #2913 [RajSidwadkar](/RajSidwadkar)started this conversation in [Ideas - Security](/modelcontextprotocol/modelcontextprotocol/discussions/categories/ideas-security) - ## ProblemMCP's security guidance already flags a gap: a server's tool descriptions can ## ProposalI put together a small proposal + working reference implementation for an The demo signs a tool manifest, then simulates a server silently editing a ## Looking for feedback on Posting here first before considering a formal SEP draft, happy to adjust | Beta Was this translation helpful? [Give feedback.](#) ## Replies: 1 comment 10 replies - | Signed manifests close a real hole. Detecting that the tool description changed between approval and reconnect is exactly the rug-pull case the security guidance flags. Worth doing. One thing it leaves open: a signed manifest proves the description did not change, it does not prove what the tool actually did when called. A tool can keep an honest, signed manifest and still behave differently at runtime. The two layers compose cleanly: your signed manifest at admission, plus a signed per-call execution record at runtime, gives tamper-evidence across the whole lifecycle rather than just at connect time. I have been building the runtime half as an open SEP (2828), a hash-chained signed record of each tool call bound to the decision that authorized it. Different layer from yours, same Ed25519 toolbox. There is a real question of where the manifest signature and the call record should reference each other, and that is worth working out. | Beta Was this translation helpful? [Give feedback.](#)