AI Agent 钱包安全吗？生产环境的 12 项支付安全检查清单

AI Agent 钱包可以安全进入生产环境，但前提不是“余额较少”或“设置了每日预算”，而是 Agent 无法取得任意签名能力，每笔付款都受身份、来源、收款方、网络、资产、金额、时效和重试规则共同约束。缺少其中任何关键边界，钱包就不应开放自动付款。

这份清单用于上线验收。它不会承诺消除提示词注入或模型错误，而是检查：即使 Agent、远程内容或某个工具给出恶意指令，支付系统能否限制损失、拒绝越权签名、避免重复付款，并留下足够证据供运营人员恢复。

AI Agent 钱包安全究竟指什么

“Agent 有一个钱包”可能代表完全不同的架构：私钥直接放在 Agent 进程里；Agent 可以调用云密钥管理服务的通用签名接口；或者 Agent 只能提交付款意图，由独立控制面和受限签名器决定是否执行。

只有最后一种架构能够建立清楚的安全边界。

OWASP 对过度代理权的说明把风险归因于功能过多、权限过大或自主程度过高，并建议缩小工具能力、下游权限以及高影响操作的自动执行范围。NIST 的软件与 AI Agent 身份和授权概念文件也把 Agent 独立身份、最小权限、委托、人工授权以及可验证审计列为关键问题。

因此，钱包安全不是密钥存放位置这一个问题，而是从模型提出请求到链上结算的整条授权链能否保持最小权限。

不可信输入与 Agent 运行时
  │ 只能提交付款意图；不能改策略、审批或签名
  ▼
策略与预算控制面 ──需要例外──> 人工审批
  │ 签发短时、单次、逐字段绑定的执行授权
  ▼
客户自持签名器
  │ 校验授权和准确付款载荷；不提供任意签名
  ▼
x402 资源服务与链上结算
  │
  └──> 独立记录付款状态、资源状态和审计证据

如何给这份检查清单评分

对每一项按证据评分：

• 0 分： 没有控制措施，或只能口头描述。
• 1 分： 已有部分控制，但依赖人工约定、单实例内存或无法重复验证的操作。
• 2 分： 控制措施默认生效，测试能够证明其拒绝失败，并且审计记录可以还原结果。

满分为 24 分。分数只用于发现差距，不是安全认证：

第 1、2、8、9、10、12 项是一票否决项。即使总分很高，只要 Agent 能取得私钥或通用签名能力、执行授权可以重放、重试会新建付款，或者紧急停用未经验证，就不应自动付款。

可以直接复制下面的表格填写证据与得分：

1. 管理凭据、Agent 凭据与签名凭据是否完全分离

日常运行的 Agent 只能持有属于自身、环境和有限操作范围的可撤销凭据。创建钱包绑定、修改策略、提高预算、批准例外和查看组织级数据，应使用另一套管理身份。钱包私钥或云密钥管理权限则只存在于签名环境。

通过证据： 使用 Agent 凭据调用策略修改、预算修改、审批和钱包管理接口时全部被拒绝；撤销该凭据后，已有进程也无法继续创建付款意图。

常见失败： 所有 Agent 共用一个组织 API Key；把管理密钥作为环境变量传给模型工具；签名伴随服务与 Agent 使用同一组云权限。

2. 钱包私钥是否离开 Agent 运行时，签名器是否拒绝任意签名

把密钥放入硬件安全模块或云密钥管理服务，只解决密钥材料不易导出的问题。如果 Agent 仍能调用 sign(anything)，它拥有的实际资金权限并没有缩小。

签名器应只接受付款专用载荷，并在签名前验证独立控制面签发的授权。测试密钥文件、正式环境密钥、伴随服务令牌和云权限都不能出现在提示词、工具结果、日志或错误响应中。

通过证据： 通用消息、任意交易、错误钱包和错误网络均被签名器拒绝；Agent 进程的文件与云身份权限无法读取或使用私钥。

常见失败： 生产环境仍使用明文私钥文件；伴随服务监听公网；只校验调用者令牌，不校验待签字段。

3. 每个 Agent 是否具有最小权限和独立归属

