第 12 章 — 协议加固与防御
LLM Primer IV: Designing AI Cognition with MCP 章节走读的第十二篇。前一章的每一项威胁这里都有一份对应的防御;没有任何一项是银弹;它们的组合是唯一能产出一种真正能部署的姿态的东西。
这一章为什么存在
协议不会因为被部署就变安全。它变安全,是因为被部署在一套补偿了裸协议所做假设的栈里。第 11 章列出了威胁;这一章按工程深度走防御。密码学能力背书关闭发现和能力升级两类。OAuth 2.1 scope 纪律加上用户委托 token 关闭代理和透传两类。有界会话生命周期关闭会话劫持类。沙箱包住预防漏掉的攻陷。人工审批门接住其他三层为了有用而不得不自动化掉的破坏性操作。每一层都留下残余风险;组合才能让残余小到实际能防住。
12.1 AttestMCP:密码学能力背书
第一项防御处理一个贯穿几乎所有威胁的问题:host 没办法验证它在跟的 server 就是它声称的那个。AttestMCP — 也叫 MCPSec 或签名能力清单 — 在协议消息结构之上加一层密码学背书。发布方持有一把长期签名密钥,在目录或透明日志里注册。完整能力清单在发布时被哈希、签名。Host 在 initialize 时用存档的发布方密钥验证签名,要么接受 server、要么隔离、要么拒绝连接。
好处是实的。Typosquat 没法生成来自合法发布方的有效签名。通过 list_changed 通知做的能力升级变得可检测,因为新清单需要新签名。细粒度策略 — "信任 GitHub 发布的 server 处理仓库但不能处理邮件" — 变得可强制,因为发布方身份现在是可验证的而不是被声称的。代价也是实的:发布方要运营签名基础设施、透明日志需要可信运营方、host 的策略层得理解吊销。诚实的框架是 AttestMCP 是一项实质工程,不是一个勾选框。还有一个值得起名的缺口:清单签名的是 server 关于自己说的话,不是它运行时做什么。一份签名后的良性工具声明依然可以出货一份在外泄的实现。背书必要但不充分,这就是这一章后半还存在的原因。
12.2 OAuth 2.1 scope 与有界会话生命周期
第二簇收紧凭据和会话模型。OAuth 2.1 的流程是成熟的;工程在 "用对" 上面。第一份纪律是 窄 scope — 只请求声明的工具表面所需。Scope 越紧,爆炸半径越小。这条纪律比听起来难,因为上游服务常把 scope 定义得粗,而窄路径很烦;宽 scope 第一次就跑得通,感觉像进展。窄 scope 的代价由工程师付;宽 scope 的代价在出事时由用户付。
scope 纪律一个人挡不住 Confused Deputy 的那个防御是 用户委托 token。在上游支持的地方,每个用户完成自己的 OAuth 流,server 用用户的 token 而不是自己的服务身份行事。代理消失了,因为 server 不再以自己的权限行事。Token 透传有另一个修法:不要让 token 透传。Server 持有自己的凭据,注册时建立,host 跟 server 之间的边界永远不带 token。有界会话生命周期对付劫持:高风险操作几分钟,常规操作几小时,在上面叠一层耐用工作流身份,这样多小时任务能续期传输会话而不必每 15 分钟提示用户。按会话能力绑定和会话续期时的 能力重确认把这条纪律补齐 — 两者都是 host 必须显式做的状态管理工作,很多实现没做。
12.3 沙箱与运行时隔离
第三簇承认不是每个威胁都能预防,而一份能站住脚的姿态必须在预防失败时控住伤害。本地 server 的进程沙箱 — Linux 上的 seccomp、macOS 上的 App Sandbox、Windows 上的 AppContainer、为更强隔离的 gVisor — 默认拒绝文件系统、网络、进程访问,只授权 server 需要的具体权限。一个被攻陷的 server 试图读密码文件或外泄到攻击者端点,在 OS 层就被拒,不是因为 server 的代码克制,而是因为沙箱。远程 server 的网络策略 — 双向 TLS、端点白名单、出向过滤 — 收窄被攻陷远程 server 能够到的表面。Host 内部的内容隔离在返回内容落进模型上下文之前用合适的怀疑度对待它:不可信标记、HTML 净化、拒绝跟随嵌入的 URL。通过能力感知策略做的工具调用沙箱让 host 检视调用参数,决定放行、拒绝、升级到用户审批。一个值得起名的具体风险是通过合法工具的侧信道外泄 — 恶意模型把凭据编进搜索查询 — 策略层靠检视参数而不是端点来抓。供应链隔离合上闭环:二进制的哈希在安装和更新时对透明日志里的签名值校验,这样一份被篡改的二进制就算清单查过也不能跑。
12.4 人工审批门
第四簇承认有些操作不应该被自动化。破坏性、不可逆、高影响的调用 — 转钱、删文件、改生产 — 在发生那一刻值得一次显式的人决定。机制是 HITL 门,工程在 "让它有效又不让系统不可用" 上面。按可逆性分类:只读操作自动放行;改状态的操作加门。有意义地呈现:一个写着 "允许工具执行?" 的弹窗就是橡皮图章;一个有用的门展示工具、完整参数、用平实语言写的后果、还有出处。靠批次上下文审批避免审批疲劳,一个发起 "把发票发给上季度的客户" 的用户审批一次批次,而不是 20 封邮件一封批一次。把高风险操作通过带外渠道路由 — 硬件令牌、第二设备、借鉴金融业的 step-up 认证。让操作可见、可审计、可撤回。Sampling 驱动的调用走跟 agent 发起的调用一样的门;服务器侧发起推理的那个侧信道不能在用户不知情的情况下落到一个副作用上。
第 12 章接下去会怎么走
工程图景的安全那一半现在完整了。另一半 — 框架、部署模式、性能特性、确认系统在生产里能跑的测试 — 是剩下几章要处理的。第 13 章开启这条弧线,走 2025 年和 2026 年里落地的框架和云集成:配 Amazon Bedrock 的 Strands、AWS 状态层模式、Microsoft Agent Framework、LangChain、Semantic Kernel。框架重要,因为没人从裸协议搭生产 MCP,在这些框架之间的选择以协议层一个人决定不了的方式塑造工程和安全姿态。
明天 — 第 13 章:框架与云集成。配 Bedrock 的 Strands、AWS 状态层、Microsoft Agent Framework、LangChain、Semantic Kernel,以及三种团队各自独立到达的生产集成模式。
