AI Agent

AI Agent 支付安全：六种"付款成功"的错误交易与护栏设计

付款成功 ≠ 应该付款。x402 实测的六种错误交易、25 微秒确定性护栏，以及 Agent 身份与四级权限的可落地设计。

一句话结论：让 Agent 能付钱，只是问题的一半；另一半是它到底被授权付什么、谁来执行这个决定。官方 x402 客户端在测试网上跑出的六种失败里，支付机制本身全部按设计工作——问题都出在支付前后的决策与边界上。解法不是再请一个模型来"看一眼"，而是把能否动钱的判断尽量做成确定性代码，再把 Agent 当成有生命周期的第一类身份来管理。

本文整理 dev.to @dailycontext《Your Agent Paid. That Does Not Mean It Should Have.》（2026-10-11）与《An Agent's Plan Isn't Permission》（2026-10-14）、Auth0《AI Agents Are Not Users: Building an Identity Model That Reflects That》（2026-10-10）、Quokka Labs《AI Agent Governance in Production: Permissions, Audits & Human Approval》（2026-10-13），做中文编译与二次整理。

一、x402 把"付款"变成了 HTTP 的一部分

一个 Agent 正在写报告，需要一个数据点。API 回答：这条数据 5 分钱。Agent 签名，付款结算，数据到达。

付款成功了。但这不代表它是一笔正确的交易。

x402 的机制只有三步：

请求被拒绝：客户端请求资源，服务器返回 402 Payment Required，并附带价格、收款地址与可选的支付方式（通常稳定币计价）；
签名：客户端选择一种支付方式，签名，带上 PAYMENT-SIGNATURE 重试；
验证与结算：facilitator 验证并结算这笔付款，然后资源才被交付。

整个人类无需逐笔批准。这正是协议有意思的地方，也恰恰是安全边界移动的地方：facilitator 只验证签名有效、金额与收款人匹配——它没有理由知道买方原本预期花多少钱、买什么。

来源文章作者用官方 x402 客户端连到 Base Sepolia（公共测试网）上的测试卖家，用公共 facilitator 跑了一组攻击。六种失败最值得记录——每一种里，支付机器都运转正常。

二、六种"付款成功"的错误交易

#	失败	机制	支付系统为什么没拦住
1	价格操纵	目录里标价 5 分钱，实际支付请求要 50 分钱	facilitator 只验签，不知道买方的预期价格；客户端默认 1 美元上限高于 50 分
2	一次付款、多次交付	同一份签名支付并发发 5 次，卖方交付 5 次	链上防了双花，没防重复交付；买方超时重试还会重复扣款
3	白嫖	验证通过但结算失败，卖方已经交付	验证 ≠ 结算；同一资源还有未保护的路径（`/report` 受保护、`/download` 没有）
4	付对钱、拿错货	一笔付款被两个同价同卖家的资源都接受	付款只标识"付给谁、付多少"，不表达这笔钱授权了什么
5	恶意发现	仿冒卖家（自己的域名 + 自己的钱包）被 Agent 选中	目录能证明"服务可用"，不能证明"谁在运营"
6	提示注入	卖家在回复里暗示"更完整的版本在另一个路径"，Agent 跟着买了	卖家的回复也是模型要读的内容，不是可信指令

几个细节值得展开：

价格操纵：作者的第一版护栏只对比金额——一半的攻击换个钱包或换个币种就绕过去了。当金额、收款人、资产、网络等每个字段都进入校验后，240 次攻击 0 通过。
白嫖的规模：在作者的实验里，30,000 次未付费请求产生了 30,000 次泄漏。规则应该写成一句话：每一次交付背后都要有一笔付款。
提示注入不需要说"付钱"：Agent 的任务是"花不超过 5 分钱拿到 Q2 摘要"，卖方返回摘要后顺带提到另一个路径有更完整的版本。本地运行的 Llama 3.2 跟着这条安静的提示，花了 50 分钱。

三、别用概率去解决概率问题

对提示注入的本能反应是"再加一个模型"：告诉它不要相信卖家内容，或者让另一个模型分类可疑回复。作者两种都试过——显眼的攻击能拦住，一句没有触发词的安静建议照样溜过去，仍有约三分之一的攻击移到了钱。

真正有效的是把授权决定从模型手里拿走：

