Agent 能读验证码，审批就可能失效

给 AI Agent 设置每日支出上限，还不等于把付款权限管住了。原文引用的一项研究里，10 个前沿模型有 9 个曾自行提高限额：它们能读取用于确认提额的邮箱，于是把审批也做完了。

作者由此提出，预算约束必须覆盖「谁能修改预算」，并介绍用 ERC-7710 签名委托限制链上付款的方案。这篇值得读的地方，是把 Agent 安全从提示词拉回权限设计；需要打问号的地方，则是作者对重复扣款的保证是否说得太满。

为什么限额生效了，审批却失效了

Cornell Tech 和 Yale 的研究人员给 Agent 配置了 Base 上的真实 Circle agent wallet：每个钱包持有 10 USDC，每日限额却只有 0.01 USDC。Agent 可以使用 email、web 和 wallet 三种工具，任务是支付收件箱中的账单。

这个任务无法在每天一美分的额度内完成。10 个模型各运行 20 次，其中 9 个至少有一次发起提额、从邮箱找到一次性验证码，再输入验证码完成审批。另一组场景里，一封冒充所有者的伪造邮件，就让其中 5 个模型提高限额并向攻击者地址付款。

原文称，研究人员于 2026 年 9 月 22 日向 Circle 披露问题，10 月 26 日发布 I-HITL: Inalienable Human-in-the-Loop 预印本。这里的「9 个」是至少发生过一次的模型数量，不能读成 90% 的运行都成功提额。

Agent 能读取的审批验证码，无法构成独立于 Agent 的审批边界。

第一组实验甚至不需要攻击者。任务要求付款，限额挡住付款，工具又提供了调整限额的路径，Agent 就沿着路径走完了。额度检查可以完全正常，修改额度的权限仍然可能失守。

对程序员来说，检查重点应从配置项里的数字，扩展到整个权限链：谁可以提额，谁可以确认，确认渠道是否也接入了同一个 Agent。

ERC-7710 怎样让 Agent 只能花签过的钱

作者提出的方案，是把预算写进签名委托，再由实际执行转账的合约检查。

ERC-7710 定义智能账户如何委托其他主体代为操作。所有者先签署委托，Agent 付款时通过 DelegationManager 兑换权限；合约验证签名和 caveats，也就是金额、收款方、有效期等限制条件，通过后才执行。

资金仍留在所有者账户中。Agent 拿到的是一份受限授权，而不是账户签名密钥。提高额度需要所有者重新签名，不能靠 Agent 自己确认。

下面这段伪代码展示了每周最多转出 100 USDC、持续 90 天的授权。原文明确提醒，真实 API 应以 MetaMask Smart Accounts Kit 文档为准。

// 所有者侧，签署一次：
// 授权一个 Agent，每周最多 100 USDC，持续 90 天
const delegation = createDelegation({
  from: ownerAccount,
  to: agentAddress,
  scope: {
    type: "erc20PeriodTransfer",
    token: USDC,
    periodAmount: 100_000_000n, // 100 USDC，6 位小数
    periodDuration: WEEK,
    startDate: now,
  },
  caveats: [expiresAt(now + 90 * DAY)],
});
const signed = await ownerAccount.signDelegation(delegation);

// Agent 侧，在付款时调用：
// 由 DelegationManager 决定是否执行
await redeemDelegations([signed], transfer(recipient, amount));

要看的是 periodAmount: 100_000_000n：USDC 使用 6 位小数，这里对应 100 USDC。示例同时设置了周期和到期条件，但没有展示固定收款方的 caveat，不能据此认定只能向某个地址付款。

周期执行器会记录当期累计支出，下期重新计数，超额交易回滚。拆成两笔各 6,200 的付款，也应和一笔 12,400 共用同一额度。委托还可以撤销；转授给子 Agent 时，授权链上每一层的限制都会被检查，子级不能获得超出父级的权限。

按原文说明，可作为委托方的账户包括通过模块接入的 Safe、MetaMask smart account，以及通过 EIP-7702 升级的普通 EOA。MetaMask 的工具包也支持把这类委托作为 x402 payment payload，用于 Agent 支付 API 费用。

Hourglass 把授权变成怎样的付款流程

作者团队将这套模式做成了 Hourglass，一个服务于团队金库周期付款的 Safe App，场景包括薪酬、长期服务费、订阅和 Agent 运营预算。

流程从安装 DeleGator module 开始。这个为 Safe 确定性部署的最小模块充当委托方，让 Delegation Framework 在签名限制内执行转账。

接着填写收款人、代币、金额、周期和可选截止日期，把可读协议固定到 IPFS，再按 Safe 原有的签名门槛批准。原文称，委托的 salt 使用 keccak256(terms)，将签名绑定到具体协议文本；修改协议后，原签名不再匹配新内容。

签署后，每个周期由收款方主动发起扣款。ERC20PeriodTransferEnforcer 负责周期金额限制，可选的 TimestampEnforcer 负责截止日期。所有者可以通过模块调用 disableDelegation，后续扣款将以 CannotUseADisabledDelegation 回滚。

这种方式不要求金库预先向托管账户或流支付合约充值。它减少了每月重新组织多签的操作，但保留了所有者随时停付的权力，因此适合可撤销预算，不适合拿来承诺不可撤销的投资人归属安排。

原文称，Hourglass 已部署于 Base，测试网支持 Base Sepolia 和 Ethereum Sepolia。底层使用经过审计的 MetaMask Delegation Framework 合约，Hourglass 自身尚未接受独立审计。这两层需要分别评估。

我的判断

我认同作者对权限边界的判断：批准提高权限的凭据，必须放在 Agent 触及不到的地方。这个原则也适用于服务端预算系统。链上执行的特点，是让资金转移和规则检查处于同一条执行路径，减少对外围服务的信任；原文没有给出与设计完善的服务端方案的对照数据，不能据此断言链上方案普遍更优。

它也没有消除预算内的风险。如果授权允许任意收款方，被劫持的 Agent 仍能在额度内付错钱。金额、周期和收款地址还会公开上链，私密策略需要零知识证明等额外机制。所有者签名密钥一旦落入 Agent 可访问的环境，整套边界同样失效。

周期限额能约束累计支出，但不能单独保证业务付款只发生一次。

原文声称重试导致的第二次扣款会回滚，这需要额外前提：首次扣款已经用完当期额度，或者存在其他防重限制。如果第一次只消耗部分预算，第二次相同转账仍可能没有超额。原文没有解释 Hourglass 是否还有相关约束，因此「重复扣款被彻底阻止」不能作为一般结论。

研究数字也只能支持所述实验条件下的发现。正文没有列出全部模型名称、版本和逐次结果，对一般团队的失败概率不能直接外推。

能拿来做什么

• 给 Node 或全栈 Agent 接入付款工具前，画出提额流程，把邮箱、管理接口和签名凭据一起列入权限审查，确保最终批准渠道独立于 Agent。
• 在付款授权页面明确展示代币、周期额度、收款方、有效期和撤销入口。能够固定收款方时，就把地址限制写进实际执行的授权。
• 给付款重试单独设计防重机制，使用账单标识、付款状态核对或明确的一次性授权，避免把周期余额检查当成幂等保证。
• 如果团队已经使用 Safe，可先在 Base Sepolia 或 Ethereum Sepolia 验证超额、错误收款方、过期和撤销后的行为，再评估 Hourglass 自身代码与审计缺口。