不同任务、环境和风险等级不应共用一个付款身份。研究 Agent、采购 Agent 和生产运维 Agent 应分别绑定需要的工具、钱包、策略和查询范围。沙盒凭据不得访问正式环境，正式钱包也不应参与开发测试。

这项隔离让团队能够单独停用受影响的 Agent，并从审计记录判断“谁代表谁执行了什么”。MCP 官方工具规范也要求客户端把不可信服务器提供的工具注释视为不可信信息；工具可见不应自动转化为付款权限。

通过证据： 任一 Agent 都无法查询其它 Agent 的付款、调用未分配能力或跨环境使用凭据；权限清单有负责人和复核日期。

4. 来源与收款方是否默认拒绝，并使用准确允许列表

只允许 https://example.com 还不够。系统需要规范化并绑定准确来源，拒绝相似域名、非 HTTPS 降级、意外端口、重定向到其它来源以及用户信息混淆等情况。付款要求中的收款地址也必须独立核对，不能因为来源在允许列表中就接受任意地址。

来源和收款方应分别形成四种结果：都已知时才可能自动付款；任一未知时进入审批或直接拒绝；两者都未知时不应因为金额小而自动通过。

通过证据： 同形域名、开放重定向、来源不变但收款方变化，以及收款方不变但来源变化的测试都会失败或进入审批。

5. 网络、资产和准确请求是否绑定到同一个付款意图

地址相同不代表网络相同，同名代币也不代表合约相同。系统必须校验规范网络标识、资产合约或铸币地址、资产位数和收款地址。对于 POST、PUT、PATCH 或 DELETE，还要绑定 HTTP 方法、完整网址摘要、请求体摘要和内容类型。

如果预览或审批后出现不同网络、资产、收款方、方法、请求体，或更高金额，它就是另一笔购买。旧审批不能继续使用。

通过证据： 在签名前分别替换每一个字段，系统都拒绝执行；运营界面能显示审核所需字段，但不泄露敏感请求正文。

6. 单笔上限与多级预算是否同时存在，并能抵抗并发

至少需要三层金额控制：不可由普通审批突破的单笔硬上限、每个 Agent 的周期预算，以及组织级周期预算。预算必须在签名前原子预留或提交，不能等链上确认后才扣减。

否则，并发的十个请求可能同时读到相同余额，并分别通过判断。金额还必须使用整数最小单位；不要用浮点数计算稳定币限额，也不要假设所有代币都有相同位数。

通过证据： 并发请求总额超过剩余预算时，只有允许范围内的请求成功；进程重启和数据库重试不会重复预留或释放额度。

预算为何不能替代其它控制，可阅读只设预算，不足以约束 AI 智能体支付。

7. 自动付款阈值和人工审批是否表达不同风险

自动付款阈值应低于或等于单笔硬上限。已知来源、已知收款方且其它字段全部符合策略的小额请求，可以在阈值内自动执行；未知对象或更高金额则等待人工审批；超过硬上限、预算不足或风险门禁失败应直接拒绝，审批不能覆盖。

审批必须针对一个不可变快照，而不是让管理员授予“以后都可以”的模糊权限。高金额可以要求多名不同管理员批准。操作人员需要看到购买内容、来源、收款方、网络、资产、最大金额和过期时间。

通过证据： 修改已审批快照的任一关键字段都会使执行失败；同一管理员不能重复计票；审批过期或被拒绝后不能恢复。

具体恢复方法见为什么支付在等待审批，应该如何恢复？。

8. 执行授权是否短时、单次且逐字段绑定

人工或策略决定不应直接变成长期签名权限。控制面应签发短时执行授权，把组织、环境、Agent、Intent、钱包、网络、资产、收款方、最大金额、随机数和有效期绑定在一起。签名器逐字段校验后，只允许使用一次。

一份授权被截获后，攻击者不应能延长有效期、替换收款人、提高金额、用于另一个钱包，或在第二台签名器上再次消费。多副本签名器需要共享、具备原子唯一约束的授权记录，而不是各自维护内存集合。

通过证据： 重放相同授权、并发提交、过期授权、未知签发密钥和字段不一致全部默认拒绝；密钥发现或授权记录存储不可用时不降级为直接签名。

9. 同一业务购买是否始终复用一个幂等身份

