GitHub: https://github.com/blocksecteam/web3-companion
Docker: https://hub.docker.com/r/blocksecteam/web3-companion
让 AI 替人做链上交易，是 2026 年 crypto 行业最热的方向。Coinbase 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 能读到的本地文件里，一封带 prompt injection 的邮件就能把私钥拿到。
签名也没有隔离。负责读取不可信网页的进程同时有权签名交易，这意味着攻击者只需要一个 RCE 漏洞，就能通过一个恶意网页完全接管 Agent 和它的密钥。
它的 Skills 市场也是个口子。安全研究者发现，ClawHub 市场里有 7.1% 的 Skills 存在凭据泄露问题，其中还有专门用来清空加密钱包的恶意 Skills。
随机数也有问题。它在多条安全关键路径上用了 math/rand，一个拿系统时钟当种子的伪随机数生成器。研究者证明，只要盯着连续两个令牌值，就能反推出内部状态，进而预测后续所有令牌和挑战值，某些分支甚至能推到钱包密钥（来源）。
最要命的是没有策略层。Agent 在签名前不受任何系统层面的硬性限制，从 prompt injection 到资金被转走，中间零拦截。
这些问题加在一起，说明一件事：通用 AI Agent 的架构直接用于 Web3 交易场景，是不安全的（来源）。
当前 AI Agent 架构的先天缺陷
这不是 OpenClaw 一家的问题，换个模型、把提示词写严一点也解决不了。当前 AI Agent 架构存在天生的安全缺陷：LLM 本身就是一个持续暴露的攻击面。
核心原因是 LLM 天生分不清指令和数据。对模型来说，系统提示词、用户消息、从网页抓回来的内容，甚至一个代币的名字，都是同一串 token，它没有一个稳定的办法去分辨哪些是该执行的命令、哪些只是该读的内容。由此产生三个安全后果。
第一，prompt injection 无法从模型层面根治。攻击者可以把指令藏进任何 Agent 会读到的东西里，邮件、合约注释、网页、代币名都行。一旦 Agent 能直接签名交易，一次注入就能把恶作剧变成真金白银的盗窃。
第二，Agent 自己基于 Skills 的交易安全审查也能被绕过。让 LLM 去判断一笔交易安不安全，它的结论完全依赖上下文，上下文一被操纵，结论就跟着被操纵，恶意签名照样发出去。
第三，Agent 7x24 小时运行，持续处理来自外部的不可信输入，而且能自主执行交易。攻击窗口永远开着，一次成功的攻击就可能造成资金损失。
安全圈对此已经有了共识：让 LLM 直接持有私钥、直接签名交易，在 prompt injection 无法根治的前提下，等于把用户资产暴露在一个随时可能被攻陷的组件面前。模型层面防不住，就必须在架构层面隔离风险：即使模型被完全攻陷，用户资金也不受影响。
Web3 Companion 的整个安全架构就是围绕这个思路设计的。
威胁模型：Agent 本身不可信
Web3 Companion 的威胁模型只有一句话：Agent 本身不可信。整个架构的设计前提，就是 Agent 随时可能被攻陷。
我们不指望把 Agent 训练得足够强、让它学会识破所有攻击手法。前面已经说清楚，靠模型自己防是防不住的。今天教会它认出摩斯密码，明天攻击者就换成 Base64、换成藏在图片里的字、换成一份看着人畜无害的文档。于是我们干脆反过来，把 Agent 放进威胁模型里，再围绕这个不可信的组件设计整个系统：哪怕 Agent 被完全控制了，用户的资产也动不了。Web3 Companion 的定位就一句话：The Secure Agentic Wallet，一个默认 Agent 不可信、却依然安全的链上钱包。
基于这个威胁模型，我们定了五条设计原则。
原则一，Agent 绝不能碰私钥。 私钥是掌控链上资产的唯一凭证，只要 Agent 能读到它，Agent 一旦被攻破，私钥就跟着丢。所以私钥必须放在 Agent 从架构上就够不着的地方。
原则二，准备不等于授权。 准备一笔交易，和授权这笔交易，是两件根本不同的事。Agent 可以帮用户看懂状态、把交易意图拼出来，但最终是否签名，由 Agent 无法访问的独立后端模块决定。
原则三，审查是检测层，不是执行层。 交易模拟、calldata 分析、地址标签这些手段都有用，能发现常见的攻击套路、帮用户把风险讲清楚，可它们不能作为最终的安全判定。模拟会失败，标签会缺，LLM 的安全分析本身就能被 prompt injection 操纵。
原则四，硬策略是最后的兜底。 万一 Agent 被操纵发起一笔 10 万美元的转账，安全审查又被操纵着说了句安全，这时候还得有一层能拦住它，前提是日限额定在 1000 美元。这层限制由代码强制执行，Agent 没有权限修改。
原则五，证据不足则拒绝执行。 扫描失败不算通过，缺数据不算安全。一旦安全证据缺失、自相矛盾、过了期或者不够用，系统不会自作主张放行，它会停下来，由用户亲自确认。
这五条原则落到实现上，对应两个核心安全模块：私钥安全和交易安全。下面逐个说。
私钥隔离：让 Agent 从架构上碰不到密钥
第一个问题最直接。我们想要一个能准备链上交易的助手，可一旦给了它签名能力，就等于把转移真金白银的权力也交了出去。2025 到 2026 年几乎每一次 Web3 Agent 被黑，都是同一个套路：Agent 进程里存着私钥，攻击者通过各种方式拿到了私钥。
于是我们换了个问法：要是 Agent 压根没法签名呢？我们要的是架构上彻底做不到。仅靠权限控制不够，软件层面的访问限制都有可能被绕过。
Web3 Companion 的做法是进程级隔离。整个系统里只有一个组件碰得到私钥，叫安全签名模块（SSM），跑在一个独立的 Go 进程里。Agent 侧的进程内存、环境变量、文件系统里压根没有密钥材料。Agent 能拿到的只有一个交易意图编号，可以请求 SSM 签名，但永远看不到编号背后的密钥。
私钥的存储方式我们对比了三种方案。明文存盘，磁盘被人读了私钥直接泄露，否决。拿用户密码派生出密钥来加密，可每次重启都要用户重新输一遍密码，对一个长期跑着的 Docker 服务来说太折腾，否决。最后选的是信封加密：每个钱包私钥用一把单独的数据密钥加密，这把数据密钥再交给主密钥（AWS KMS，或者本地的 AES-256）加密。这么一来，就算加密文件被整个端走，没有主密钥也解不开。私钥只在 SSM 进程的内存里以明文形态存在那么一瞬，签完一笔立刻清零。
每一个签名请求都走同一条路，没有任何快速通道可以跳过检查。一笔交易要被签出来，得依次走完七个步骤：委托检查、模拟、安全检查、安全 Agent 审查、策略评估、Passkey 审批，最后才轮到 SSM 真正签名。前一步过了，后面的步骤一个都不能跳。
还有一个底层细节：系统里所有随机字节，包括私钥生成、AES-GCM nonce、认证令牌、WebAuthn 挑战值，全部来自 crypto/rand（操作系统的密码学安全随机源）。安全关键代码里不许出现任何 math/rand，测试和 CI 扫描会自动拦截违规。
交易安全：四道纵深防御
私钥隔离只解决了密钥安全，交易层面的风险仍然存在。被攻陷的 Agent 可以准备一笔看上去完全合规的交易意图，拿去骗用户，或者钻自动签名策略的空子。prompt injection 根本不需要拿到私钥，只要能说服系统走正常流程把一笔恶意交易签出去就够了。
所以真正的问题是：当替用户准备交易的 Agent 本身就可能被攻陷的时候，怎么才能把一笔恶意交易拦下来？
单层防御都有明显短板。只靠交易模拟？模拟会失败、RPC 会断，没见过的新攻击也不在已知套路里。只靠 LLM 安全审查？前面说过，同一套 prompt injection 攻击 Agent 之后，还能接着攻击审查模块，因为审查本身也靠 LLM。只靠一刀切的硬限额？合法用户立刻被卡死，正常兑换限额 100 美元根本没法用。
这些方案单独用都不够。我们把它们叠在一起，组成四道纵深防御。每一道在设计时都假设前面的防线已经被攻破。
第一道，交易模拟。 交易拼好之后、签名之前，系统先模拟执行一遍：calldata 能不能正常解码，执行会不会回滚，字段格式有没有异常。模拟能提前暴露一部分明显的问题，但它有盲区，新型攻击手法和 RPC 故障都会让模拟失灵。
第二道，对手方安全评估。 系统会对交易对手方做一系列固定检查：收款人和金额是否匹配，是否给了无限授权，是否发去了销毁地址，有没有意料之外的委托调用。地址风险筛查通过 BlockSec 的 x402 合规服务（x402.blocksec.ai）自动完成，Agent 通过 x402 微支付实时查询地址标签和风险评分，无需 API key 或订阅。前两道加起来能抓住大量常见问题，但我们清楚它们都可能被绕过，所以把它们的定位压得很低：只负责发现风险、帮用户读懂风险，放不放行不由它们说了算。
第三道，硬策略执行。 这道完全由代码执行，规则写死在 Go 里，LLM 不参与，Agent 没有权限修改。单笔上限、每日预算、收款地址白名单、自动签名阈值，一笔 5000 美元的转账撞上 100 美元的单笔上限，当场就拒；想改策略本身，得先过 Passkey。策略更改为什么要 Passkey？因为 Agent 要是能改策略，一次注入就能先把限额放宽、再清空钱包。自动签名为什么默认关掉？因为新钱包默认每一笔都要人点头，直到用户自己明确打开、设好额度。
也就是说，即使前面所有检测层都被绕过、Agent 被完全攻陷并签署了恶意交易，实际损失也被策略锁死在可控范围内。比如用户把每日自动签名阈值设为 500 美元，那么最坏情况下的损失上限就是 500 美元，而不是整个钱包。策略层把”被攻破”从灾难性事件降级为有限损失。
第四道，用户确认（Passkey）。 一旦策略要求人工审批，系统就要求用户做一次 WebAuthn 验证，指纹或者面容，这是纯软件再怎么折腾也过不去的最后一道门。
四道防御合起来，关键在互不信任。后面的每一道都假设前面的防御已经失守。模拟和评估做得再完美，策略照样卡住限额；策略被配错了，Passkey 还要再验一次用户的指纹。每一道都独立工作，不依赖前面的判断。
还有一个容易被忽略的细节，叫判定重用。DeFi 攻击中一种常见手法，就是把一个旧的安全判定，套到一笔已经被改过的交易上。Web3 Companion 的做法是给每个写操作单独建一个交易意图，状态流转全程可审计，安全审查只对它审过的那一个意图生效。Agent 只要重建了交易，哪怕只改了金额或者收款人，那就算一个全新的意图，得从头再过一遍所有检查。
总结一下，四道防御对应三道独立的信任边界（私钥 / 策略 / Passkey），任何一道被攻破，剩余的边界仍然能独立拦截：
| 如果这层被攻破 | 还能拦住的 |
|---|---|
| Agent（prompt injection、RCE） | 没有密钥就签不了，撞上策略就超不了限，过不了 Passkey 就批不了 |
| 安全审查（判定被操纵） | 策略照样卡住限额，该人工审批的照样要 Passkey |
| 策略（用户配置出错） | 凡是要人工的操作，照样得刷一次生物识别 |
| 除 Passkey 之外的一切 | 凭据和硬件绑死，攻击者得让用户本人到场刷脸按指纹 |
Security by Design：开源背后的理念
BlockSec 从成立第一天起就在做链上安全。我们保护过数十亿美元的链上资产，也亲眼看过无数次同一个教训：安全如果不是 by design 写进架构里的，出事的时候再补就来不及了。
AI Agent 正在成为链上交易的新入口。这个赛道跑得很快，但安全标准几乎是空白。大多数团队还在比谁的 Agent 更能干，很少有人认真考虑过：如果这个 Agent 被攻陷了，架构能不能兜住？
Web3 Companion 是 BlockSec 把多年链上安全经验融入 Agentic Wallet 架构的一次完整实践，代码以 MIT 协议完整开源（目前标注为 research preview）。这个行业现在就需要一个安全设计的起点。威胁模型怎么建，私钥怎么隔离，交易防御做到什么程度，这些问题不应该每个团队从零摸索。这套设计全部开放，希望它能成为社区构建安全 Agentic Wallet 的基础。