单个协议都没错，Agent组合后却越权：形式化分析揭示30个跨协议安全失败

6 月 27 日，Dartmouth、Palo Alto Networks、Meta、UC Riverside 等机构的研究人员发布论文 《Formal Security Analysis of Agent Protocol Composition》。

https://arxiv.org/pdf/2606.28690

这篇论文关注的不是某一个 MCP Server 有没有漏洞，也不是某个 Agent 会不会被提示注入，而是一个更底层的问题：当 MCP、A2A、ANP、ACP、ACP-Client 这些 Agent 协议被同一个 Runtime、Bridge 或 Conductor 串起来之后，安全责任到底由谁承担？

论文提出了一个分析框架 AgentThread，把协议规范、形式化模型、SDK 实测和责任归属串成一条证据链。

研究结果并不乐观：在五类 Agent 协议中，AgentThread 发现了 35 个规范层安全发现，并通过 80 个实现层测试验证其中一部分问题；更关键的是，在 8 组跨协议组合模型里，它发现了 30 个只在协议组合后才出现的安全失败。

这也是这篇论文最值得关注的地方：Agent 安全正在从“单点工具风险”进入“协议组合风险”阶段。单个协议看起来没有明显问题，单个工具调用也都合法，但它们被 Agent Runtime 串起来之后，权限、上下文、身份、审计边界会发生迁移，最后产生越权。

真正的问题不在单个 Server，而在 Agent Runtime 串起了一条链

过去讨论 MCP 安全，很多人会从 Server 角度看问题：有没有命令注入、有没有 SSRF、有没有任意文件读取、有没有路径穿越。

这些问题当然重要，但论文认为，仅仅检查单个 MCP Server 不够。因为真实 Agent 系统里，Host 往往同时连接多个 Server：

一个 Server 负责抓网页，一个 Server 负责读本地文件，另一个 Server 负责发网络请求，模型上下文则把这些工具输出全部混在一起。

论文用一个典型多 MCP Server 攻击链作为动机：用户只是要求 Agent 总结某个网页；Agent 通过 Fetch MCP Server 抓取网页；网页里藏着间接提示注入；这段内容进入模型上下文后，诱导 Agent 调用另一个具备本地文件读取能力的 MCP Server；最后再通过网络能力把敏感文件发出去。

论文强调，这条链里每一步单看都可能是合法工具调用，真正的问题是不可信内容、共享上下文、文件权限、网络出口权限被同一个 Agent Runtime 串成了完整攻击路径。

这里的关键判断是：

单个 MCP Server 可以没有恶意，单个工具调用也可以符合协议，但组合之后仍然可能形成攻击。

这和传统 API 安全不太一样。传统 API 安全更多关注认证、鉴权、消息格式、接口边界；Agent 协议还要处理一个额外问题：文本会变成动作。

网页内容、工具返回结果、另一个 Agent 的消息，不只是普通数据。它们进入模型上下文之后，可能影响后续工具选择、参数生成和权限使用。Agent 系统里的“数据流”和“控制流”不再完全分离。

AgentThread：把协议文本变成可检查的状态机

AgentThread 的思路可以概括为一句话：

先把协议规范翻译成形式化模型，再用模型检查找到反例，最后尽量映射到真实 SDK 里复现。

论文把整个流程分成几个步骤。

第一步，收集协议材料。

包括协议说明文档、角色文档、schema、示例、SDK 和参考实现。

第二步，从自然语言规范中抽取中间表示。

论文里叫 Protocol IR 和 Responsibility IR。前者描述协议里的角色、状态、动作、前置条件和状态变化；后者描述某个安全控制到底由谁负责，是规范负责、SDK 负责、Runtime 负责，还是应用开发者负责。

第三步，把这些 IR 编译成 TLA+ 模型。

TLA+ 可以简单理解为一种描述状态机和不变量的形式化语言。这里不是为了证明 Agent “绝对安全”，而是为了让工具能够自动枚举状态，并找出“怎样一步步走到不安全状态”。

第四步，用 TLC model checker 找 counterexample trace。

也就是一条反例轨迹：从初始状态开始，经过哪些协议动作，会走到违反安全属性的状态。

第五步，把反例轨迹转换成 SDK/API 测试。

如果这条路径在真实实现里可执行，AgentThread 会通过协议适配器把模型动作映射成真实 SDK 调用，验证真实系统是否也暴露同样行为。

这套方法的价值在于，它没有停留在“我觉得这里有风险”的威胁建模层面，也不是只写几个 PoC。它试图建立一条更硬的证据链：

