MCP 需要一次信任握手:基于证明的工具服务器准入

这是什么?

2026 年 5 月 22 日,Alfredo Metere 在 arXiv 上发布了论文 Attested Tool-Server Admission: A Security Extension to the Model Context Protocol(2605.24248,cs.CR)。该工作源于一个具体的运维需求 —— 让 Enclawed agent 能够安全地连接到 Google 的外部 MCP 服务器(Gmail、Calendar、Drive),而不必在”盲信”和”全拒”之间二选一 —— 并将其泛化为对协议一个干净的、向后兼容的附加项。

论文的论点从对今天 MCP 的一个结构性观察出发:协议规范了 LLM host 和工具服务器如何交换消息,但没有任何关于 host 可以使用哪些服务器、敏感度如何或服务器的哪些工具处于边界内的原生概念。host 读取服务器自声明的工具列表并直接分发调用。这正是未经中介的第三方连接所继承的信任模型,也正是让今天的受认证部署事实上不可能的那个缺口。

论文提出三个小幅添加,以规范性的 RFC 2119 形式表述,以便能够作为 MCP 附录被采纳,而不是被重新发明。它在 NSA AISC 文件 Model Context Protocol: Security Design Considerations for AI-Driven Automation 发布两天后出现 —— 两份文档从协议栈的两端得出了相同的结论。

工作原理

mcp-attested 在 MCP 握手中增加三层检查。不知晓该 well-known 文档的未扩展 host 会直接忽略它,行为与今天完全相同 —— 该设计严格是加法性的。

机制                          所在位置                              所限制的对象
---------------------------  ----------------------------------  --------------------------
Signed clearance assertion   服务器的 well-known URI              服务器准入
Per-server tool allowlist    host 配置,deny-by-default          逐工具的分发
Flavor-gated enforcement     host 运行时模式                       Warn 与 hard-deny

签名的准入断言。 每个 MCP 服务器在一个 well-known URI 上发布一份离线签名的小文档。host 在分发任何工具调用之前,根据一个 pinned 的信任根验证该断言。服务器不再凭”实现了 MCP”被准入,而是因为 host 预先决定承认的某个信任根在某个准入等级上为它做了背书。

逐服务器的默认拒绝白名单。 准入一个服务器并不等于信任它的每个工具。host 为每个被准入的服务器配置它愿意分发的工具显式子集。任何不在白名单中的工具都被拒绝,根本不会到达模型的工具选择步骤 —— 这就把”模型本身推理是否调用工具”这一最慢、最昂贵的防御层完全绕过。

两种风味的强制模式。 同样的检查可以运行在 warning 风味(记录并放行)或 enforcing 风味(记录并拒绝)。受监管的部署可以在没有运维兜底的情况下以 enforcing 风味交付;开发模式的部署可以在团队整理白名单期间保持 warning。每个决定 —— admit、deny、warn —— 都写入一份防篡改的审计日志,使分发决定事后可复审。

论文还附带线协议格式、验证算法、安全分析和一项由 LLM 驱动的对抗性评估。另一条独立的工作线 MCPShield (arXiv:2602.14281)(2026 年 2 月发布)采取互补的认知层方法 —— 调用前的元数据引导探测、调用中的隔离投影、调用后的周期性推理 —— 与本文一起阅读最有用,而不是当作对立面。

为什么重要

业界在过去十八个月里艰难前行的 MCP 威胁模型把 host 当作信任权威,把模型当作守门员。两种选择都错,而且错在不同的方向。host 在协议层面对服务器的身份没有抓手。而模型并不是一个安全边界 —— 它是一个对下一个 token 做概率预测的预测器,可以被劝说放弃拒绝。

不堵这个洞的 MCP 特定后果到现在已经被记录得相当清楚。NSA AISC 在 2026 年 5 月 20 日的 CSI 中编目了八类弱点,包括能力伪装的服务器和未认证的工具注册。公开报告 —— Invariant Labs 的 WhatsApp MCP 与 GitHub MCP 发现,2026 年春季的 MCP 后端 CVE 浪潮 —— 已经表明,恶意或被攻陷的服务器可以把例行的工具分发变成数据外泄或文件系统破坏。这些事件没有一个需要一个巧妙的 prompt;它们只需要 host 听信服务器一面之词。

mcp-attested 的有趣之处在于,它把信任决定彻底从模型中拉出来。模型永远不会”选择”去分发到一个未经证明的服务器,因为 host 的分发路径在模型的工具选择运行之前就已经拒绝。这与 TLS 的握手前决定形状相同:应用代码无权”考虑”连接到一个证书无效的服务器。

代价是少量新增的运维工作 —— 维护一个 pinned 的信任根、维护逐服务器的白名单、分发签名的准入文档。论文的主张 —— 在最近一波 MCP CVE 之后听起来正确 —— 是这就是能够认证一个 MCP 部署所必须付的成本。

防御

即使您的技术栈不会逐字采纳 mcp-attested,论文中仍有四点值得借鉴。

1. 为 MCP 服务器固定一个信任根,并拒绝其他。 即便没有正式的准入模式,host 运行时也可以随发行版附带一份指纹清单,凡不在清单内的连接都产生硬错误,而不是默默忽略。
2. 把逐服务器的白名单做成默认,而不是 opt-in。 把”这个服务器暴露了一个我没有枚举过的工具”当作部署缺陷,而非使用事件。host 实际会分发的工具集合应当是显式的、可版本化的。
3. 把 warning 模式和 enforcing 模式分开,并从第一天起就交付审计日志。 即便是开发用 MCP host,也应当把每次准入和分发决定写入一份防篡改的日志。绝大多数生产事故都是从事发当时还不存在的日志中重建的。
4. 把这篇论文与 NSA AISC CSI 和 MCPShield 一起阅读,而不要孤立地读。 三者合起来分别覆盖协议层(Metere)、治理层(NSA)和运行时认知层(MCPShield)。任何一个单独都不够。

状态

项目	参考	日期	备注
Attested tool-server admission 论文	arXiv:2605.24248	2026-05-22	RFC 2119 线格式、签名准入、白名单、强制模式
参考实现	mcp-attested(论文引用)	2026-05	据论文 §1,随 enclawed-oss 与 enclaved 发行版交付
NSA AISC MCP CSI	nsa.gov,U/OO/6030316-26	2026-05-20	八类弱点、防御基线
MCPShield	arXiv:2602.14281	2026-02	互补的认知层防御

MCP 在未来十二个月不会失去它的增长曲线。它可能失去的,是”服务器这么说就够分发一个工具了”这个惯例 —— 而 Metere 的论文是第一个具体的提案,让 host 能够在模型被问到之前就说不。