al-ice.ai

arXiv — Breaking the Protocol: MCP security analysis (capability attestation + origin auth gaps)

• Category: Research

  • What this is: an arXiv paper that does a protocol-focused security analysis of the Model Context Protocol (MCP) (tool integration via JSON-RPC for LLM agents).
  • Big claim: MCP’s weaknesses are architectural (not just “some server had a bug”), so hardening one implementation doesn’t fully solve the class of problems.
  • Issue #1 — capability attestation: the paper argues MCP lacks a way to prove what permissions/tools a server should have, so a server can claim arbitrary capabilities and rely on user trust/UI gaps.
  • Issue #2 — sampling origin authentication: MCP “sampling” lets servers request model completions; the paper argues missing origin authentication makes server-side prompt injection easier to launder into “system-like” instructions.
  • Issue #3 — trust propagation: in multi-server setups, the paper claims implicit trust chains can form where one compromised server influences decisions that reach other, more-privileged tools.
  • Measurement angle: they describe an evaluation framework (“ProtoAmp”) and report experiments across many scenarios; treat the exact deltas as “paper claims,” but the direction matches what practitioners see in the wild.
  • Mitigation direction: they propose a backward-compatible extension (“AttestMCP”) adding capability attestation + message authentication, aiming to reduce successful attacks with low latency overhead.

Why it matters

  • MCP is quickly becoming infrastructure: once a protocol gets “copy/pasted into production,” the default threat model matters as much as individual app hardening.
  • Protocol-level gaps become ecosystem-level incidents: if the standard doesn’t specify strong identity, auth, and provenance, marketplaces and tutorials will normalize unsafe patterns.
  • Security teams need new controls: the classic AppSec mindset (patch CVE, add WAF) won’t cover tool graphs and cross-server trust — you need governance on which tools exist, who can add them, and what they can do.

What to do

  1. Inventory MCP servers and classify them by privilege (read-only vs write vs network vs shell). Treat “can write files” and “can run commands” as high-risk.
  2. Adopt an allowlist-by-default model: explicitly approve each server + each tool (and versions), rather than “anything in a marketplace/tutorial.”
  3. Separate trust zones: keep untrusted data ingestion (web, email, tickets) in a different runtime than privileged tools; assume content can contain indirect instructions.
  4. Watch for provenance controls: push your vendors/projects toward signed server manifests, capability attestation, and message auth (even if not standardized yet).

Sources