2026 年 8 月 27 日,Show HN 上线了一个非常具体的工程方案——AC2 Protocol(ac2protocol.org),自我定位为"the missing security layer for AI agents"。它的提出者是 Algorand Foundation 团队里负责 Pera Wallet 的工程师,核心思路是把 Agent 的"用户授权"从传统的 chat-ba
2026 年 8 月 27 日,Show HN 上线了一个非常具体的工程方案——AC2 Protocol(ac2protocol.org),自我定位为"the missing security layer for AI agents"。它的提出者是 Algorand Foundation 团队里负责 Pera Wallet 的工程师,核心思路是把 Agent 的"用户授权"从传统的 chat-based 确认(那条"是否同意?"的 yes/no 消息)升级为基于 FIDO2 passkey 的硬件绑定签名,并把 Agent 的"密钥管理"从"塞进 runtime"改成"签名授权,不接触真实 key"。HN 上 49464979 这条帖拿到了 17 个 points 和 16 条评论,讨论热度不高,但工程上的方向值得严肃对待——它正面回答了"Agent 时代怎么证明'这个动作确实是这个用户批准的'"这个所有 Agent 协议都没解决的基础问题。
本文把 AC2 Protocol 的 HN 帖和官方文档(2026-08-27)、HN 评论里关于"crypto stink"和"agent governance"的真实工程讨论,合并改写,从"为什么 chat-based approval 不够"、"AC2 的工程方案是什么"、"这套方案对企业级 Agent 信任根意味着什么"三个角度,展开聊一聊这件事。
一、Chat-based Approval 为什么不安全
先回到一个朴素的事实:今天所有 AI Agent 在执行"高风险动作"之前的(之前的人类批准,都是"在 chat 里弹一条'是否同意?'消息"。Claude Code 在执行破坏性操作前会问"Sensitive commands require approval. Proceed?",Cursor 在删文件前会问"Delete this file?",Codex 在调用外部 API 前会问"This will make a network request. Continue?"。这种"chat-based approval"是过去几年 Agent 框架默认的事实标准。
但这种方案在工程上有三个根本性的弱点,这些弱点是 AC2 想要正面回应的。
第一个弱点是可伪造性。chat 里的"approved"只是一段文本,攻击者只要能改 runtime 的 prompt、或者注入一段 prompt injection,就可以伪造一个"user approved"的消息流。HN 上 AC2 帖的作者 josephcecala 原文是:"chat-based approvals are just messages, spoofable and session-hijackable"。这条判断是工程事实——没有任何密码学保证这段消息真的是用户发的。
第二个弱点是没有审计追踪。一段 chat 消息没有可信的 timestamp、没有可信的设备指纹、没有可信的抗篡改存储。一个攻击者伪装成用户批准了一个危险操作,事后审计员看聊天记录只能看到一段"approved"文本,完全无法证明这段文本是用户本人发的、还是 attacker 注入的。
第三个弱点是密钥泄露面太大。传统 Agent 框架里,API key、OAuth token、SSH key 这些敏感凭据,通常需要被注入到 Agent 的 runtime 里(否则 Agent 没法主动调用)。这意味着 runtime 被攻破 = 所有凭据被偷。OneCLI、OtoDock、Harden.run 这些项目都在用不同方式(密钥隔离、Vault 代理、IRM hook)对治这个问题,但都没有从协议层面给出根上的解。
二、AC2 Protocol 的工程方案
把 AC2 的 HN 帖和官方文档合并,可以看到三个工程基线设计。
第一个基线是"approvals 是 FIDO2 passkey signature,不是 chat message"。当 Agent 需要执行一个高风险动作(支付、git push、调外部 API),它不会在 chat 里发一段"是否同意?"的文本——它会通过 AC2 的协议栈向用户的钱包发起一个 FIDO2 签名请求,用户的硬件设备(Pera Wallet、YubiKey、Touch ID、Window Hello)在本地完成签名,签名结果通过端到端加密的 WebRTC 通道送回 Agent。这个签名是硬件绑定的、抗钓鱼的、不可重放的,本身就构成了一条不可否认的审计记录——任何人看到这个签名,都能验证"这个动作确实是这个用户在他们自己的设备上批准的"。
第二个基线是"credentials never enter the runtime"。Agent 在执行动作时拿到的不是真实的 API key、OAuth token、SSH key,而是一份"已签名的授权书"(signed authorization)。这份授权书的有效期、权限范围、撤销机制都在签名里强制约束。Agent 可以用这份授权书去调外部服务,但即使整个 runtime 被攻破,攻击者拿到的也只是这份授权书,不是底层 key——key 永远留在用户的硬件设备上。
第三个基线是"三个开放标准组合"。AC2 不是发明新协议,而是把三个已经成熟的开放标准组合起来:DIDComm v2.0(消息协议,用于 Agent 和 wallet 之间的结构化通信)、WebAuthn/FIDO2(硬件绑定认证,用于签名和反钓鱼)、WebRTC DataChannel(P2P 传输,用于端到端加密的传输通道,不依赖任何 relay 服务器)。这条组合的好处是"零新攻击面"——任何对这三个标准的攻击,都可以借鉴过去十年的研究;不需要为 AC2 重新发明新的密码学原语。
三、对企业级 Agent 信任根的工程启示
把 AC2 的设计抽象出来,有三条对国内企业构建 Agent 信任根体系特别有借鉴价值的工程启示。
第一条启示:Agent 的人类批准必须从"消息"升级为"密码学签名"。今天国内很多 AI Agent 项目里的"高风险操作二次确认"都是 chat-based 的——Agent 在 chat 里弹一条"Are you sure?",用户回 "yes",Agent 就继续做。这条交互链路在工程上没有任何密码学保证,审计员事后无法验证"用户真的批准了吗"。AC2 给出的方向是:把"批准"从 chat message 升级为 FIDO2 级别的硬件绑定签名,即使用户的 chat 历史被攻破,审计员也能从签名层验证动作的真实来源。
第二条启示:Agent 的密钥必须从"塞进 runtime"升级为"签名授权,不接触 key"。OneCLI、OtoDock 这种 agent platform 的核心价值之一就是"密钥不进 agent 上下文",但它们的实现方式是"gateway 拦截 + 注入",中间还是有一个集中的 gateway 持有真实 key。AC2 的方向更进一步:key 永远在用户的硬件钱包里,Agent 拿到的只是"已签名的授权",没有任何中间环节可以偷到 key。这条思路在国内企业里特别有价值——金融、医疗、政企场景里"代码、密钥、操作日志不能出域"是硬约束,任何持有真实 key 的中间环节都是潜在的合规风险。
第三条启示:Agent 协议层应该站在已有开放标准之上,而不是发明新东西。AC2 没有发明新的密码学原语、新的消息协议、新的传输协议,而是把 DIDComm、WebAuthn、WebRTC 这三个成熟标准组合起来。这条选择对国内企业落地 Agent 协议非常重要——任何"为了 Agent 而发明的新协议"都会面临"生态接受度低、实现质量参差、安全审计无依据"的困境,而把已有标准组合起来是更稳的工程路径。
四、AC2 Protocol 在工程社区的真实争议
把 HN 上 49464979 这条帖子下面的 16 条评论合并看,会发现 AC2 在工程社区里引发了两条主要的争议。
第一条争议是"crypto stink"。几个 HN 用户直接质疑 AC2 是不是又一个"把上一波 crypto 概念强行套到 AI 上的项目"。一位用户直言:"This is just trying to salvage ideas and tools from the last fad into the current one。"这条质疑背后是真实存在的工程问题:过去几年 crypto 行业确实造了很多"看起来很 fancy 但实际工程价值不大"的协议,这些协议被搬到 AI 时代之后,经常会被工程社区贴上"crypto stink"的标签。AC2 的解药是"它的密码学部分全部基于 WebAuthn/FIDO2 这种已经被 W3C/FIDO Alliance 标准化的成熟协议,不是新发明"——但这个解药能不能说服工程社区,目前看还在博弈中。
第二条争议是"agent governance 是不是必须靠 crypto"。一位用户(motohagiography)给出了一个非常有意思的类比:"the only thing reliably containing humanity is interstellar distances, and the equivalent for ASI would be cryptographic distances"。意思是:Agent 时代的安全边界只能靠密码学,这是不可绕过的物理限制。这条类比呼应了 Anthropic、OpenAI 内部安全研究的核心假设——Agent 一旦超过人类智能,任何非密码学的安全机制都会被 Agent 自己绕过去,只有密码学层面的硬约束才是真正的可信边界。AC2 的设计正好和这条假设吻合:approvals 是密码学签名,credentials 是硬件绑定,运行时密钥不落地。
五、AC2 Protocol 还没解决的工程问题
把 AC2 夸完,也得指出这套方案目前还没解决的几个工程边界。
第一个边界是WebRTC 的连通性。WebRTC DataChannel 在大多数企业内网环境下需要 STUN/TURN 服务器,或者直接被防火墙阻断。AC2 的 HN 帖里没有详细讨论"如果用户的 wallet 在家里、Agent 在企业内网,WebRTC 怎么连得通"这条工程问题。这是 P2P 架构的普遍短板,目前业内有 ICE/TURN 的标准解法,但企业部署时仍然需要额外配置。
第二个边界是签名授权的撤销机制。如果一个用户批准了一个签名授权,但 5 分钟后意识到授权给错了——他能撤销吗?传统 OAuth 的 access token 有过期时间和 refresh 机制,FIDO2 签名是不可撤销的(签名一旦做出就永远有效)。AC2 的方案目前没有详细说明"已签名授权"的撤销路径,这件事在企业场景里几乎是必须的(比如管理员批准了一个 Agent 调 SAP 的授权,但 Agent 之后开始乱操作,管理员要能立刻撤销授权)。
第三个边界是密钥管理的用户体验。FIDO2 passkey 的体验比 chat-based approval 复杂得多——用户需要购买或者激活硬件设备、需要管理 passkey、需要懂"什么是签名"。这件事在 crypto-native 用户群里没问题,但在普通企业用户群里会形成巨大的采用门槛。AC2 的 HN 帖里 josephcecala 说"one plugin, one command",但这条营销话术掩盖了"用户必须自己持有 wallet"的真实使用门槛。
六、结论:Agent 信任根必须从 chat 升级到密码学
回到标题那个问题:AC2 Protocol 给出的工程基线回答了一个所有 Agent 协议都没解决的基础问题——"Agent 时代怎么证明'这个动作确实是这个用户批准的'"。AC2 的答案不是"在 chat 里再加一条 Are you sure?",而是"用 FIDO2 硬件签名替代 chat 消息,用签名授权替代密钥注入,用 WebAuthn 的抗钓鱼特性替代 session hijacking 防护"。这套方案在工程上不是新发明,而是把三个已经成熟的开放标准组合起来。
对国内企业把 Agent 落到生产环境里,这件事的真正意义是:Agent 的信任根必须从 chat-based 升级到密码学-based。下次再有人跟你说"我们的 Agent 有二次确认机制",你可以反问一句:"二次确认是基于 chat 文本还是基于密码学?密钥是在 runtime 里还是硬件钱包里?签名有审计追踪吗?授权有撤销机制吗?"——这四个问题的答案,就是判断一个 Agent 项目的"人类批准"机制能不能扛住 Agent 时代安全边界的最低门槛。
参考资料:
- josephcecala, *Show HN: AC2 Protocol: The missing security layer for AI agents*, 2026-08-27, news.ycombinator.com/item?id=49464979
- AC2 Protocol 官方文档, ac2protocol.org, 2026-08
- Algorand Foundation / Pera Wallet 团队, github.com/perawallet, 2026
- W3C, *WebAuthn Specification*, w3.org/TR/webauthn
- DIF, *DIDComm v2.0 Specification*, identity.foundation/didcomm
- IETF, *WebRTC DataChannel*, rfc8831