AI Agent 钱包允许软件通过签名者请求金融操作。实际的控制点在于谁持有签名权限、哪些操作是被允许的，以及在整个任务中如何限制支出。
因此，给软件提供钱包不仅仅是选择存储密钥的位置。您需要规则来管理它可以授权哪些操作、支出如何累计以及谁可以阻止它。模型的推理和钱包的强制执行是该系统的独立组成部分。
我会通过尝试通过普通工具调用来超出其权限来评估一个 Agent 钱包。一个宣称“Agent 理解预算”的产品尚未证明预算得到了强制执行。
映射所有者、操作者和签名者
人类或组织为钱包提供资金并制定政策。Agent 在任务中选择操作。签名组件将允许的操作转换为有效的授权或交易。一个产品可以结合其中一些角色，但权限仍应保持清晰。
签名者可能运行在本地进程、托管钱包服务或专门的隔离基础设施中。智能账户可以通过其合约强制执行额外规则。这些安排具有不同的托管和恢复假设。
Coinbase 的 Agentic Wallets 产品描述了私钥隔离和支出护栏。这是一个具体的待审查产品架构，而不是与 AI 模型连接的每个钱包的通用属性。Coinbase Agentic Wallets。
询问谁可以更改政策，以及如果 Agent 的访问凭证被盗会发生什么。保护签名密钥的系统仍可能通过已授权的 API 凭证接受恶意购买指令。密钥隔离和操作授权解决的是不同的问题。
将政策置于 Agent 和资金之间
请求在钱包签名之前应通过支出控制。
授权受限购买并记录结果。
拒绝或在签名前上报人工审批。
使权限具有针对性
一个有用的支出权限包含支出方、资产和允许额度，并设有时间边界。应用程序可能还需要商户或合约限制，以及对支出方可以执行的操作的控制。
Coinbase 文档中的支出权限接口包括允许额度、循环周期和有效窗口。具体的执行取决于相关的账户和合约实现。支出权限 API。
权限应与任务相匹配。购买数据响应所需的权限低于交易任意代币。向已知商户付款所需的权限低于允许来自工具生成交易的每一个合约调用。
连接钱包、批准代币支出和委托账户操作也是不同的步骤。用户可以在不打算授权提款的情况下检查余额。现有的代币批准在 Agent 集成更改后仍可能有效。钱包权限与批准。
交易上限未包含在重试循环中
考虑一个假设的智能体，其最大购买限额为 $1，任务预算为 $5。它请求一个 $0.50 的 API 响应，收到一个模糊的超时错误并尝试再次请求。每次购买都符合交易上限。但重复请求仍可能消耗掉全部任务预算。
预算检查需要考虑累计支出和待处理授权。如果多个调用并发运行，它们都可能在任何结算完成之前看到相同的未支出余额。在一次原子操作中检查并预留预算，可以防止并发调用批准相同的资金。
下面的策略演示将已支出资金和预留资金视为不可用于新请求。它使用了虚构的价格和简化的本地状态机。真实的实现需要持久化存储和能够承受进程重启的强制执行机制。
相同的会计处理也应遵循已取消或失败的调用。当授权无法再结算时释放预留，而不是假设超时返回了资金。未解决的付款仍是一个需要对账的财务状态。
保持任务预算与钱包余额分离
钱包可以持有比特定智能体允许支出的更多资金。这使得多个任务可以共享资金，而无需授予每个任务全部余额。它还防止“可用余额”成为默认的授权边界。
在工作流需要的地方设置任务预算、累计周期限制和交易上限。它们的目的不同：一个限制单次错误，另一个限制循环，另一个限制总运营支出。
MPP 的智能体支出指南将预算管理置于支付客户端周围。这使得配置的策略成为一个需要审查的组件，而不是关于模型将做出何种决定的假设。管理智能体支出。
对于生产系统，应记录预算所有者和每个限制的来源。工具响应可以提议价格，但它不应该仅仅因为资源是“必需”的就能够重写最大限额。
接收方也需要单独核查
允许的资产和金额并不代表付款会发送给正确的卖家。交易可能包含正确的货币，但仍可能指向非预期的地址或合约。
在支付机制支持的情况下，将购买行为与商家和资源绑定。检查目的地的变更，而不是接受来自任意内容的地址。Agent 的研究材料和服务支付挑战是用于验证的输入，而不是拥有钱包权限的指令。
对于合约交互，检查正在签署的完整操作。一个看似微小的代币转账可能包含在具有额外权限的更广泛调用中。仅检查可见金额的策略可能会遗漏其余部分。
x402 指南解释了支付报价。Agent 身份文章解释了为什么识别卖家仍不能证明每个报价的质量或安全性。
撤销存在时机问题
阻止 Agent 发布新签名并不一定能使已生成的签名失效。已经广播的交易在所有者按下停止按钮后仍可能完成结算。界面应解释撤销影响哪个阶段。
链上授权或委托权限需要自己的撤销流程。托管服务的账户块可以在另一个层级运行。审查停止操作是移除正在进行的权限、使新会话过期，还是仅断开前端连接。
这种差异在事故中变得明显。操作员需要一份待处理授权、待处理交易和活动批准的列表。如果没有它，“Agent 已停止”可能会被误认为是“所有财务风险已停止”。
恢复演练应包括在激活紧急开关后的延迟结算。结果比正常支付的演示能提供更多关于权限边界的信息。
记录购买行为，而非密钥
有用的收据记录任务、商家、报价金额、授权最大值和结果。它应让所有者区分已结算的付款和已到达的资源。日志不需要签名密钥即可提供这些证据。
对于变量的使用，记录预留金额和最终费用。一个任务可以在选择低价值资源的同时仍保持在上限之内；支出日志为所有者提供了一种将结果与成本进行对比的方法。
同时记录被拒绝的操作。重复被拦截的购买行为可能会揭示一个损坏的循环，或者是一个预算不符合其要求的任务。静默重试被拒绝的操作会将可理解的限制变成难以调试的故障。
智能体在 2026 年的测试中提高了自身的限制
Cornell Tech 和耶鲁大学的研究人员于 2026 年 10 月 30 日在 arXiv 上发布了一篇论文（I-HITL: Inalienable Human-in-the-Loop），测试了上述描述的弱点：谁可以更改策略。这是一个受控实验，并非针对 Circle 客户的攻击。研究人员在 Base 主网上为 Circle 智能体钱包注入了 10 USDC，并设置了 0.01 USDC 的每日上限，即一美分。该智能体拥有电子邮件、网络和钱包工具，收件箱是接收 Circle 发送的一次性验证码（OTP）电子邮件的入口，用于批准更改上限。十个前沿模型在每个场景下运行了 20 次试验，且任务从未提及支出政策。
在没有攻击者的情况下，智能体必须支付三张 0.01 USDC 的发票，这需要更高的每日上限。10 个模型中有 9 个通过读取收件箱中的 OTP 至少提高了一次上限。在第二个场景中，智能体仅被要求总结收件箱，而攻击者的电子邮件冒充了所有者。10 个模型中有 5 个提高了上限并至少支付了一次给攻击者（CoinDesk, 2026 年 11 月 1 日）。
请注意比例。作者表示，这个问题并非仅限于 Circle 或电子邮件，并预计它会延续到具有类似审批设计的其他钱包。CoinDesk 报告称，这尚未在其他产品上表现出来。Circle 告诉 CoinDesk，其文档告知用户切勿给予 AI 智能体用于验证的电子邮件账户无限制的访问权限，并要求用户自行输入一次性代码。
实际结论是，只有当智能体无法触达承载审批信息的渠道时，人类的审批才有效。如果智能体能够读取收件箱、浏览器会话或确认其限额变更的存储凭证，那么该限额就只是一个建议。将用于限额变更的审批渠道（电子邮件、身份验证器应用、账户恢复）排除在智能体的工具之外，然后进行测试：给智能体提供它实际拥有的工具，并尝试让它提高自身的上限。仅移除电子邮件访问权限可能不足，因为作者指出，拥有终端或浏览器的智能体可能会找到存储的凭证。他们自己的提议是使用独立的受信任设备，这是一个名为 Countersign 的手机应用原型。这是一个研究原型，我们尚未对其进行测试。
我会在资助前进行的测试
在测试环境中给智能体一个小的假设预算。尝试进行多次同时购买，重复一个超时请求并更改付款目的地。然后，在仍有一笔付款处于待处理状态时撤销其权限。
钱包应当让所有结果对所有者清晰可见。已允许、已预留、已支出、已拒绝和未解决，不应全部看起来像是一个不断变化的余额。
一旦这些控制措施生效，根据资源的计费模型选择支付协议。x402 与 MPP 的对比 对比了该层。无论智能体使用哪种支持的路径，钱包策略都需要保持有效。
两个智能体可以在不共享预算的情况下共享资金
想象一个钱包为两个研究智能体提供资金。每个任务有 5 美元的津贴，但操作员仅允许 8 美元的每日总支出。如果第一个任务支出了 5 美元，根据该共享规则，第二个任务最多只能使用剩余的 3 美元。其未使用的 5 美元任务津贴并不代表可以绕过每日上限的许可。
签名者需要在批准并发购买之前，针对每一个适用的限额预留资金。否则，两个单独有效的任务请求可能会超出共享预算。这是一个假设的策略设计，并非声称每个钱包都实现了嵌套预算。