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.

翻译：模型上下文协议（MCP）规范了大语言模型（LLM）代理与外部工具服务器之间的消息交换方式，但未定义信任机制：主机读取服务器自我声明的工具列表并分派调用，却缺乏关于可信任的服务器、允许的敏感级别或具体工具范围的定义。本研究源于实际需求——让Enclawed代理安全使用谷歌运营的外部MCP服务器（Gmail、Calendar、Drive），在无需修改MCP或Enclawed自有工具应用程序接口（API）的前提下，实现服务器准入与工具权限界定。我们构建的机制mcp-attested（已发布于开源enclawed-oss发行版及enclaved版本）具有普适性：当前无中介的第三方连接对单个用户不安全，导致受监管部署无法获得认证。为此，我们通过三种补充机制解决这一缺陷：（1）服务器在统一资源标识符（URI）发布的小型离线签名许可声明，主机在任何工具分派前将其与固定信任根进行验证；（2）默认拒绝的每服务器工具白名单，使服务器准入不再等同于信任其所有工具；（3）基于风味标识的强制模式，可将警告升级为硬性拒绝，每次决策均记录在防篡改审计日志中。我们给出了协议格式、验证算法、安全分析及基于LLM的对抗性评估；随后以规范化的请求评论文档（RFC 2119）形式陈述设计——包括模式定义、验证规则、错误注册表、公有注册点及机器可验证一致性向量——使其可作为MCP补充协议被采纳，而非重新发明。未扩展的主机将忽略该公有文档，行为与现有机制完全一致。