GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
让 AI 代替用户执行链上交易，是当前加密领域最热门的趋势。Coinbase 于 2026 年 2 月推出了 Agentic Wallets，麦肯锡预测 AI Agent 中介的商业交易规模到 2030 年可能在全球达到 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，在五天内斩获 10 万个 GitHub Star。作为通用 Agent，它运行良好，但一旦涉及 Web3 交易，所有安全漏洞便暴露无遗。
私钥以明文形式存储在本地文件中，Agent 可以直接读取。仅需一封包含提示词注入的邮件，就足以将其窃取。
签名没有隔离。抓取不可信网页的进程与签署交易的进程相同，因此一个 RCE 漏洞就能让攻击者通过恶意网页完全控制 Agent 及其密钥。
Skills 市场是另一个薄弱环节。研究人员发现 ClawHub Skills 中有 7.1% 会泄露凭证，部分甚至是专门为清空加密钱包而设计的。
随机数生成同样存在缺陷。OpenClaw 在安全关键路径上使用了 math/rand——一种以系统时钟为种子的伪随机数生成器。研究人员证明，只需连续两个 token 值，就足以重建内部状态并预测所有未来的 token 和质询值。在某些代码路径中，这甚至可以延伸至钱包密钥的恢复。
最严重的是，系统缺少策略层。提示词注入与资金转移之间毫无拦截机制，零拦截。
结论：通用 AI Agent 架构并不适合 Web3 交易。
当前 AI Agent 架构的根本缺陷
这个问题不只存在于 OpenClaw。换一个模型或写更严格的提示词并不能解决问题。当前 AI Agent 架构存在一个固有的安全缺陷：LLM 本身是一个永久暴露的攻击面。
根本原因在于：LLM 无法区分指令与数据。系统提示、用户消息、网页内容，甚至代币名称，都以相同的 token 流输入。模型没有可靠的机制来区分"执行这个"和"只是读取这个"。由此产生三个后果。
其一，提示词注入在模型层无解。攻击者可以将指令隐藏在 Agent 处理的任何内容中：邮件、合约注释、网页、代币名称。若 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 万美元的转账，安全审查也被操控通过。代码强制执行的每日限额 1,000 美元仍会将其拦截。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 无法修改规则。单笔交易上限、每日预算、收款方白名单、自动签名阈值：一笔 5,000 美元的转账在单笔上限 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 许可证下完全开源（目前标注为研究预览版）。行业现在需要一个具体的安全设计参考点。如何构建威胁模型、如何隔离密钥、交易防御应推进到何种程度——没有任何团队应该从零开始重新摸索这些问题。我们发布完整设计，让社区能够在此基础上继续构建。
