MCP messages pass through the gateway unsigned — MCPS as a signing layer

[razashariff]

The gateway routes MCP traffic between agents and servers but doesn't verify the integrity of the messages passing through. Specifically:

• Tool definitions from upstream servers are forwarded without schema validation — a compromised upstream passes poisoned descriptions to the agent
• Tool call parameters aren't signed — anything between the gateway and the server could modify the payload
• No replay protection on tool calls

Since the gateway is the natural interception point, it's the ideal place to add message signing. MCPS (MCP Secure) provides this as an IETF Internet-Draft: draft-sharif-mcps-secure-mcp

MCPS adds per-message ECDSA signing, tool hash-pinning, and nonce-based replay rejection. Available on npm and PyPI. A managed proxy implementation with Defender + Sentinel integration is live at mcpsaas.co.uk.

OWASP MCP Top 10 covers this under MCP-01 and MCP-10: owasp.org/www-project-mcp-top-10

[willamhou]

Client-side and gateway-side signing solve different problems — worth being explicit about which threat model this issue targets.
Client-side (what Signet does): proves agent X sent request Y with params Z. The signature travels with the message through the gateway. Protects against impersonation and param tampering upstream of the gateway.

Gateway-side: proves the message transited the gateway at time T in a specific form. Protects against tampering between gateway and server.

These chain naturally. Signet injects signing metadata into params._meta._signet — a gateway interceptor could read that field, verify the client signature, then append its own. The result is a two-layer proof: origin + transit.
If the gateway is defining a signing metadata schema, we'd want to coordinate field naming to keep them interoperable.