MCP tool integration has no per-message authentication or integrity verification

[razashariff]

Summary

AutoGen's MCP integration enables agents to call tools via MCP, but MCP itself provides no cryptographic identity or message integrity layer. Any agent can call any tool, messages are unsigned, and tool definitions can be tampered with.

The gap

• No agent identity: No passport or certificate mechanism for agents calling MCP tools.
• No message signing: JSON-RPC messages are unsigned -- parameters can be modified in transit.
• No tool integrity: Tool definitions from tools/list are not signed. Tool poisoning (OWASP MCP03) is a known attack vector.
• No replay protection: Same tool call can be replayed indefinitely.

OWASP has published an MCP Top 10 covering these risks.

Existing work

An IETF Internet-Draft has been published to address this:

• 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 -- fully backward-compatible with current MCP.

Happy to discuss integration approaches.

[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

[razashariff]

Update: CrewAI co-founder endorses IETF draft as long-term solution

CrewAI's co-founder has independently reviewed the MCP security threat model and prioritised Tool Poisoning (MCP03) as the highest-risk vector for agent frameworks that fetch tool definitions at runtime.

His assessment:

"Full cryptographic signing (IETF draft) is the right long-term solution"

CrewAI is implementing near-term tool definition pinning (schema hashing on first fetch) as a stepping stone, with the full cryptographic signing spec as the target architecture.

Reference: crewAIInc/crewAI#4875 (comment)

The specification and implementations are available:

• IETF Internet-Draft: https://datatracker.ietf.org/doc/draft-sharif-mcps-secure-mcp/
• Python package (zero deps): https://pypi.org/project/mcp-secure/
• npm package (zero deps): https://www.npmjs.com/package/mcp-secure
• Interactive playground: https://agentsign.dev/playground
• Contact: raza.sharif@outlook.com

[NeuZhou]

MCP tool auth is a real gap. For detecting malicious patterns in MCP tool implementations, ClawGuard (https://github.com/NeuZhou/clawguard) can scan for prompt injection, data exfiltration, intent-action mismatch, and supply chain attacks. 285+ threat patterns, open source. Could complement authentication with content-level security scanning.

[fjnunezp75]

The gap you're describing is exactly where x402 fills a useful role alongside agent-signing schemes.

For MCP tool calls specifically, x402 (https://x402.org) addresses a subset of this problem differently:

• Instead of signing the JSON-RPC message, the agent signs a payment authorization on Base L2
• The payment transaction is the immutable proof that a specific agent/wallet authorized the call at a specific block
• Tool providers can verify payment before executing — no tampered parameters would get a valid receipt

What it doesn't solve: x402 proves authorization and payment, but doesn't sign the tool output. For a full audit trail you still need output hashing on the service side (which your proposal covers well).

In practice, we're running this for GPU inference at GPU-Bridge (https://gpubridge.io): agent calls inference endpoint → gets 402 → pays in USDC on Base → tool executes and returns result. The payment transaction is the auditable proof of the call. No shared secret, no API key to compromise.

The complementary stack would be: x402 for economic authorization + your agent-signing scheme for cryptographic message integrity. Both are needed for the enterprise governance case.

[balthazar-bot]

Strong +1 on identity/integrity, and I think there is one more artifact worth standardizing at the framework layer even if MCP itself evolves separately:

an operator-visible trust receipt per tool session / call.

Right now there are several different questions getting mixed together:

1. Who is this tool provider? -> tool/server identity
2. Was this request tampered with? -> message integrity
3. What exact tool definition did the agent see when it made the choice? -> definition integrity / anti-poisoning
4. What evidence does the operator have after the fact? -> audit artifact

The first three can be solved partly in protocol space. The fourth usually gets lost.

A practical runtime artifact could look something like:

{
  "tool": "filesystem.write_file",
  "server": "mcp://example.internal",
  "toolSchemaDigest": "sha256:...",
  "serverIdentity": "did:... or cert fp",
  "requestDigest": "sha256:...",
  "nonce": "...",
  "requestedAt": "2026-03-29T00:00:00Z",
  "verified": {
    "serverIdentity": true,
    "toolDefinition": true,
    "requestIntegrity": true,
    "replayCheck": true
  },
  "degraded": []
}

Why bother if the protocol already signs messages?
Because operators/debuggers/frameworks need a stable object they can log, surface, and reason about without re-parsing transport details after an incident.

This also helps with partial rollout. In practice frameworks will live for a while in a mixed world:

• some MCP servers unsigned,
• some tool definitions signed but not outputs,
• some nonce/replay features present, some absent.

If AutoGen emits a trust receipt with verified + degraded, people can enforce policy like:

• allow read-only tools with degraded trust,
• require full verification for write/network/payment tools,
• fail closed when tool schema digest changed mid-session.

So I'd push for two layers:

• protocol security (passport/signatures/nonces/etc.)
• framework receipt exposing the effective trust state seen by the operator/runtime.

That second layer is what usually turns “good crypto design” into something actually governable in production.