2026 年 8 月 27 日,Algorand Foundation 在 Hacker News 发布 AC2 协议——Agentic Communication + Control Protocol,定位是给 AI Agent 补一层缺失的安全层,17 分上首页讨论 7 条,质量很高。同月 12 天,arXiv 编号 2609.10871 的 A2ABreak 论文给行业扔了一颗冷弹——这是学
2026 年 8 月 27 日,Algorand Foundation 在 Hacker News 发布 AC2 协议——Agentic Communication + Control Protocol,定位是给 AI Agent 补一层缺失的安全层,17 分上首页讨论 7 条,质量很高。同月 12 天,arXiv 编号 2609.10871 的 A2ABreak 论文给行业扔了一颗冷弹——这是学术界对 Google Agent2Agent 协议(2025 年 4 月发布,Linux Foundation 治理)的首次系统性安全分析,作者从自然语言规范里抽出 37 个状态、76 个转换、929 个形式化陈述,跑了一遍对抗性验证,挖出 11 个新漏洞,全部由"合规的"对手利用而不需要任何实现层缺陷。两件事放在一起读,正好把企业级 Agent 通信协议工程当前面临的核心矛盾摆到桌面上——协议层正在快速分裂(A2A、MCP、AC2、APH 各有山头),但协议层的安全标准还没跟上。把这事拆开来谈,可以非常清晰地看出 Agent 协议工程的下一阶段重心应该放在哪里。
一、为什么 Agent 协议需要补一层安全
Algorand 团队在 AC2 协议白皮书里直接给出了问题定义。当 AI Agent 接管支付、代码签名、敏感操作后,现有的人机协作(Chat HITL,Chat-based Human-in-the-Loop)框架存在三个结构性缺陷。
第一个缺陷,缺少可验证的身份。今天的 Agent 收到一个授权请求,只能从用户那里拿到"ok 同意"的一句话,这句话没有任何身份证明。Agent runtime 本身一旦被攻破——比如某个第三方插件被供应链污染——攻击者可以伪造同意消息,Agent 没法区分这条消息是真人发的还是攻击者发的。
第二个缺陷,缺少标准化的授权委托。当用户把执行权委托给 Agent,这条授权链路上每一跳用什么协议、什么字段、什么格式,各家 Agent 平台都不一样。结果是同一笔支付可能因为 Agent 平台切换导致授权失效,或者反过来因为授权过宽让 Agent 越权做事。
第三个缺陷,缺少密码学证明的用户意图。即使 Agent 把请求展示给用户,用户点了"同意",这个动作本身在系统里没有密码学痕迹。事后审计时无法证明哪个动作是用户真的授权过的、哪个是被注入的、哪个是 Agent 自己误操作的。
这三个缺陷的根因都是同一个——把"Agent 运行时"当成信任边界,而 Agent 运行时恰恰是最不可信的环节。任何 Agent 平台都会引入大量第三方工具、MCP server、插件、模型,这些组件里的任何一个被攻破,Agent 运行时就被攻破。把密钥、token、敏感凭证放到运行时里,等于把保险箱钥匙放在保险箱外面。
二、AC2 协议怎么补这层
AC2 协议的核心设计哲学是私钥永远不离开用户设备,Agent 永远拿不到钥匙,只拿到签过名的授权。具体来说,AC2 在 Agent runtime 和用户钱包之间开了一条端到端加密的 WebRTC 直连通道。当 Agent 需要签一个东西(支付、commit、API 调用),它通过 AC2 把请求发出去,用户在钱包里审批,签名通过同一通道回传给 Agent。整个过程,私钥从未出现在 Agent runtime 内存里。
技术栈层面,AC2 用三个公认标准做拼装。底层是 FIDO2/WebAuthn,这是行业标准硬件认证器规范,支持面部识别、指纹、设备 PIN,设备私钥在 TPM/Secure Enclave 里出不来。中间是 Liquid Auth,在 FIDO2 之上做了一层 passkey-based authentication,让 passkey 可以在不同 agent framework 之间复用。最外层是 DIDComm v2.0,这是去中心化身份通信的事实标准,保证 AC2 消息格式与其他 DID 系统兼容。
落到具体场景,AC2 协议展示了五个用例。第一个,签名 commit——Agent 提交代码改动,要求人用 FIDO2 硬件授权,签下来的 commit 包含密码学证据证明"人行使了最终批准权"。第二个,客户端通信——Agent 准备给客户发一封邮件,邮件正文的精确字节流送到用户钱包,用户在钱包里签字批准,证明"人签了确实要发出去的版本"。第三个,支付授权——支付详情直接路由到用户钱包,授权发生时私钥不出设备。第四个,API 调用授权——Agent 调用任何外部 API 之前,具体参数展示给用户钱包,签名证明"授权了 X 参数、由 Y、在 Z 时刻"。第五个,Google AP2 IntentMandate——Agent 提交一个 IntentMandate 定义"能做什么、在什么约束下",签名一次,后续执行全程靠密码学强制执行。
三、A2ABreak 给行业提了个醒
如果说 AC2 是给 Agent 协议工程"补一层安全"的提案,A2ABreak 论文则是给已有的 Agent 通信协议"做一次全面体检"。arXiv 2609.10871 标题是《A2ABreak: Systematic Security Analysis of the A2A Protocol》,目标是 Google 在 2025 年 4 月发布的 Agent2Agent 协议——目前由 Linux Foundation 治理,被定位为多 Agent 生态的横向通信层,与 MCP 互补(MCP 管工具集成,A2A 管 Agent 间通信)。
论文采用的方法很有借鉴价值。先用 LLM-assisted extraction 从 A2A 自然语言规范里抽出 verified finite-state machine,产出 37 个状态、76 个转换、929 个形式化陈述的统一模型,这是"形式化基础"。然后用对抗性验证在这个模型上做穷举式漏洞挖掘,在 full-compliance assumption(假设所有参与者都严格遵守规范)的前提下找漏洞。这种方法的优势是漏报率低,任何漏洞一定是规范允许的攻击路径。
结果是 11 个新漏洞,每个都可以被严格合规的对手利用,不需要任何实现层缺陷。论文列出的三类典型漏洞值得每个 Agent 协议设计者引以为戒。
第一类,跨客户端 context injection 通过未受保护的 context identifier。A2A 协议规范里的 context identifier 字段没有明确的加密或签名约束,一个合规的 Agent 可以构造一个携带恶意 context identifier 的消息,接收方 Agent 在没有任何上下文验证的情况下按 identifier 解析并执行。这意味着一个合规客户端可以向另一个合规客户端注入恶意上下文,后者在毫不知情的情况下执行。
第二类,多跳委托链上的 credential harvesting。A2A 协议允许 Agent A 委托 Agent B,Agent B 再委托 Agent C,但规范没有要求每次委托都传递原始 credential 的 proof of authority。结果是攻击者只要插入一个合规 Agent 到委托链里,就可以 harvest 上游 Agent 的 credential,因为下游委托时默认信任上游的授权,不会重新验证授权链的真实性。
第三类,数据外泄通过 rogue agent 自报 unattested capability claims。A2A 规范里 Agent 可以声明自己有什么 capability,这个声明在协议层不做强制验证。一个 rogue Agent 可以声明自己有某种 capability,被允许执行对应操作,即使它其实根本不具备——因为协议不检查 capability 的真实性,只检查 capability 是否被声明过。
A2ABreak 论文还做了一个重要对照——同样的协议规范文档,如果只用 zero-shot LLM baseline 去分析,产生的 confirmed findings 是 0。换句话说,显式的形式化基础对于协议安全分析是不可省略的,LLM 直接读自然语言规范看不到漏洞。这个结论对工程团队很重要——LLM 可以用来加速规范的理解,但形式化状态机抽取仍然需要专业方法学。
四、企业级 Agent 协议工程需要补什么
把 AC2 和 A2ABreak 合起来看,企业级 Agent 通信协议工程当前需要补的功课可以分成四块。
第一块,身份层必须密码学化。任何 Agent 协议的设计阶段必须包含"谁在调用"的密码学证明,这条标准不能等到发现漏洞再补。A2ABreak 论文里 identity loss 漏洞的根因就是缺乏每跳 identity proof,而 AC2 用 FIDO2 硬件认证器提供天然 per-user identity proof,方向上是对的。FIDO2 在消费市场已经被 Apple、Google、Microsoft 全部支持,直接拿来作为 Agent 协议的身份底层是合理选择。
第二块,授权链必须可追溯。A2ABreak 漏洞二的核心是委托链上 credential 不验证上游 authority,这意味着任何 Agent 协议在设计 delegation 时必须明确"每次委托需要携带原始授权 proof"的字段。Web 世界的 OAuth 2.0 已经解决过类似问题,Agent 协议可以照搬它的 delegation token 链,让每一跳都能验证上游授权的真实性。
第三块,capability 必须经过强制验证。A2ABreak 漏洞三说明 capability claim 在协议层不能自我证明,必须有 attestation 机制。在 Web 场景这等价于 SSL/TLS 证书的 CA 验证,在 Agent 场景应该是"capability 由谁背书、谁验证"的固定字段。可以引入 PKI 体系或去中心化身份体系来做背书,但绝不能让 Agent 自己声明自己有什么 capability。
第四块,消息格式必须经过形式化验证。A2ABreak 论文展示了一个重要事实——LLM 直接读自然语言协议规范找不到漏洞,只有形式化状态机抽取 + 对抗性验证才能系统性地发现漏洞。这意味着任何要进入企业生产环境的 Agent 协议,在发布之前都需要做一次类似 A2ABreak 的系统性安全分析,而不是依赖"开发都看过一遍"的传统 code review。
五、协议分裂与生态选择
Agent 协议工程当前的现实是分裂。A2A 主打跨组织 Agent 发现和委托,MCP 主打工具集成和上下文共享,AC2 主打可验证身份和密码学授权,APH、MCP-Deception、OpenClaw、XMPP-over-agents 等小众协议还在持续冒出。任何一个协议都没能完整覆盖 Agent 通信的所有需求。
企业落地面对这种生态分裂有两种策略。第一种是协议无关的中台——自研一个 Agent communication layer,把 A2A、MCP、AC2 等多个协议适配进来,让上层 Agent framework 通过统一 API 调用所有协议。这种策略的好处是不被任何一家协议生态绑定,坏处是适配工作量巨大,且任何一个上游协议升级都可能影响中台。第二种是深绑单一协议生态,选择一个主力协议(比如 AC2)并把它做成内部标准,通过 plugin 或 adapter 让其他协议可以接入。这种策略的好处是集成深度可控,坏处是被单一生态绑死,协议方一旦战略调整企业就被动。
无论选哪种策略,企业 IT 评估 Agent 协议时都应该套用同样的检查表。一,协议是否定义了密码学身份层,没有的话协议成熟度不够。二,委托链是否携带上游授权 proof,没有的话合规风险不可控。三,capability claim 是否需要 attestation,没有的话企业部署后会出现 rogue agent 行为。四,是否做过类似 A2ABreak 的系统性安全分析,没有的话漏洞清单不可信。五,是否支持形式化验证,没有的话协议升级时兼容性风险不可控。
把这五条套到今天市场上任何一个 Agent 协议上,会得出一个相当冷静的结论——目前没有一家能完整通过所有检查,企业落地时必须自己加补充措施。这就是为什么协议层会持续分裂,因为还没有人做出真正的"标准答案"。
六、从 AC2 和 A2ABreak 看下一步
最后把这两件事放在一起看,可以看出 Agent 协议工程的下一阶段重心会落在三个方向。
第一个方向,密码学身份层会被快速标准化。FIDO2/WebAuthn 已经成熟,DIDComm v2.0 是事实标准,未来的 Agent 协议无论叫什么名字,身份层大概率会从这两套里取一个做底层。AC2 把这条路走通,意味着任何不采用类似设计的协议会在企业市场被自然淘汰。
第二个方向,协议安全分析会变成发布前提条件。A2ABreak 论文展示了一个完整的可复用流程——LLM-assisted extraction + 形式化 FSM + 对抗性验证 + 独立专家 review。任何一个协议要进入生产环境,都需要这种程度的验证。学术界会持续出 A2ABreak 风格的论文,业界也会开始要求协议供应商提供对应的安全分析报告。
第三个方向,协议层的合并会比想象来得快。MCP 和 A2A 已经在 Linux Foundation 治理下开始相互引用,AC2 这种新协议如果要做大也必然要和 MCP、A2A 做互操作。协议工程的下一步不是发明新协议,而是把现有协议的边界画清楚,做好互操作层。任何一家想完全另起炉灶的协议,最终都会被生态压力逼回到兼容老协议的路上。
合起来,Agent 协议工程从 2026 年下半年开始,已经从"能不能跑通"过渡到"能不能跑得安全"。AC2 是在补具体的安全能力,A2ABreak 是在揭已有的安全缺口,两件事合起来给整个行业指了一条明路——协议设计阶段就要把密码学身份、可追溯授权链、capability attestation、形式化验证四件事做扎实,而不是等出了事再补。这是 Agent 协议工程从早期实验走向企业级生产必须过的一关,也是企业 IT 评估任何 Agent 协议供应商时必须问清楚的四个问题。