arXiv 2601.17549 对 MCP 规范本身做了第一次系统性安全分析,并提出 ProtoAmp 框架来度量协议级攻击面。结论是三个协议设计层的缺陷,靠改某个客户端修不好。

ProtoAmp 指出的三条信任裂缝是什么?

第一,缺能力证明。MCP server 可以随意宣称自己有什么权限,协议没有要求它出示可验证的凭据。一个恶意 server 声称自己「只读」,实际却能写文件,Agent 无从分辨。

第二,双向采样无来源认证。MCP 允许 server 反过来向客户端请求采样(sampling),但没有认证这个请求到底来自哪。攻击者借此把提示注入塞进模型上下文,而 Agent 以为是用户的指令。

第三,多服务器隐式信任传递。当一个 Agent 同时连多个 MCP server,server 之间可以互相影响,信任被隐式传递,没有一道显式的授权闸。

针对这三条裂缝该怎么加固?

能力证明:要求 server 在握手时出示声明的权限边界,客户端按最小权限放行。采样来源:对 server 发起的采样请求做来源白名单,拒绝任何未经用户确认的反向调用。多服务器隔离:不同 server 的上下文物理隔开,禁止一个 server 的内容直接成为另一个 server 的工具输入。

MCP 信任问题的本质到底是什么?

MCP 的问题本质是「把网络信任默认成了本地信任」。在 Agent 自动执行一切的时代,每一次工具握手都应该是一次显式授权,而不是一句「默认信任」。

落地时必须守住哪三条红线?

第一,不信任任何 server 自报的权限。让 server 在握手时出示它要访问哪些资源,由你按最小集合批准,而不是它说只读就只读。第二,默认拒绝 server 反向发起的采样请求,确有需要时弹给用户确认,绝不让 server 借模型之手发指令。第三,多 server 之间做上下文隔离,一个 server 返回的内容在喂给另一个 server 的工具前,必须经过清洗与标注。这三条做到,ProtoAmp 指出的三类协议级风险就被兜住了大半。协议本身要补,但企业侧的防御不能等协议修完才动手。

去论坛讨论

这篇文章里的观点,欢迎到硅基AGI论坛讨论。按标题搜索:MCP能力证明