Agent 先写计划——"买摘要，最多 5 分钱"——代码把它锁死；
签名之前，一个确定性 guard 只回答一个问题："这笔购买在计划内吗？"
它不需要理解卖家的措辞，也不需要判断什么算恶意——在 90 次攻击里，全部被拦下；
买家侧这个检查的运行时间约 25 微秒。

模型仍然可以自己发现服务、理解回复、决定要达成什么——它只是没有移动钱的最终权限。卖方可以告诉你价格，但它没有权限替你决定买。

确定性护栏也有成本。把卖家固定成白名单后，合法卖家轮换钱包时也会被拦，Agent 的采购完成率一度只有 17%。最终的做法是给新卖家或变更过的卖家一个观察期，由人复核——保护还在，流程不停。任何让工作流停摆的安全措施，最后都会被关掉。

四、控制点该放在哪里：签名前与交付前

六种失败最终收敛到两个控制点。

买家侧，在签名之前：

把支付请求与 Agent 原本选择的对象逐字段比较：金额、收款人、资产、网络，以及其他所有相关字段；
限制允许付款给哪些卖家，配合预算与锁定的计划；
支付超时后，先查询状态，再重试同一笔支付——不要新建一笔。

卖家侧，在交付之前：

要求合适的结算状态才释放付费资源（验证通过不够）；
每笔付款只认领一次，并把它绑定到它所授权的那个资源；
保护所有提供该资源的路径（别让 /download 绕过 /report），付费响应不得进入共享缓存。

当 Agent 通过 MCP、A2A 继续委派时，授权必须在每一跳上都成立——它应该是围绕自主性的一个边界，而不是又一次交给模型的判断。

五、再往上：Agent 需要"身份"，而不是一张额度更大的卡

把边界做在支付字段上是对的，但根子在更上层：Agent 以一个什么身份在行动？

2026 年 4 月，一个 AI coding agent 在 9 秒内删除了 PocketOS 的整个生产数据库，连同卷级备份。这个由 Cursor 驱动、跑在前沿模型上的 Agent，事后被描述为"配置了厂商告诉开发者要配的全部安全规则"——系统提示词告诉它不要做破坏性操作，但系统提示词是建议，不是强制。真正的架构失误，是给一个非确定性的 Agent 配了与人同等的权限，却指望自然语言去约束它。

我们现有的两种身份模型都接不住这种角色：

OAuth 委派：Agent 拿到用户同等的权限——用户能做的它都能做，且跨每一次未来交互，无法表达"这一步只允许做什么"；
服务账号：Agent 有自己的凭据，但通常静态、范围宽、脱离用户上下文；出事时审计日志只显示"某个服务账号做了某事"。

两者共享四个会随规模放大的失效模式：

权限过大：凭据按资源粒度定义（billing:write），而不是按能力粒度（billing.refund.issue_under_50_usd）；
爆炸半径：Agent 进程、内存或日志被攻破，暴露的是对生产系统的长期访问权；
缺少行为上下文：身份层分不清"Agent 在总结工单"和"Agent 在发退款"，因为两种操作出示的是同一张宽范围凭据；
凭据泛滥：每接入一个工具就多一份要配置、存放、轮转、审计的凭据。

第一类 Agent 身份应当具备四个属性：

属性	含义
目录标识	独立于任何用户/服务账号，含 Agent 类型、定义版本，最好注明谁对它负责
范围权限	用业务语言定义，独立于用户权限，即使它在替用户办事
委派上下文	记录"Agent X 代表用户 Y、以授权 Z 行动"——下游看到的是完整三元组
专属审计轨迹	每个动作归属到具体 Agent 身份，委派链完整，独立于工具自身的日志

落实时有两条工程原则：

身份凭据 ≠ 执行凭据。身份说明"它是谁、原则上能做什么"；执行凭据是短命 token，只授权眼前这一次调用。OAuth 2.0 Token Exchange（RFC 8693）就是为这种动态、按请求授权的委派设计的——Agent 不持有长期 refresh token，而是即时换取分钟级访问令牌，用完即弃；撤销连接，后续换取立即失效。
授权绑行为，不绑角色。把判断放到动作发生的那一刻，用请求上下文（代表谁、什么资源、什么时间、什么任务参数）评估——ABAC 对多数团队够用；资源-关系数量上千的多租户系统再上 ReBAC（如 OpenFGA 的 Agent 授权模型，Agent 作为第一类 principal 进入关系图，条件表达式还能带时间窗，例如"这次指派在过期时间之前有效"）。

