攻击者已经用上 AI，我们的防线也必须改变
攻击者已经在用 AI 寻找我们的薄弱之处。防守的人如果还按过去的速度、过去的边界做安全，下一次事故就可能从那些我们以为已经检查过的地方开始。
11 月 3 日，币安公布了重大安全事件的初步调查。这份复盘呈现的，不是一个孤立的“私钥泄露”故事：假面试、被替换的开发工具、内部系统和部署凭据，最后一路连到了资产签名。[1]
几天前，我写了一篇行业自救倡议书。今天的新信息，让我更想把那个呼吁往前推一步：我们应该具体改什么？尤其当攻击者已经能够借助 AI 阅读代码、寻找缺口，防守者怎样用同样的工具，重新建设自己的防线？
我们自己也被迫面对了这些问题。作为 ArcBlock 的 founder，我不想只讨论别人的事故。这篇文章，也包括我们自己的反思。
一次入侵，怎样走到资产签名
按币安的初步复盘，9 月，一名工程师被假招聘面试诱导，在工作电脑上安装了面试项目。恶意程序替换了本机的 Python 版本管理工具 pyenv。10 月，攻击者又借助受控设备和内部 AI 工具，进一步侵入其他工程师的环境。后续操作用到了一人的容器部署凭据，以及另一人的设备，最终触及签名服务。[1]
这里的 pyenv 是在受害设备上被替换，不能据此说官方项目本身被攻破。报告也不足以证明这次攻击全程由 AI 自动完成。值得警惕的是，内部开发工具、人的角色和部署权限，被组合成了一条通向资产的路径。
更关键的是后半段：攻击者通过 EIP-7702，让账户把操作交给恶意程序执行。这种委托一旦在链上生效，关闭原来的提现和热钱包服务，也不会自动把它收回；币安随后进行了链上撤销。[1] 停掉一台服务器，与收回一个账户已经授出的资产处置权，是两件不同的事。
这也是我认为必须重新检查系统边界的原因。工程师需要开发工具，DevOps 需要部署权限，签名服务也要服务业务。每一项单独看，都有存在的理由。但它们组合之后，是否让一个已经失陷的环境获得了远超本职需要的能力？最后一道资产约束，又是否独立于这些环境？
前一段时间，我们的 Blocklet Server 体系也遭遇了攻击。我们及时发现，没有造成财务损失。但攻击者找到了一处隐蔽的权限边界问题，获得了本不应拥有的更高权限。我们事后分析时，觉得这条路径相当精巧，也怀疑其中使用了 AI 辅助代码分析。这是我们的技术判断，目前不能当作已经证实的攻击归因。
这件事促使我们用 AI 重新审视自己的链、密码学相关实现，以及使用的开源依赖。我们找到了不少令人不安的潜在问题。我们此前公开的 Blocklet Server 安全加固公告，记录了部分凭据权限、输入校验和日志方面的改进。
这些发现需要逐项验证：攻击路径是否可达，触发需要哪些权限，是否存在模型误判。一个潜在问题未必能直接造成损失，但这些候选问题已经让我们重新追问：过去的审查，有多少地方根本没有覆盖到？
安全领域常用 James Reason 的“瑞士奶酪模型”解释这种风险。你可以把几层防护想成几片都有孔洞的奶酪：一层漏掉的事情，另一层本来可能挡住；当一条攻击路径恰好穿过多个缺口，局部问题就可能串成事故。[2]
这是风险组合的示意，不是币安内部架构图。某些漏洞本身就足以造成严重后果；多层防护的价值，是让一个缺口不必然成为整套系统的失败。
AI 让人担心的一个变化，是它能够更快地阅读大量代码，并尝试把分散的问题联系起来。Anthropic 在 2025 年披露的攻击案例中，就记录了攻击者用 AI 辅助侦察、寻找漏洞和横向移动，同时也记录了模型的错误与误判。[3] 我们不必相信 AI 已经无所不能，才开始改变防守方式。
重新审计，也重新审视我们相信什么
过去，阅读庞大代码库、追踪跨模块权限，需要大量时间和经验。现在，这些工作可以让 AI coding agents 先做一轮，甚至持续地做。防守者拥有源码、运行环境和设计背景，理应比外面的攻击者更有条件验证问题。
难处往往在发现之后。
一段代码可能支撑着多年兼容性；一套旧的密钥格式，可能已经写进了用户备份；一个看起来应该拆掉的权限，可能正被多个服务共用。AI 可以帮你找到问题，却不能替团队免除迁移成本。多年积累仍然有价值，但那些我们很难改变的部分，也可能成为攻击者最愿意研究的地方。
所以，我想推动的是持续的 AI 辅助审计：让 agent 沿着真实权限边界检查输入、依赖和状态变化，把怀疑变成可复现的案例，再由人和独立工具验证。修复之后，还要留下能证明旧问题不会重现的检查。没有复现、修复和复验，堆出一份“发现很多漏洞”的报告，意义有限。
审计用的 agent 自己也必须受到约束。读取源码和执行复现，应该与生产密钥、部署权限隔离。代码注释、依赖说明和测试输出，都是被检查的材料，不能因此成为扩大权限的指令。如果一个审计工具顺便获得了贯通生产的能力，我们就又建起了一条想要拆掉的攻击路径。
这也让我重新看待 Crypto 行业常说的一句话：开源有无数双眼睛，所以更安全。
开源提供了重要的审查条件。问题是，源码放在那里，与真的有人持续审查、及时修复，是两回事。攻击者现在可以带着明确目标和 AI 来阅读同一份代码。防守方如果仍然只等待热心的人偶然发现问题，那种等待就显得更加被动。
源码可见，已经不足以作为安全背书。公开源码，或者只向客户和指定审计者披露源码，都需要可复验的审计。
企业系统中只向客户或指定审计者提供源码的方式，也有值得重新讨论的价值：它可以限制源码的直接获取范围，并为修复保留协调空间。但代价同样明确，外部审查范围会缩小，用户需要更依赖厂商，攻击者也仍可能通过逆向、泄露或实际接口研究系统。闭源本身不会让漏洞消失。
AI 给了用户更多自己检查软件的能力，前提仍然是能够取得需要审查的材料。无论采用什么披露方式，都应该问得更具体：审查的是哪个版本？结论能否重现？修复是否进入实际运行的系统？一个认证标志、一份漂亮的审计报告，或者一份公开仓库，都不能代替这些问题。
钱包需要的不只是更难偷的钥匙
硬件钱包 COLDCARD 的公告提醒受影响用户：更新固件可以纠正未来的种子生成，却不能修复已经生成的有问题的种子。Ledger 披露的另一起事件，则涉及被改装后重新进入分销渠道的设备，在设置时截取恢复短语。两件事的入口不同，但都说明硬件保护之外，还有生成、交付、备份和恢复的完整过程。[4] [5]
尤其是随机性出了问题时，用户甚至不必主动泄露私钥，资产就可能有风险。让一个已经知道危险的人，只能赶紧拿旧钥匙把全部资产转出去，是非常脆弱的应急安排。
我们正在把更多设计工作转向 Passkey、成熟的安全硬件能力，以及密钥轮换与恢复机制。ArcBlock 链的 v1.19.x 已经支持原生 Passkey 账户。但一项签名能力已经可用，与一整套更可靠的钱包已经做完，距离还很远。
Passkey 值得采用，因为它通过密钥证明身份，并把登录验证与正确的网站绑定，减少了某些钓鱼风险，也能借助成熟设备的安全能力。但它有同步型和设备绑定型之分，不能一概说密钥永远不离开某一块芯片。恢复账户的安全性、设备丢失后的处理，以及用户究竟授权了什么，仍然要设计。[6]
一个人成功解锁了设备，并不表示他正在批准一笔合理的交易。 即使密钥没有被导出，被控制的软件仍可能诱导用户签署错误的请求。这是我不愿把改进钱包简单写成“用 Passkey 替换助记词”的原因。
更值得从企业安全借鉴的是密钥的完整生命周期：生成、使用、权限限制、轮换、撤销、恢复。一个长期存在的账户，不应该只能与同一把钥匙共存亡。日常支付钥匙可以只有小额度；大额操作需要另一组独立授权；恢复流程也必须防止被日常钥匙单方面改写。这些机制会增加设计与使用成本，但成本应该由产品认真处理，而不是一句“保管好助记词”全部推给用户。
钱包协议也应该让个人用户与交易所共享一部分基础能力：明确表达谁能动什么、能动多少、去向哪里，以及异常发生后怎样收回权限。个人小额消费与交易所热钱包可以采用不同策略，不必各自重新发明一套看不见的权限系统。
这里有个很实际的问题：当我们已经知道一把钥匙或一个环境失陷时，还有没有办法踩下刹车？
传统支付系统并非不会出事，但它们把限制和处置当作业务的一部分。Visa 的 Transaction Controls 可以在授权环节应用交易规则；Swift 的 Stop and Recall 提供止付与召回请求机制。后者需要满足流程条件和相关机构配合，并不意味着任何已经最终结算的款项都能追回。[7] [8]
区块链不能照搬银行的权力结构，却应该认真借鉴这种准备：限额、延迟、暂停、撤销，以及恢复后的重新授权。Bitcoin 的脚本和 Ethereum 的合约已有一些相关工具；我们缺少的是广泛可用、容易正确配置、经过演练的完整体验。普通原生 BTC、ETH 转账也没有一个发行人替所有人统一冻结的开关。
USDC 则提供了另一种对照：发行方可以在特定条件下阻止某个地址收发 USDC，但这不能撤回已经完成的转账。[9] 冻结可以限制资产继续流转，同时也引入了对发行方的依赖。它与用户预先设置自己的止损规则，是不同的权力安排。
我更倾向于让用户预先选择自己的约束。比如，大额转账有等待期，新收款人要经过独立确认，紧急暂停只能阻止支出，不能把钱划给另一个人。暂停由谁触发、怎样解除、会不会被恶意滥用，都必须公开设计。如果管理员能任意夺走资产，只是把风险搬到了另一个地方。
Crypto Frontier：把新的防线建在可以验证的地方
这些改进，需要更小、更明确的底层规则来承接。
在企业系统里，访问控制经常通过规则或专门的策略语言表达。这种设计的价值，是把“能做什么”从复杂业务代码中分出来，方便独立检查。策略语言最终也由程序执行，规则写错一样危险。值得借鉴的是缩小需要信任的范围，让日常业务不能随意改写自己的约束。
Ethereum 有访问控制、时间锁和暂停等合约工具。执行这些合约的运行环境 EVM，当然有安全基础。[10] 但工具需要应用正确使用：如果有人能替换负责检查的合约，或者把操作交给不受同样限制的程序，原来的保护就可能失效。我们应该继续追问：哪些资产策略可以成为统一的、独立的约束，而不是每个钱包、每个协议自己补一次？
2017 年的 Parity 事故，是一个沉重的历史提醒：多个钱包共同使用的一份程序库被销毁，钱包自己还在，却无法再正常动用资金。[11] 今天的 EVM 语义和工具已经变化，不能把当年的具体漏洞原封不动套到今天；但“我的最后一道保护，是否依赖于同一段可以出错或被改写的代码”，仍然值得问。
举个可以讨论的设计：日常钥匙只能向已确认的地址小额付款；修改额度和收款名单，需要三把分别保管的管理钥匙中的两把批准，并等待一天。紧急暂停可以立即阻止支出，但恢复付款要经过另一套预先约定的核验，不能由日常钥匙自己解除。
这个例子里，“独立”有具体含义：偷走日常钥匙的人，不能先改规则再转走全部资产。它也有清楚的边界：如果管理钥匙并没有真正分开保管，或者足够多的管理者一起失陷，保护仍然可能失败。不同资产的授权、委托和转账路径，也都要受同样的限制，不能只挡住界面上的那个付款按钮。
AI 可以帮助分析一笔请求是否异常，建议加强核验或者触发预先授权的暂停。但它不应该成为一个拥有任意资产处置权、又无法解释的最终裁决者。区块链的不同节点必须按相同规则判断交易是否合法，才能得到一致的账本。一个会随模型、上下文而变化的回答，不能未经处理就成为所有节点必须服从的判据。
这也是我理解的 Crypto Frontier：沿着已经暴露的失败边界，建立下一道可验证的防线。
前篇的七项建议，本文重点展开了其中两项：限制资产处置权，以及让钱包可以安全恢复。减少交易服务对用户资产的控制、只披露必要信息、隔离和替换故障组件、让用户自己核验链上证据、共享检测与应急经验，则是这条防线向外延伸的工作。它们的完整讨论可以回到前篇，不必等七项都完成，才开始修好其中一项。
身份标准也可以成为其中的工具。例如，用 W3C 的去中心化标识符（DID）描述身份及其验证方式，用可验证凭证（VC）携带能核验来源的资格声明。但一张“有资格操作”的凭证，仍然要交给明确的授权规则，才能判断此刻能操作什么、额度多少。[12] [13] 同样，让钱包自己核验交易被记入链上的证据，也只是减少对远程服务的盲信，不能替用户识别所有骗局。
这些都不是只属于某一条链的题目。协议标准、企业安全和传统支付，已经积累了很多可以借鉴的东西。我们应该把它们放到 Crypto 的现实约束下重新验证，保留有用的部分，而不是因为来自另一个技术传统就忽略它。
前一篇文章发出后，有不少人转发、收藏，也有人重新联系我，有媒体提出采访。这些回应让我感到，这个问题确实被很多人放在心上。真正表示要一起动手的人，目前还不多。我觉得这很正常：表示认同，与投入长期建设，是两种不同的负担。
我们会继续做自己能做的那一部分：用 AI 检查存量系统，把确认的问题修好，验证新的钱包与授权机制，也把适合公开的经验拿出来。已经实现的、正在探索的、还没有答案的，分别说清楚。
攻击者已经把 AI 带到了我们的门前。我们也该用它重新检查地基，修补旧系统，并建设下一道防线。 Crypto 的新 Frontier，要从这些具体工作里长出来。
- Binance：2026 年 10 月 30 日安全事件初步调查与响应更新，2026 年 11 月 3 日。报告按 UTC+8 记为 10 月 30 日，与前篇按 UTC 记录的 10 月 29 日为同一事件；调查仍在继续。 ↩
- James Reason，Human error: models and management，BMJ，2000 年，PMC 收录全文。 ↩
- Anthropic：Disrupting the first reported AI-orchestrated cyber espionage campaign，2025 年 11 月 13 日。文中事件与归因来自厂商披露。 ↩
- COLDCARD：Current Security Status，查阅于 2026 年 11 月 3 日，包含受影响种子迁移的说明。 ↩
- Ledger：Response to the Hardware Implant Attack。文中对事件范围的描述来自厂商回应。 ↩
- FIDO Alliance：Passkeys。 ↩
- Visa：Getting Started with Visa Transaction Controls。 ↩
- Swift：Stop and Recall API。 ↩
- Circle：Understand Circle’s stablecoin blocklisting process。 ↩
- OpenZeppelin Contracts：Pausable。 ↩
- Parity Ethereum：2017 年共享钱包库事故原始 issue。 ↩
- W3C：Decentralized Identifiers v1.0。 ↩
- W3C：Verifiable Credentials Data Model v2.0。 ↩