每次重试都生成新标识，会把一次购买变成多次合法付款。幂等键应在业务任务层生成，和原 Intent 一起持久保存，并跨网络超时、进程重启、队列重投及人工审批恢复保持不变。

x402 的 payment-identifier 扩展允许服务端按付款标识去重并返回缓存结果，但它是可选扩展，而且缓存有效期由服务端配置。买方仍需在自己的控制面保证 Intent、预算和签名授权不因重试而复制，不能把卖方去重当作唯一防线。

通过证据： 对同一个幂等键并发发送相同请求时只产生一个 Intent 和一笔预算占用；同一个键配不同请求内容时被拒绝，而不是复用错误结果。

10. 结算状态未知时是否停止付款并对账原 Intent

签名后的超时不等于付款失败。请求可能已经到达资源服务器或结算服务，只是响应在返回途中丢失。此时应进入明确的 settlement_unknown 状态，保留已经提交的预算，停止该业务购买的自动重付，并查询原 Intent、授权和链上证据。

x402 的 HTTP 付款流程会把验证、结算和资源响应连接到一次 HTTP 交换中，但具体付款方案的链上时点可能不同。安全恢复不能只看客户端是否收到 2xx 响应。

通过证据： 在“签名完成后、收到响应前”强制断网，系统不会创建新 Intent 或释放预算；恢复任务最终把原付款归入已结算、已回滚、已过期或继续未知。

完整操作见结算状态未知时应该怎么办？。

11. 审计、告警与敏感信息处理是否同时可用

一条有用的审计记录应该能回答：哪个 Agent 和任务发起请求，使用哪版策略，谁批准，哪些字段被绑定，由哪个签名器和授权执行，链上交易及资源交付分别是什么状态。

记录完整不等于复制秘密。日志不应包含私钥、完整 Agent Key、伴随服务令牌、完整执行授权、付款签名或敏感响应正文。使用稳定标识、字段摘要和关联编号即可重建决策链。

至少应对下列事件告警：连续策略拒绝、未知来源或收款方激增、审批异常、签名重放、预算快速消耗、结算长期未知、Webhook 验证失败以及签名器不可用。告警必须有负责人、处理时限和升级路径。

通过证据： 从一条告警可以关联到完整 Intent 和状态迁移；删除或修改审计记录需要单独权限；日志扫描确认没有上述秘密。

12. 紧急停用与恢复演练是否真正阻断新付款

团队需要能够分别撤销 Agent Key、停用 Agent、解除钱包绑定、停用签名器、撤销管理密钥和关闭正式环境付款。控制面故障、签名器失联或风险检查不可用时应保持拒绝，而不是临时绕过策略。

停用不一定能撤回已经提交到链上的付款，因此流程还要区分：阻止新意图、阻止新授权、处理已经签名但结果未知的付款，以及恢复仍未交付的业务资源。

通过证据： 演练从发现异常到阻断新签名的实际时间；停用后旧凭据、待审批 Intent 和未消费授权均不能继续执行；结果未知的旧付款仍能进入只读对账流程。

哪些威胁应该由哪一层控制

单一措施无法处理所有失败。下面的映射可用于检查控制是否过度集中在模型提示词或钱包余额上。

这也是为什么提示词防护不是付款安全边界。NIST 对 Agent 劫持的研究指出，攻击者可以把恶意指令藏在 Agent 读取的网页、文件或消息中。系统应该减少这类攻击成功的机会，但资金控制还必须假设恶意指令有时会到达工具层，并在模型之外独立拒绝越权操作。

上线前应该怎样做故障演练

不要只演示一笔成功付款。至少在沙盒中自动运行下面的拒绝与恢复测试：

1. 使用 Agent Key 修改自己的策略、预算和钱包绑定，确认全部被拒绝。
2. 分别替换来源、收款方、网络、资产、HTTP 方法、请求体和金额，确认旧审批或授权失效。
3. 对同一个幂等键发起并发请求，确认只创建一笔购买。
4. 在签名后、资源响应前中断连接，确认进入结算未知而不是新建付款。
5. 重启 Agent、控制面客户端和签名器，再恢复同一个 Intent，确认不会重复签名。
6. 重放已经消费的执行授权，确认所有签名器实例都拒绝。
7. 快速耗尽 Agent 预算并同时保留组织预算，确认 Agent 级限制独立生效。
8. 撤销 Agent Key、停用 Agent 和解除钱包绑定，测量新付款被阻断的时间。
9. 让签名器、风险检查或审计存储不可用，确认系统保持拒绝且产生告警。
10. 从告警、Intent、审批、授权、交易和资源状态重建一次完整事件，确认日志没有泄露秘密。