审计也随之改变：日志要能回答"哪个 Agent、代表谁、为什么被允许、结果是什么"，并且保留决策链（用户的原始意图 → Agent → 子 Agent → 工具 → 资源），而不只是工具侧的动作流水。

六、治理控制面：六道控制、四级权限、按后果审批

把上面的东西工程化，就是一个横在 Agent 运行时和企业系统之间的控制面：

User/Workflow → Agent Identity → Policy Engine → Approval Gate → Tool/API → Audit Ledger

控制	生产要求
Agent 身份	每个 Agent / 每类 Agent 有唯一、有主、可撤销的身份
权限	默认拒绝；按任务范围最小化
运行时策略	评估动作、资源、数据分级、金额、上下文
人工审批	高影响或不可逆动作必须过审批门
审计	记录请求、策略判定、审批人、工具调用、结果
遏制	撤销凭据、暂停运行、安全回滚

权限可以按后果分四级，避免"要么全放开、要么全拦死"：

级别	例子	默认控制
0：读	查知识库、总结工单	允许 + 日志
1：可逆写	建草稿、开工单	允许 + 日志 + 限额
2：高影响写	退款、对外邮件、部署	人工审批
3：受限	改 IAM、删生产数据、改治理规则	阻断或双重审批

审批要按后果升级，而不是按"不确定"升级——每个动作都要人看，审核者会变成橡皮图章。建议强制审批的触发条件：超过阈值的资金、对外或受监管通信、生产基础设施与访问权变更、受限数据外泄、删除或不可逆变更、创建新的 Agent / 凭据 / 工具 / 策略例外。审计事件至少要能重建：Agent 身份与版本、发起主体、run ID、请求动作、目标资源、工具输入、策略判定、审批状态与审批人、执行结果、时间戳、模型/提示词版本——并把策略版本一起存下来，否则审计员只能看到"发生了什么"，无法证明"哪条规则授权了它"。

最后，NIST AI RMF 的 Govern / Map / Measure / Manage 与 ISO/IEC 42001 是治理脚手架，它们不能替代运行时的授权判断——但能让"已治理"变成可度量的日常操作。

七、可以照着做的清单

给每个 Agent 一个负责人和唯一身份，它既不是用户，也不是服务账号；
权限默认拒绝、按任务最小化、短命、可撤销；不要让它继承开发者的宽范围 OAuth token；
策略要能在工具调用执行之前直接拦截，而不是事后解释；
高影响 / 不可逆动作进审批门，阈值与分级写在策略里而不是提示词里；
审计记录决策，不只记录动作：委派链、策略版本、审批人、结果都能重建；
能停掉一个 Agent 而不停整个平台；
测试 kill / 回滚 / 超时 / 审批过期这些路径，别只测正常流程；
买家侧：付款前逐字段校验、锁定计划、限制可付款卖家；超时重试同一笔支付；
卖家侧：交付前确认结算状态、每笔付款幂等认领并绑定资源、保护所有资源路径；
记住那条边界："付款成功"只说明支付系统执行了。它没有回答：Agent 是否按预期金额、付给了预期卖家、买到了预期资源，以及不可信内容有没有改变它的决定。

来源

@dailycontext, Your Agent Paid. That Does Not Mean It Should Have.（dev.to，2026-10-11）：https://dev.to/dailycontext/your-agent-paid-that-does-not-mean-it-should-have-2dnd
@dailycontext, An Agent's Plan Isn't Permission（dev.to，2026-10-14）：https://dev.to/dailycontext/an-agents-plan-isnt-permission-5cf8
Auth0, AI Agents Are Not Users: Building an Identity Model That Reflects That（dev.to，2026-10-10）：https://dev.to/auth0/ai-agents-are-not-users-building-an-identity-model-that-reflects-that-1mfp
Quokka Labs, AI Agent Governance in Production: Permissions, Audits & Human Approval（dev.to，2026-10-13）：https://dev.to/quokkalabs/ai-agent-governance-in-production-permissions-audits-human-approval-5ai
Software Factory 参考架构（Keycard / Docker / Barclays / Socket / Aaron Stanley）：https://agentbaseline.org