[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?
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.