协议文本在哪里说了，形式化模型怎么表达，反例轨迹怎么走，SDK 是否真实复现，最后谁应该负责。

这对 Agent 协议安全很重要。因为 MCP、A2A、ANP 这类协议还在快速演进，很多安全要求分散在文档、schema、SDK 行为和安全建议中。如果没有一条可追溯的证据链，后续协议一改，旧的安全结论很快就会失效。

五层安全范围：Agent 协议不只是 RPC

论文把 Agent 协议安全分成五层。前面三层偏传统协议安全，后面两层更接近 Agent 特有风险。

论文明确假设传输安全是底层基础，重点分析协议层和 Agent 层可见的安全义务。AgentThread 在组合场景里会把这些检查提升到 Bridge 边界：L1 看翻译后消息是否良构，L2 看生命周期是否级联，L3 看权限是否单调，L4 看语义内容是否越过权限边界，L5 看审计和溯源是否连续。

这个分层很关键。今天很多 MCP 安全讨论还停在 L1-L3：消息格式、鉴权、工具 schema、Server 权限。但 Agent 风险的难点往往在 L4-L5：模型怎么解释工具输出，工具输出如何影响下一步动作，多个工具之间的权限如何叠加，最终审计能不能还原完整链路。

换句话说，Agent 协议安全不能只问“这个调用是不是合法”，还要问：

这个调用的意图来自哪里？它是否继承了不可信内容？它是否超出了用户最初授权？它是否和前后调用组成了更高风险的链？日志能不能证明这一点？

如果这些问题没有答案，单个工具调用再合法，也可能只是攻击链上的一环。

五个协议、55 个检查单元：没有一个协议全部通过

论文评估了五类 Agent 协议：MCP、A2A、ANP、ACP-Cap、ACP-Client。它们分别覆盖工具调用、多 Agent 委派、身份型 Agent 网络、能力通信以及 Coding Agent 本地开发环境访问等场景。

AgentThread 设计了一个 5 × 11 的安全检查矩阵，一共 55 个协议-检查单元。结果显示：

35 个是规范层安全发现，其中 12 个被实现层测试确认，23 个停留在规范/模型层，10 个通过，10 个因为协议范围不适用或未检查。

论文特别指出：没有一个协议通过全部检查。 其中，审计完整性和凭证/注册表完整性是五个协议中普遍存在的问题，要么被违反，要么只是建议，要么没有执行机制，要么规范本身不充分。

比较值得注意的是，论文没有简单地把所有失败都称为“漏洞”。它区分了几种情况：

第一类是标准不一致。

规范明确要求必须做到，但 SDK 或参考实现没有做到。比如 MCP 内容完整性检查中，论文认为规范要求清洗工具输出，但 SDK 工具调用路径里，五种注入 payload 都可以原样通过。

第二类是建议落空。

规范里只是 SHOULD 或建议做，但没有强制。例如某些 token 生命周期、凭证撤销、用户确认机制。

第三类是框架加固缺口。

协议没有明确要求，但从 AgentThread 的安全框架看，这个控制应该存在。例如 A2A 中委派范围约束不足，可能导致权限跨 hop 放大。

第四类是层级完整性问题。

某一安全层面的义务没有被完整覆盖，比如跨协议审计、组合安全、fail-secure 默认行为。

这种分类比较克制。它没有把作者自己的安全理想强行套到所有协议上，而是把“违反规范”“规范建议不足”“设计上应该加固”“组合后没人负责”分开讨论。

几个典型反例：问题不是一次调用，而是一段状态轨迹

论文里有几个典型 counterexample，可以帮助理解这种“协议状态机安全”。

第一个是 MCP 凭证/注册表完整性问题。

TLC 找到一条轨迹：会话初始化之后关闭，但凭证没有被撤销。这里甚至不需要攻击者主动操作，问题在于“会话结束”并没有自动终止这次会话创建出来的 authority。论文把它归为生命周期建议缺口，因为相关规范没有强制定义撤销机制，只是建议控制 token 生命周期。

第二个是 A2A 委派单调性问题。

一个 Agent 把 capability 委派出去之后，后续步骤可以把 capability 重新委派到超出原始授权范围的位置。由于 A2A 没有明确定义 delegation-scope constraints，transitive re-delegation 可能导致权限跨多个 hop 被放大。论文把它归为框架加固缺口。

第三个是 MCP 内容完整性问题。

