为什么 AI 代理钱包 必须是非托管的：Lazarus 攻击让这一点显而易见

Source: Dev.to

要为您提供完整的中文翻译，我需要您粘贴或提供文章的正文内容（除代码块和 URL 之外的文字）。请把您想要翻译的文本贴在这里，我会在保持原有 Markdown 格式和技术术语不变的前提下，将其翻译成简体中文。

Bitrefill 发生了什么

Gartner 确认，Lazarus Group 本月利用被泄露的 API 密钥以及通过其面向客户的 AI 助手进行的提示注入，入侵了 Bitrefill 的热钱包。该注入提升了对支付后端的权限。热钱包——集中管理、单一密钥——在几分钟内被清空。

• 没有区块链漏洞。
• 没有智能合约错误。
• 他们只找到了一把集中式密钥，这就是全部关键。

如果你在使用托管钱包运行代理，那么你面临的攻击面完全相同——甚至可以说更糟，因为你的代理会持续读取不可信的内容。

三种托管模型对代理的破坏方式

1. 提示注入 → 支付执行
   代理整天处理不可信内容（网页、API 响应、用户输入、工具输出）。能够向代理上下文注入文本的攻击者可以尝试触发提款、批准交易或轮换凭证。

   • 托管钱包：该指令会到达能够执行它的后端，暴露整个钱包余额。
   • 非托管且使用链上消费策略：相同的注入会命中一个合约，该合约强制执行限制（例如，“每笔交易最多 0.01 ETH，只能发送到白名单地址，且每日不超过 0.1 ETH”）。请求被拒绝。

2. 基础设施所有者是最薄弱环节
   托管意味着别人持有你的密钥。那个人就是目标——API 密钥泄漏、内部威胁、钓鱼、供应链妥协——所有这些都会在你没有任何失误的情况下暴露代理的资金。

   • 非托管：你的代理自行持有密钥。基础设施提供商被攻破也不会影响你的钱包。

3. 二进制授权对代理来说过于粗糙
   大多数托管设置只有一个开关：API 密钥可以消费，或者不能。没有每个代理的限制，没有目的地白名单，没有时间锁定的提款。
   ERC‑6551 Token‑Bound Accounts——agent‑wallet‑sdk 所运行的环境——在链上放置消费控制。每个代理钱包都有一个 SpendingPolicy，精确定义它可以做什么。该策略是不可变的、可审计的，且不能通过重新部署来覆盖。

代码示例

import { AgentWallet, SpendingPolicy } from '@ai-agent-economy/agent-wallet-sdk';
import { parseEther } from 'ethers';

// Spin up an agent wallet with hard guardrails
const wallet = await AgentWallet.create({
  policy: new SpendingPolicy({
    maxPerTx: parseEther('0.01'),   // 0.01 ETH max per transaction
    maxPerDay: parseEther('0.1'),   // 0.1 ETH daily cap
    allowedDestinations: [
      '0xYourAPIProvider',
      '0xYourSubAgentPool',
    ],
  }),
});

// Agent pays for an inference call
await wallet.pay({
  to: '0xYourAPIProvider',
  amount: parseEther('0.005'),
  memo: 'inference_call_id_abc123',
});

没有中心化服务器。策略检查在合约中进行。注入的提示、恶意工具输出或受损的子代理都无关紧要——合约会拒绝任何超出策略范围的操作。

没有人谈论的 ERC‑6551 属性

TBA 钱包由 NFT 拥有。转移 NFT，所有代理权限会立即撤销——无需 API‑key 轮换、无需后端调用、无需 incident‑response ticket。

Bitrefill 泄露部分成功是因为撤销被泄露的凭证需要手动操作。发现到撤销之间的时间就是造成损害的时段。使用 TBA 架构，撤销可以自动化：异常触发 NFT 转移到 null address，在人类甚至被呼叫之前就锁定钱包。

值得讨论的反对意见

“非托管很复杂。使用良好安全实践的托管则没问题。”

句子后半部分承担了大量的论点。

Bitrefill 并没有糟糕的安全实践；他们采用的是常规做法——API 密钥管理、访问控制、日志记录。Lazarus 找到了 AI 助手并利用它，因为该助手拥有支付权限。

这就是新的攻击向量。大多数托管安全模型是在能够处理不可信文本的代理具备支付能力之前建立的。它们并未针对这种威胁设计。

链上消费限额配合目的地白名单是唯一不需要完美操作安全（OPSEC）的架构控制。其他所有措施都是深度防御——好且必要，但并不足够。

结论

如果你的代理涉及真实金钱，架构决策就不再是权衡取舍：非托管且具备链上支出限额、白名单目的地和最小余额（仅足够完成接下来的几次操作）。

我们构建了 agent‑wallet‑sdk，因为我们自己的代理需要它，而市面上并不存在。它使用 TypeScript 编写，采用 MIT 许可证，并基于 ERC‑6551 构建。

Repo: github.com/AI-Agent-Economy/agent-wallet-sdk

正在构建代理支付基础设施并想交流经验？我在 X 上的账号是 @AgentEconoemy。

Tags: #ai #blockchain #security #typescript