GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
让 AI 代替用户执行链上交易，是当前加密领域最热门的趋势。Coinbase 于 2026 年 2 月推出了 Agentic Wallets，麦肯锡估计到 2030 年由 AI Agent 主导的商业交易规模将在全球达到 3 至 5 万亿美元。正如 Coinbase CEO Brian Armstrong 所说：AI Agent 无法开设银行账户，但它们可以拥有加密钱包。
问题在于，让 AI 操作链上资产，与让它管理日历或邮件有着本质区别。链上交易不可逆，没有退款，没有撤销。一次恶意签名就能在一个区块内清空整个钱包。没有安全保障，任何功能都毫无意义。
BlockSec 已开源 Web3 Companion，这是一款以安全为核心的 Agentic Wallet。本文将深入介绍其背后的安全设计：为何当前 Agentic Wallet 架构存在根本性缺陷，以及我们如何从底层将安全性融入钱包架构之中。
当前 Agent 有多危险：OpenClaw 事件
当 AI Agent 没有任何安全边界时会发生什么？2026 年初的 OpenClaw 事件给出了答案。
OpenClaw 是一款开源通用 AI Agent，五天内在 GitHub 上斩获 10 万颗星。作为通用 Agent，它表现出色，但一旦触及 Web3 交易，所有安全漏洞便暴露无遗。
私钥以明文形式存储在 Agent 可读取的本地文件中，一封提示注入邮件便足以将其窃取。
签名缺乏隔离。抓取不可信网页的进程与签署交易的进程相同，因此一个 RCE 漏洞就能让攻击者通过恶意网页完全控制 Agent 及其密钥。
Skills 市场是另一个薄弱环节。研究人员发现 7.1% 的 ClawHub Skills 存在凭证泄露，部分 Skills 更是被直接设计用于清空加密钱包。
随机数生成也存在缺陷。OpenClaw 在安全关键路径上使用了以系统时钟为种子的伪随机数生成器 math/rand。研究人员证明，只需两个连续的 token 值，就能重建内部状态并预测所有未来的 token 和挑战值。在某些代码路径中，这一漏洞甚至可延伸至钱包密钥恢复。
最严重的是，系统完全没有策略层，在提示注入与资金转移之间毫无拦截机制。
结论：通用 AI Agent 架构并不适合处理 Web3 交易。
当前 AI Agent 架构的根本缺陷
这个问题不只存在于 OpenClaw。更换模型或编写更严格的提示词并不能解决问题。当前 AI Agent 架构存在一个固有的安全缺陷：LLM 本身就是一个永久暴露的攻击面。
根本原因在于：LLM 无法区分指令与数据。系统提示、用户消息、网页内容，甚至 token 的名称，都以同一种 token 流的形式输入。模型没有可靠机制来区分"执行这条指令"与"只是读取这条内容"。由此引发三个后果。
其一，提示注入在模型层面无解。攻击者可以将指令隐藏在 Agent 处理的任何内容中：邮件、合约注释、网页、token 名称。若 Agent 具备签名交易的能力，一次成功的注入便可将恶作剧变为盗窃。
其二，Agent 自身基于 Skills 的安全审查可被绕过。LLM 对交易安全性的判断完全依赖上下文，一旦上下文被污染，判断结果就会逆转，恶意签名得以顺利通过。
其三，Agent 全天候运行，持续消费不可信输入，并能自主执行交易。攻击窗口永远不会关闭，一次入侵便可能导致资金即时损失。
安全社区普遍认同：在提示注入尚无根治方法的今天，让 LLM 直接访问私钥，无异于将用户资产存放在一个随时可能被攻陷的组件中。由于模型层面无法被强化，风险必须在架构层面加以遏制——即便模型被完全攻陷，也不应能转移用户资金。
Web3 Companion 的安全架构正是基于这一理念构建的。
威胁模型：Agent 是不可信的
Web3 Companion 的威胁模型可以用一句话概括：Agent 本身是不可信的。整个架构假设 Agent 随时可能被攻陷。
我们不依赖于将 Agent 训练得足够强大以识别每一次攻击。如上所述，模型层面的防御行不通。今天训练它识别摩斯密码注入，明天攻击者就换成 Base64、图片中的隐写文本，或看似无害的 PDF。为此，我们翻转了假设：Agent 处于威胁模型内部，系统的其余部分被设计用来约束它。即便攻击者完全控制了 Agent，用户资产依然安全。一句话定位：The Secure Agentic Wallet——一款默认将自身 Agent 视为不可信、无论如何都保持安全的钱包。
基于这一威胁模型，我们提炼出五条设计原则。
原则一：Agent 绝不能接触私钥。 私钥是控制链上资产的唯一凭证。若 Agent 能读取私钥，一旦被攻陷便意味着密钥丢失。私钥必须存储在 Agent 在架构层面无法触及的地方。
原则二：构建交易不等于授权交易。 组装交易与批准交易是两个独立的行为。Agent 可以帮助用户了解链上状态并组装意图，但签名决定权属于一个独立的后端模块，Agent 无法访问。
原则三：审查是检测手段，而非执行手段。 交易模拟、calldata 分析、地址标签识别能发现常见攻击模式，帮助用户理解风险，但它们不是最终裁决。模拟可能失败，标签可能缺失，LLM 自身的分析也同样容易受到提示注入攻击。
原则四：硬性策略是最后的防线。 假设 Agent 被诱骗发起 10 万美元的转账，安全审查也被操纵为批准通过——代码层面强制执行的每日 1000 美元限额仍会将其拦截。Agent 无权修改这些限额。
原则五：无证据，不执行。 扫描失败不等于通过，数据缺失不等于"安全"。当安全证据缺失、矛盾、过期或不充分时，系统暂停执行，等待用户明确确认。
这五条原则通过两个安全模块实现：私钥安全与交易安全。
私钥隔离：在架构层面让 Agent 无法触及
第一个问题很直接。我们需要一个能帮助准备链上交易的助手，但若赋予它签名能力，就等于将真实资金的转移权拱手相让。2025 年和 2026 年几乎所有 Web3 Agent 安全事故都遵循同一套路：私钥存在于 Agent 进程内，攻击者找到方法将其提取。
因此我们重新定义了问题：如果 Agent 从根本上就不能签名，会怎样？不是"被告知不能"，而是在架构层面就不具备该能力。软件层面的访问控制始终可以被绕过，我们需要更强的保障。
Web3 Companion 强制实施进程级隔离。只有一个组件接触私钥：安全签名模块（SSM），这是一个独立的 Go 进程。Agent 的进程内存、环境变量和文件系统中不存有任何密钥材料。Agent 所能看到的只是一个交易意图 ID。它可以请求 SSM 对该意图进行签名，但永远看不到背后的密钥。
在密钥存储方面，我们评估了三种方案。明文存储于磁盘：磁盘读取即可立即暴露密钥，已拒绝。基于密码派生的加密：每次重启都需要重新输入，对长时间运行的 Docker 服务不切实际，已拒绝。我们选择了信封加密：每个钱包密钥使用各自的数据密钥加密，数据密钥再由主密钥（AWS KMS 或本地 AES-256）进行封装。即便加密文件被整体窃取，没有主密钥也毫无用处。密钥只在 SSM 内存中短暂以明文形式存在，签名完成后立即清零。
每一个签名请求都经历相同的流程，没有快速通道，没有捷径。一笔交易按顺序经过七个步骤：委托检查、模拟执行、安全检查、Agent 安全审查、策略评估、Passkey 审批，最后才由 SSM 完成签名。完成某一步骤永远不会跳过下一步。
有一个底层细节值得一提：系统中的每一个随机字节——包括私钥生成、AES-GCM nonce、认证 token、WebAuthn 挑战——均来自操作系统级加密随机源 crypto/rand。math/rand 在所有安全关键代码中被明令禁止，并通过测试和 CI 强制执行。
交易安全：四层纵深防御
私钥隔离解决了密钥安全问题，但交易层面的风险依然存在。被攻陷的 Agent 可以组装一笔看似完全合法的交易意图，以欺骗用户或绕过自动签名策略。提示注入不需要私钥，只需让系统通过正常流程对恶意交易进行签名即可。
核心问题在于：当准备交易的 Agent 本身可能已被攻陷时，如何识别恶意交易？
没有任何单一防御层能独立支撑。仅靠模拟执行？模拟会失败，RPC 会宕机，新型攻击超出已知模式。仅靠 LLM 审查？攻陷 Agent 的同一注入也会攻陷审查者，因为两者都运行在 LLM 上。仅靠固定的硬性限额？合法用户寸步难行，每笔 swap 上限 100 美元根本无法使用。
我们将四层全部叠加在一起，每一层都假设前面所有层已经失效。
第一层：交易模拟。 签名前，系统模拟执行：calldata 解码、回滚预测、字段格式检查。模拟能发现明显问题，但存在盲区——新型攻击手法和 RPC 故障都可能令其失效。
第二层：交易对手方评估。 一系列静态检查针对交易对手方展开：接收方/金额匹配、无限授权检测、销毁地址检测、异常委托调用检测。地址风险评分通过 BlockSec 的 x402 合规服务进行，Agent 通过 x402 小额支付查询标签和风险评分，无需 API 密钥或订阅。第一层和第二层合力覆盖大多数常见问题，但两者均可被绕过。它们的职责被明确定位为检测与解释，而非最终决策。
第三层：硬性策略执行。 完全由 Go 代码强制执行，LLM 不参与其中，Agent 无法修改规则。单笔交易限额、每日预算、接收方白名单、自动签名阈值：一笔 5000 美元的转账若超出每笔 100 美元的限额，将被当场拒绝。修改策略本身需要 Passkey。原因何在？若 Agent 能编辑策略，一次注入就能先提高限额，再清空钱包。自动签名默认关闭，在用户明确选择启用之前，每笔交易都需要手动审批。
这意味着，即便所有检测层均被绕过，一个完全被攻陷的 Agent 对恶意交易进行了签名，实际损失也受策略约束。若用户将每日自动签名阈值设为 500 美元，最坏情况下的损失就是 500 美元，而非整个钱包。策略层将一次入侵从灾难性事件转变为有限损失。
第四层：用户确认（Passkey）。 当策略要求手动审批时，系统需要进行 WebAuthn 验证（指纹或面部识别）。任何纯软件漏洞都无法伪造这一验证。
四层防御建立在相互不信任的基础之上，每一层都假设前面所有层已经失效。完美的模拟结果不会放松策略要求，策略配置错误不会跳过 Passkey 验证，每一层都独立成立。
有一个容易被忽视的细节：裁决复用问题。DeFi 中有一种已知攻击手法，会将旧的安全裁决重放至修改后的交易上。Web3 Companion 将每一笔写操作绑定至唯一的交易意图，并配以可审计的状态转换。安全裁决仅适用于其所审查的确切意图。若 Agent 重新构建了一笔交易，哪怕只是修改了金额或接收方，系统也会将其视为全新意图并重新执行所有检查。
四层防御映射到三个独立的信任边界：私钥、策略和 Passkey。任意一个边界被突破，其余两个依然屹立：
| 被突破的边界 | 剩余保护 |
|---|---|
| Agent（提示注入、RCE） | 无密钥 = 无法签名；策略阻断超限操作；Passkey 阻断未审批操作 |
| 安全审查（裁决被污染） | 策略仍强制执行限额；需手动审批的操作仍需 Passkey |
| 策略（用户配置错误） | 需手动审批的操作仍需生物特征验证 |
| 除 Passkey 以外的一切 | 凭证与硬件绑定；攻击者需要用户亲身在场 |
安全即设计：开源背后的理念
BlockSec 自创立之初便深耕链上安全领域。我们保护过数十亿美元的链上资产，并一次次印证同一个教训：安全若不从架构层面内嵌，事后补救永远为时已晚。
AI Agent 正在成为链上交易的新入口。这一领域发展迅猛，但安全标准几乎一片空白。大多数团队专注于 Agent 能做什么，鲜有人认真思考：如果这个 Agent 被攻陷，架构能否限制爆炸半径？
Web3 Companion 是 BlockSec 将多年链上安全经验注入 Agentic Wallet 架构的成果。代码完全在 MIT 许可证下开源（当前标注为研究预览版）。行业现在就需要一个具体的安全设计参考基准——如何构建威胁模型、如何隔离密钥、交易防御应推进到何种程度——没有哪个团队应该从零开始重新发明这一切。我们公开完整设计，希望社区能在此基础上继续构建。
