{"slug": "finally-mcp-s-tool-poisoning-gap-solved-a-protocol-level-defense", "title": "Finally MCP's Tool Poisoning Gap Solved: A Protocol-Level Defense", "summary": "A new protocol-level defense against tool poisoning in the Model Context Protocol (MCP) has been proposed, using signed tool manifests to detect unauthorized changes to tool descriptions between approval and reconnect. The proposal, submitted by RajSidwadkar, addresses a known security gap and includes a working reference implementation. Community feedback suggests combining this with runtime execution records for end-to-end tamper-evidence.", "body_md": "# Signed tool manifests : additive extension for tool-poisoning / \"rug pull\" defense #2913\n\n[RajSidwadkar](/RajSidwadkar)started this conversation in\n\n[Ideas - Security](/modelcontextprotocol/modelcontextprotocol/discussions/categories/ideas-security)\n\n-\n\n## 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\nThe demo signs a tool manifest, then simulates a server silently editing a ## Looking for feedback on\nPosting here first before considering a formal SEP draft, happy to adjust |\n\nBeta\nWas this translation helpful?\n[Give feedback.](#)\n\n## Replies: 1 comment 10 replies\n\n-\n\n|\nSigned 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. |\n\nBeta\nWas this translation helpful?\n[Give feedback.](#)", "url": "https://wpnews.pro/news/finally-mcp-s-tool-poisoning-gap-solved-a-protocol-level-defense", "canonical_source": "https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2913", "published_at": "2026-06-19 01:23:53+00:00", "updated_at": "2026-06-19 01:30:37.353591+00:00", "lang": "en", "topics": ["ai-safety", "ai-tools", "ai-infrastructure"], "entities": ["Model Context Protocol", "MCP", "RajSidwadkar", "Ed25519"], "alternates": {"html": "https://wpnews.pro/news/finally-mcp-s-tool-poisoning-gap-solved-a-protocol-level-defense", "markdown": "https://wpnews.pro/news/finally-mcp-s-tool-poisoning-gap-solved-a-protocol-level-defense.md", "text": "https://wpnews.pro/news/finally-mcp-s-tool-poisoning-gap-solved-a-protocol-level-defense.txt", "jsonld": "https://wpnews.pro/news/finally-mcp-s-tool-poisoning-gap-solved-a-protocol-level-defense.jsonld"}}