🤖 AI Summary
This work addresses the lack of a trust mechanism for third-party tool servers in the Model Context Protocol (MCP) and its susceptibility to unauthorized invocations. We propose the first security extension that requires no modifications to the existing protocol or APIs. Our approach introduces offline-signed admission assertions, server-level tool allowlists, and configurable enforcement policies ranging from warnings to outright rejection. Security and consistency are ensured through URI-distributed signed assertions, pinned trust root verification, tamper-resistant audit logs, and machine-verifiable test vectors. The solution has been integrated into the enclawed-oss and enclaved distributions and validated through formal security analysis and LLM adversarial evaluation. The resulting specification conforms to RFC 2119 and is ready for direct adoption as an MCP appendix.
📝 Abstract
The Model Context Protocol (MCP) standardizes how a large-language-model (LLM) agent and an external tool server exchange messages, but not trust: a host reads a server's self-declared tool list and dispatches calls, with no notion of which servers it may use, at what sensitivity, or which of a server's tools are in bounds. This work grew out of a concrete need -- letting the Enclawed agent use Google's externally-operated MCP servers (Gmail, Calendar, Drive) safely, admitting the server and bounding the tools it may drive, without changing MCP or Enclawed's own tool application-programming interface (API). The mechanism we built, mcp-attested (shipped in both the open enclawed-oss distribution and the enclaved flavor), generalizes: the gap that makes an unmediated third-party connection unsafe for one user makes a regulated deployment impossible to accredit. We close it with three additive mechanisms: (1) a small, offline-signed clearance assertion a server publishes at a well-known Uniform Resource Identifier (URI) and a host verifies against a pinned trust root before any tool dispatch; (2) a deny-by-default per-server tool allowlist, so admitting a server is not trusting its every tool; and (3) a flavor-gated enforcement mode that turns the checks from warnings into hard denials, with every decision written to a tamper-evident audit log. We give the wire format, the verification algorithm, a security analysis, and an LLM-driven adversarial evaluation; we then state the design in normative Request-for-Comments (RFC 2119) form -- schema, verification rules, error registry, well-known registration, and machine-checkable conformance vectors -- so it can be adopted as an MCP addendum rather than reinvented. An unextended host ignores the well-known document and behaves exactly as today.