这个问题更直接。论文认为 MCP 规范对工具输出清洗有明确要求，但 SDK 工具调用路径没有拦截注入 payload，导致恶意内容能够原样进入后续上下文。

这几个例子说明，Agent 协议安全不是简单的“接口是否鉴权”。很多风险来自状态之间的连接：

会话结束了，凭证是否仍然有效？Agent 委派了权限，权限能不能继续转委派？工具输出是数据，还是会变成下一步指令？

这些问题放在单次 API 调用里不明显，放到多轮、多工具、多 Agent 运行轨迹里就会变得很关键。

最关键的发现：组合后新增 30 个跨协议安全失败

论文最有价值的部分在 RQ3，也就是协议组合安全。

作者构造了 8 个 composed models，一共实例化了 43 个面向安全的组合义务，包括 31 个边界风险义务和 12 个 Bridge 合同保持义务。结果有 30 个出现 counterexample。论文也特别说明，30/43 不是所有 TLC 检查的失败率，而是针对 layer-derived cross-boundary security obligations 的反例率。

8 组组合结果如下：

其中 MCP ↔ A2A 是最有代表性的案例。

在这个组合里，MCP 工具输出进入 A2A conductor，A2A conductor 再协调下游 Agent。TLC 找到一条轨迹：未清洗的 MCP 输出污染 Bridge，Bridge 进一步导致 A2A authority 超过接收方原始授权范围，而这次权限升级没有完整审计轨迹，因为 Bridge 不属于 MCP 或 A2A 各自的本地审计范围。

这个问题单看 MCP 看不到，单看 A2A 也看不到。

• 在 MCP 侧，它只是内容完整性缺口；

• 在 A2A 侧，它只是委派范围缺口；

• 但在 MCP ↔ A2A 的边界上，两者组合成了权限升级。

这就是论文标题里“composition”的含义。Agent 协议不是孤立运行的，真正的风险经常出现在协议之间的缝隙里。

三类组合失败：中间人、语义不匹配、身份幻觉

论文把跨协议组合失败归纳成三类。

第一类是隐藏中间人。

比如 chained MCP relay、A2A federation、ANP-discovered MCP tool use。这类结构会把 provenance、trust、credential 边界压扁。单个端点只能看到自己的局部状态，看不到完整链路。最终风险不是“某个端点做错了”，而是中间桥接层把上下文和权限悄悄传过去了。

第二类是 authority / consent 语义不匹配。

比如 MCP ↔ ACP-Cap、A2A ↔ ACP-Cap。不同协议对 consent、delegation、authority 的理解不一致，Bridge 在中间做静默翻译，结果本来应该重新确认的权限被自动延续。论文指出，这类问题不是简单加一个弹窗就能解决，因为弹窗背后必须先定义清楚：到底是哪一段 authority 被传递，用户同意的是哪一个操作范围。

第三类是身份认证不等于内容安全。

ANP 有 DID-based identity、端到端加密、token 生命周期等机制，但论文发现，身份体系并不会自动提供内容完整性和委派范围控制。换句话说，你能证明“这条消息是谁发来的”，不代表这条消息里的内容不会污染模型上下文，也不代表它不会诱导后续工具越权。

这一点很容易被低估。很多 Agent 协议和平台在谈安全时，倾向于强调身份、签名、认证、加密。但在 Agent 场景里，身份只解决“谁发的”，不解决“内容会驱动什么动作”。

对 Agent 来说，最危险的经常不是匿名攻击者，而是可信来源里的不可信内容。

责任缺口：最危险的地方往往没人负责

论文提出 Responsibility IR，是为了回答一个非常现实的问题：

发现这个组合风险之后，应该找谁修？

单协议问题通常比较好归属。规范写错了找协议作者，SDK 没实现找 SDK 维护者，应用滥用找应用开发者。但跨协议组合问题不一样。MCP 负责工具调用，A2A 负责 Agent 委派，ANP 负责身份网络，ACP-Client 负责本地开发环境访问；真正把它们串起来的 Runtime、Bridge、Conductor，往往不在任何一个协议的规范责任范围内。

论文分析了 35 条责任记录，覆盖 MCP、A2A、ANP、ACP-Client 四类协议。结果显示，只有一个安全相关控制既有责任归属又被实际执行，也就是 ANP 的 DID-based identity verification；32 个 gap 中，有 18 个属于 enforcement gap，也就是规范里分配了责任，但 SDK 没有提供执行机制；所有 composition control 都是 orphaned，没有协议负责 chained MCP servers、A2A conductors 或 ACP-Client 内部 MCP tools 这类 Bridge 安全。

