AC2 Protocol:Agent 通信缺失的安全层,以及它在企业级多 Agent 部署里真正补齐的协议缝隙 2026 年 8 月 27 日,Algorand Foundation 在 GitHub 上线了一个名为 AC2 Protocol(Agentic Communication + Control Protocol)的开源协议,自我定位是"the missing security laye
AC2 Protocol:Agent 通信缺失的安全层,以及它在企业级多 Agent 部署里真正补齐的协议缝隙
2026 年 8 月 27 日,Algorand Foundation 在 GitHub 上线了一个名为 AC2 Protocol(Agentic Communication + Control Protocol)的开源协议,自我定位是"the missing security layer for AI agents"。这个协议的核心目标非常清晰:把 AI Agent 在执行敏感操作(付款、代码签名、API 调用)时所需的"用户意图证明",从传统的"聊天界面点击确认"提升为"基于硬件绑定的密码学签名"。AC2 不依赖中心化中继、不需要区块链运行,采用 FIDO2 硬件认证 + DIDComm v2.0 消息格式 + Liquid Auth 协议栈。它的出现,精准回应了 2026 年下半年企业级多 Agent 部署中一个被反复忽视的协议缝隙——当 A2A(Agent-to-Agent)协议让 Agent 之间能够自由通信、MCP 让 Agent 能够调用工具,但"用户意图如何在 Agent 之间被忠实传递与证明"这个问题始终没有标准化答案。AC2 的尝试,正是为这个问题提供一个工程化的解决方案。
AC2 的核心设计哲学可以概括为三句话:第一,credential isolation——"Private keys never leave your device. Agents request intent, but never see your keys";第二,phishing-resistant——"FIDO2 hardware-bound approvals protect against phishing and replay attacks";第三,verifiable intent——"Cryptographic proof of who approved what, when, and for which action"。这三句话精准命中了 2026 年企业 Agent 落地的三个核心恐惧:Agent 内部被攻破导致凭据泄漏、Agent 在用户不知情时执行了危险操作、Agent 误操作后无法追溯是谁在什么时间授权了什么事。
从工程实现看,AC2 采用了插件化的部署形态。它不是另一款 Agent 框架,而是一个可以安装到现有 Agent 框架(目前官方支持 OpenClaw)的协议插件。安装流程是:`openclaw plugins install` + `openclaw ac2 setup` + 在用户手机上下载 AC2 Wallet App(支持 Android 和 iOS)+ 扫描 agent 端的配对 QR 码。配对完成后,Agent 想执行敏感操作时,通过 AC2 协议请求用户钱包签名,用户的生物识别(指纹/人脸/PIN)在本地通过 FIDO2 完成签名,签名结果返回给 Agent 作为"已授权"的密码学证据。整个过程用户私钥永远不出设备,Agent 永远看不到明文凭据。
从 HITL 到 Hardware-Bound Intent
把 AC2 放在企业 Agent 部署的演进谱系里看,它的真正贡献是把"Human-in-the-loop"(HITL,人在环)从"用户在聊天界面点按钮"提升为"用户在硬件层面签名意图"。传统的 HITL 模式面临三个根本性局限:第一,聊天界面点击确认缺乏密码学证明,事后无法审计谁在什么时间授权了什么;第二,Agent 在被 prompt injection 攻击时,可能会伪造用户授权(比如模仿用户的语气绕过审批);第三,多个 Agent 协作时,无法把"用户意图"在 Agent 之间传递并保持可验证。AC2 用 FIDO2 硬件认证 + DIDComm v2.0 解决了前两个问题,用 AC2 钱包 + 签名意图解决了第三个问题。
AC2 官网列举了五个典型应用场景,每一个都对应企业 Agent 落地中一个具体的痛点。Code deploys 场景下,AC2 让"代码合并到主分支"这个动作需要硬件绑定签名,提供"人类行使最终权威"的密码学证据;Client communications 场景下,Agent 替用户发送邮件或消息前,AC2 钱包对精确的邮件正文做签名,提供"人类已经审阅"的可验证证据;API access 场景下,Agent 调用外部 API 时,请求参数先交给 AC2 钱包签名,签名结果证明"什么参数被授权、谁授权的、什么时间";x402 payments 场景下,基于 x402 协议的链上支付细节直接路由到 AC2 钱包,授权时私钥不离开设备;Intent-based actions 场景下,Agent 提交 Google AP2 IntentMandate 一次性签名,后续执行被密码学强制约束。
这五个场景的共同特征是"不可逆、有外部效应、需要可追溯"。这些恰恰是企业 Agent 落地中最敏感的环节。AC2 把这些环节从"事后审计"前移到"事前密码学证明",在工程上是一次质的飞跃。
Agent 通信协议的标准化竞速
把 AC2 放到更宏观的 Agent 通信协议标准化竞速里看,可以看清它的真正战略意义。2026 年下半年,Agent 通信协议领域至少存在 5-6 个并行标准:Anthropic 主导的 MCP(Model Context Protocol,Agent 与工具/数据源的纵向集成)、Google 主导的 A2A(Agent-to-Agent,Agent 之间的横向协作)、IBM 的 ACP(Agent Communication Protocol)、Cisco 的 Agora、Agent Network Protocol(ANP)等等。这些协议各自解决了 Agent 生态的某一部分问题,但"用户意图如何在 Agent 之间传递与证明"这个核心问题,几乎都没有给出明确答案。
2026 年 2 月 arXiv 上线的论文 2602.11327 "Security Threat Modeling for Emerging AI-Agent Protocols: A Comparative Analysis of MCP, A2A, Agora, and ANP" 对这一现状做了系统性梳理。论文明确指出:"no protocol-centric risk assessment framework has been established yet"——目前没有一个"以协议为中心的风险评估框架"被广泛接受。论文提出了 12 项协议级风险,并在 MCP 上做了案例研究:"quantifying wrong-provider tool execution under multi-server composition across representative resolver policies"。换句话说,即使在 MCP 这种已经被广泛部署的协议上,"错供应商工具执行"这种攻击仍然存在,缺乏密码学层面的防护机制。
AC2 在这个协议生态中的独特定位,是把"用户意图"作为独立于 Agent 通信的一等公民来对待。它不试图成为 Agent 之间通信的协议,而是专注于"用户意图如何被安全地表达、传递、验证"。这种"垂直专精"的策略,使 AC2 能够与现有的 MCP、A2A 等协议共存——MCP 处理 Agent ↔ 工具,A2A 处理 Agent ↔ Agent,AC2 处理 Agent ↔ 用户意图。三者互补,不冲突。
从协议到生态:AC2 的真正考验
把 AC2 当作一个独立协议来评估,它在工程上已经做得相当扎实。FIDO2 硬件认证是行业标准、DIDComm v2.0 是 W3C 推荐的 DID 通信协议、Liquid Auth 是 Algorand 基金会自研的身份验证协议栈。这些底座都是被广泛验证的开源标准,AC2 在它们之上的"协议胶水"也设计得相对克制——只定义消息格式、签名协议、用户意图证明语义,而不试图重新发明整套 Agent 框架。这种"克制式创新"在企业级协议中是非常难得的。
但 AC2 的真正考验在于生态扩展。从官网披露看,目前 AC2 仅官方支持 OpenClaw 这一个 Agent 框架。对比 cc-safety-net 支持 13 款 Coding CLI、AgentSight 通过 eBPF 自动支持多种 Agent,AC2 的生态覆盖明显较窄。要成为"AI Agent 通信的缺失安全层",AC2 必须把插件适配到 Claude Code、Cursor、Codex、DeepSeek Harness 等主流 Agent 框架,以及 A2A、MCP 等主流通信协议。这种生态扩展需要 AC2 团队投入大量工程资源,或者通过开放的标准接口让第三方开发者可以快速适配。
另外,AC2 的设计假设用户拥有智能手机作为签名硬件。这在消费场景下是合理假设(几乎每个人都有手机),但在企业场景下可能不成立——很多企业内部场景下,服务器、CI runner、自动化流水线都在没有人类交互的环境下运行,这些场景下"FIDO2 硬件签名 + 用户生物识别"的设计就无法直接套用。AC2 需要为这种"无人值守 Agent"场景设计替代方案,比如"基于 HSM 的服务端签名"、"基于短期凭证的设备绑定签名"等。
对企业 Agent 落地的具体启示
把 AC2 这种协议映射到企业 Agent 落地的具体场景,可以提炼出三条立即可用的启示。第一条是"敏感操作必须有密码学证明"。在企业 IT 治理中,任何涉及金钱、权限变更、数据外发的操作,都应该有"谁在什么时间基于什么理由批准了这件事"的密码学证据。AC2 是目前工程上最接近"开箱即用"的实现,即使最终不直接采用 AC2,它所体现的设计原则也应该被吸收到企业内部 Agent 治理规范里。
第二条是"Agent 通信协议的多协议并存是常态"。MCP、A2A、AC2、ACP、ANP 各有定位,企业 Agent 部署不应该押注单一协议,而应该建立"多协议适配层",让 Agent 工具链能够根据场景选择合适的协议。这种"协议无关"的架构,使得企业不会因为某个协议的兴衰而被迫迁移整个工具链。
第三条是"用户主权与 Agent 自治的平衡点"。AC2 的核心思想是"用户保留对 Agent 的最终控制权",但这并不意味着用户应该介入 Agent 的每一次操作。在企业场景下,合理的做法是把"操作分类 + 风险分级 + 自动化审批"这套机制工程化——低风险操作 Agent 自动执行,中风险操作 Agent 通过 AC2 请求用户签名,高风险操作 Agent 强制要求多因素审批。AC2 在这种分层架构中扮演"用户意图密码学证明"的关键基础设施,但它不是企业 Agent 治理的全部。
回到协议缝隙的本质
把 AC2 这种项目放回 2026 年下半年 Agent 协议生态的整体演进中看,可以提炼出一个更深的洞察:Agent 协议生态的成熟度,并不取决于"有多少协议",而取决于"协议之间的缝隙有多少已经被填上"。MCP 填补了 Agent ↔ 工具的缝隙,A2A 填补了 Agent ↔ Agent 的缝隙,但 Agent ↔ 用户意图这条缝隙长期被忽视。AC2 的出现,意味着 Agent 协议生态正在向"完整的三角关系"(Agent ↔ 工具、Agent ↔ Agent、Agent ↔ 用户)收敛。
这种收敛对企业 Agent 落地具有结构性意义。当三角关系的每一条边都有标准化协议支撑时,企业可以基于这些协议构建"可证明安全"的 Agent 系统——基于 MCP 证明"Agent 调用了什么工具",基于 A2A 证明"Agent 与哪些 Agent 协作",基于 AC2 证明"谁在什么时间授权了什么 Agent 操作"。这种"可证明的 Agent 安全"是 2026 年以前难以想象的,但在 2026 年下半年,它正在变得工程上可行。AC2 这种协议虽然还处于早期,但它所代表的方向——"把用户意图作为密码学一等公民"——是 Agent 协议生态走向成熟的必经一步。对于正在建设企业级 Agent 工具链的团队,这种方向感比 AC2 协议本身的技术细节更重要。