通过测试后，先在正式环境完成一笔金额很小、必须人工审批、结果容易核对且没有不可逆业务副作用的付款。只有当付款证据、资源结果、钱包余额、预算和审计记录全部一致时，才逐步提高自动付款阈值。

StableOps 如何对应这 12 项检查

StableOps Agent Payments 把运营者使用的管理 API Key、运行时使用的受限 Agent Key，以及客户环境中的签名凭据分开。不可变策略绑定来源、收款方、网络、资产与限额，两级预算限制 Agent 和组织总量；未知对象或超过自动阈值的付款进入审批。

执行时，StableOps 签发短时、单次且逐字段绑定的授权，由客户自行部署的签名器验证，并使用本地测试密钥、AWS KMS 或本地 Solana 密钥完成付款专用签名。私钥不交给 StableOps 或 Agent。审批后恢复原 Intent，签名后结果不确定则进入对账，不用新付款替代。

这不意味着接入某个产品就自动通过检查。团队仍要正确隔离部署环境、保管管理凭据、限制伴随服务、配置明确策略、接收告警，并实际完成停用与结算未知演练。可从 Agent Payments 快速开始建立沙盒流程，再按签名器部署检查核对密钥边界。

常见问题

AI Agent 钱包本身安全吗？

钱包软件或密钥托管方式只能覆盖一部分风险。决定生产安全性的是 Agent 能否取得任意签名能力，以及每笔付款是否经过独立、可验证、可撤销的授权链。直接把私钥交给 Agent 不安全。

只给钱包放很少的钱，可以代替这些控制吗？

不可以。小余额能够限制某一时刻的最大损失，但不能防止付错对象、重复付款、泄露密钥或错误交付业务资源。它可以作为额外的资金隔离措施，不能替代权限和恢复控制。

私钥放在 AWS KMS 中就足够安全吗？

不够。还要限制谁能调用 KMS、能够签署什么、授权有效多久、是否只能使用一次，以及请求字段变化时是否拒绝。对 Agent 开放通用 KMS 签名权限仍然属于过大权限。

每一笔 Agent 付款都需要人工审批吗？

不一定。已知来源和收款方、低于自动阈值且完全符合策略的付款可以自动执行。未知目标、更高金额或高影响操作应审批，硬限制或风险检查失败则应直接拒绝。

这些控制能彻底解决提示词注入吗？

不能。它们的目标是在提示词注入、模型错误或工具被入侵后，仍限制资金能力和可恢复范围。输入隔离、内容检测和工具安全仍需单独建设。

付款请求超时后可以用新幂等键重试吗？

签名前且能够证明没有生成授权时，可以按原业务状态恢复。签名后超时必须查询原 Intent，不能用新幂等键发起替代付款，否则可能重复扣款。

x402 是否保证收费服务值得信任？

不保证。x402 标准化付款要求、验证和结算流程，不替买方判断服务质量、来源信誉、收款方归属或业务结果。发现服务后仍应执行允许列表、审批和结果验证。

多久应该重新执行一次检查清单？

至少在首次上线、提高自动阈值、增加网络或资产、更换签名器、修改身份架构、发生安全事件以及重要依赖升级后重新执行。日常还应定期复核权限、允许列表、告警负责人和停用时效。

从零自动付款开始

初始自动付款阈值设为零并不是失败，而是一种校准方法。它让团队先验证审批、签名、结算和审计，再把一条经过证明的路径改为自动执行。

先完成 12 项书面评分和十个故障测试，再从一个 Agent、一个专用钱包、一个来源、一个收款方、一种资产和一条网络开始。安全地扩大自主程度，依靠的是扩大可验证的安全路径，而不是扩大模型持有的权限。

本文资料与协议链接核验于 2026 年 9 月 15 日。