这其实是今天 Agent 安全落地里最麻烦的问题。

• 协议作者可能会说，组合安全属于应用层；

• SDK 作者可能会说，SDK 只负责协议调用，不负责业务策略；

• 平台方可能会说，权限配置由开发者自己决定；

• 开发者又可能默认认为协议和 SDK 已经处理了安全边界。

最后真正危险的位置——Agent Runtime、Bridge、Conductor——反而没有清晰责任主体。

这也是论文最后的核心结论：Agent 协议安全不能只靠更好的单协议规范和 SDK 补丁，还需要显式的 composition contracts，以及对连接这些协议的 Runtime 明确执行责任。

对企业落地 Agent 的启发：不要只做 Server 白名单

这篇论文对企业 Agent 落地有几个直接启发。

第一，MCP Server 白名单只能解决一部分问题。

白名单可以降低恶意 Server 风险，但不能自动解决“可信 Server 输出的不可信内容”问题。一个正常的 Fetch Server 抓取了恶意网页，仍然可能把隐藏指令带入模型上下文。

第二，工具权限不能只按单个工具配置。

文件读取工具、网络请求工具、代码执行工具、数据库查询工具，单独看都有合理用途。但它们组合之后，可能形成“读取—加工—外传”链路。权限控制要按任务链路、数据来源、目标动作一起判断。

第三，用户确认不能只做粗粒度授权。

“允许 Agent 使用文件工具”不等于“允许 Agent 在网页总结任务里读取本地敏感文件”。更合理的做法是把用户意图、数据来源、目标资源、外部发送动作绑定起来。

第四，审计日志必须跨工具、跨 Server、跨 Agent。

只记录“调用了哪个工具”不够。审计要能还原：调用前模型看到了什么内容，工具参数如何生成，权限来自哪里，结果流向哪里，是否跨协议经过 Bridge。

第五，Agent Runtime 要成为安全控制点。

过去很多安全能力放在模型前后、工具 Server、应用业务层。但这篇论文提醒我们，组合风险经常发生在 Runtime。Runtime 才知道当前任务上下文、工具集合、权限状态和跨工具调用链。它不只是调度器，也应该是策略执行点。

局限性

这篇论文也有边界。

首先，它的检查项来自 AgentThread 的分层安全框架，并不完全等同于每个协议自己的设计目标。所以论文才区分了标准不一致、建议缺口、框架加固缺口和层级完整性问题。不能简单说“某协议有多少个失败，所以它一定更差”。

其次，TLA+ 模型是抽象模型，不是完整系统。它可以帮助发现状态轨迹里的安全反例，但不能覆盖真实 Agent 系统里的全部复杂性，比如模型内部推理、不确定工具选择、业务策略、用户交互细节。

再次，实验覆盖的是特定协议、特定 SDK 版本、有限 TLC bounds 和有限参考实现。论文结果更适合理解风险结构，而不是直接当作全行业统计结论。论文自己也说明，30/43 是跨边界安全义务中的反例比例，不是所有 TLC 检查的失败率。

但这些局限不影响它的价值。它最重要的贡献不是证明“某个协议不安全”，而是提出了一个更清晰的问题框架：Agent 协议进入组合部署之后，安全属性必须跨边界成立，责任也必须跨边界分配。

写在最后

如果把 MCP、A2A、ANP、ACP-Client 看成 AgentOS 的基础组件，那么这篇论文讨论的就不是一个小众形式化验证问题，而是未来 Agent 基础设施的安全底座问题。

今天的 Agent 系统正在从单 Agent、单工具、单应用，走向多工具、多 Agent、多协议、多环境。一个 Coding Agent 可能同时访问本地仓库、CI/CD、数据库、浏览器、云服务；一个企业办公 Agent 可能同时连接邮件、IM、文档、审批、知识库；一个多 Agent 系统还会把任务拆给不同 Agent，再由它们继续调用工具。

在这种系统里，安全边界不再固定在某一个接口上。边界会随着上下文流动，随着任务委派迁移，随着协议桥接改变。

所以，Agent 安全不能只问：这个工具安全吗？这个协议安全吗？这个 SDK 有没有漏洞？

还要继续问：工具之间如何组合？协议之间如何传递权限？Bridge 是否重新校验语义和授权？Runtime 是否记录完整链路？出现问题后谁负责修？

这篇论文最重要的提醒是：

单个协议都没错，不代表组合后的 Agent 系统安全。真正的越权，往往发生在协议之间。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。