Feature request: MCP message signing and tool integrity verification

[razashariff]

As MCP adoption grows, the protocol's lack of a built-in security layer becomes a concern for production deployments. This project's MCP integration currently has no mechanism for:

• Message signing — tool calls between agent and server travel unsigned, so a proxy or MITM can modify parameters without detection
• Tool integrity verification — tool definitions can mutate post-deployment (rug pulls) with no hash-pinning to detect changes
• Cryptographic agent identity — agents are identified by bearer tokens or API keys, not unforgeable cryptographic identity
• Replay protection — captured MCP messages can be resent without nonce or timestamp binding to reject them
• Mutual authentication — server responses are not signed, so clients cannot verify response integrity

This isn't unique to this project — it's a gap in MCP itself. We built MCPS (MCP Secure) to close it:

• ECDSA P-256 agent identity passports with trust levels (L0-L4)
• Per-message signing with nonce + timestamp + passport binding
• Tool definition hash-pinning (detects poisoning and post-deployment mutations)
• Replay protection, real-time revocation, mutual authentication
• Zero dependencies, drop-in middleware — npm install mcp-secure

MCPS is published as an IETF Internet-Draft and has been tested with 180 security tests across 19 attack categories.

• GitHub | npm: mcp-secure
• Live interactive demo — 7 scenarios including replay attacks, tool poisoning, signature stripping
• agentsign.dev — free security scanner at agentsign.dev/scan

Happy to discuss integration or answer questions.

[dataCenter430]

Hi, @razashariff thanks for reporting this.
I'd love to take this as a contributor.
Please assign it to me, if needed.
Thank you.
cc: @ntindle

[ntindle]

We don't typically assign tickets but please feel free to work on it. I've not considered or accepted the ticket just so you are aware.

[dataCenter430]

thanks for your response, 👍
okay, I'm on it. Could you let me know who can review the PRs, so I can tag him/her?

[ntindle]

You will automatically be assigned a reviewer when the pr is opened :)

[razashariff]

@dataCenter430 great progress on #12455 -- saw the CI failures and the envelope format issue flagged by the reviewers. A few quick fixes that should unblock it:

1. Envelope keys: mcp-secure uses mcps (no underscore) and message (not payload). Update client.py to match: "mcps" in body and body["message"]

2. Hard vs optional dep: Move mcp-secure to an extras group in pyproject.toml (e.g. [tool.poetry.extras] mcps = ["mcp-secure"]) -- that way the try/except pattern makes sense

3. Duplicated setup: Extract the MCPS context creation into security.py as a try_create_security_context() function -- both block.py and run_mcp_tool.py can call it

Happy to help if you want me to walk through any of these.

[dataCenter430]

Thanks for your concern, @razashariff 👍
Then I think my current implementation is good based on the analysis of codebase.
And I'm getting the CI testing failures for my PR. I'm not sure the reasons exactly.
Could you please check the latest change for the implementation, if you want? 🙏
Thank again.

[razashariff]

@dataCenter430 took a look at the latest changes -- solid work. The structure looks good. One thing to double check: make sure the envelope key names in client.py match what mcp-secure actually outputs (mcps not _mcps, message not payload). That was the main thing the automated reviewers flagged. Other than that, looking clean. Good work indeed.

[dataCenter430]

Thanks for your feedback, you're professional.
okay, I got it. Thanks