MCP protocol itself lacks per-message signing and agent identity

[razashariff]

Summary

This repo provides MCP servers for Google security products, but MCP itself -- the underlying protocol -- has no cryptographic identity or per-message signing layer. This means the security tools themselves are delivered over an insecure protocol.

Protocol-level gaps

• No agent identity: Any client connecting over MCP can call security tools. There is no mechanism to verify which agent is making the request.
• No message signing: JSON-RPC messages are unsigned. Parameters (including security-sensitive queries) can be modified in transit.
• No tool integrity: Tool definitions are not signed by their author. An attacker could modify tool descriptions via tool poisoning (OWASP MCP03).
• No replay protection: Security tool calls can be replayed.

For security-focused MCP servers specifically, this is a significant concern -- the tools meant to improve security are themselves delivered without integrity guarantees.

Existing work

An IETF Internet-Draft has been published addressing MCP security at the protocol level:

• IETF Datatracker: https://datatracker.ietf.org/doc/draft-sharif-mcps-secure-mcp/
• Reference implementations: npm / PyPI (zero dependencies)
• Interactive demo: https://agentsign.dev/playground

The spec adds agent passports (ECDSA P-256), per-message signing, tool definition signatures, and nonce-based replay protection as an envelope around existing JSON-RPC -- fully backward-compatible.

Happy to discuss technical details.

[razashariff]

Update: Real-world MCP security incidents now documented

Since filing this issue, multiple real-world MCP security incidents have been publicly disclosed:

• CVE-2025-6514 (CVSS 9.6) -- mcp-remote RCE via crafted OAuth URL. 437,000+ downloads affected.
• CVE-2025-49596 (CVSS 9.4) -- Anthropic MCP Inspector unauthenticated RCE. 38,000 weekly downloads.
• CVE-2025-68145/68143/68144 -- Anthropic mcp-server-git chain. Full RCE via path bypass + git_init + argument injection.
• Smithery.ai breach -- Path traversal exposed 3,243 MCP servers and thousands of API keys.
• Asana cross-tenant leak -- MCP server bug exposed ~1,000 customers' data across organisations for 34 days.
• postmark-mcp backdoor -- First malicious MCP server in the wild. BCC'd every email to attacker.

The full specification for addressing these at the protocol level is now an IETF Internet-Draft:
https://datatracker.ietf.org/doc/draft-sharif-mcps-secure-mcp/

Interactive playground (no install): https://agentsign.dev/playground

[0xbrainkid]

This issue captures the fundamental architecture gap well. MCP inherited the "trusted local process" assumption from language server protocol (LSP), but agents operate in adversarial, cross-organizational environments. The protocol's security model doesn't match its deployment reality.

Building on @razashariff's CVE roundup — the 30+ CVEs filed in 60 days (Jan-Mar 2026) cluster into patterns that all trace back to the identity gap:

1. Tool poisoning (OWASP MCP03) is an identity problem.
If agents could verify tool publisher identity and integrity, poisoned tool descriptions would be detectable. The fix isn't just signing tool definitions — it's establishing a chain of trust from publisher → registry → agent → operator.

2. The "security tools on an insecure protocol" irony is worse than it looks.
When a SOC agent calls a security tool via MCP, the tool call itself is an attack surface. An attacker who can intercept the MCP connection can modify the query ("scan this IP" becomes "scan our own infrastructure") or replay authorization decisions. Per-message signing is the minimum — but signing without identity just proves message integrity, not message authority.

3. The OWASP AISVS already addressed this.
OWASP's AI Security Verification Standard (AISVS) merged C10 requirements in March 2026 (PR #608) that include:

• C10.2: Key-based identity for autonomous agents (mTLS, signed JWTs with proof-of-possession)
• C10.3: Per-message cryptographic signing over canonicalized payload
• C10.4: Application-layer replay protection (nonce + timestamp)
• C10.6: Fail-closed semantics on security control failure

These are testable controls Google's MCP servers could implement today, independent of protocol-level changes.

4. Cross-org agent identity is the harder problem.
Within Google's infrastructure, agent identity can be solved with Workload Identity Federation or SPIFFE SVIDs. But MCP is an open protocol — third-party agents calling Google security tools need cross-organizational identity verification. This requires:

• Verifiable agent identity that persists across organizations
• Behavioral trust scoring (not just credential validation)
• Temporal trust decay (last month's verification ≠ today's trust)

The MCP protocol spec team has started addressing pieces of this — SEP-2468 (issuer claims), SEP-2385 (tool auth manifest), SEP-2061 (action security metadata) — but the identity layer is still the critical gap.

Practical path forward for this repo: Add an agent identity verification middleware that checks trust claims before executing any security tool call. Accept signed JWTs from multiple trust providers (SPIFFE, SATP, AIP, etc.) and enforce minimum trust thresholds per tool sensitivity level.