SAFR之后，AI支付需要Payment Harness

2026 年 7 月 3 日，新加坡金融管理局 MAS 联合多家金融机构和金融科技公司，发布了《Safeguards for Agentic Finance at Runtime》，简称 SAFR。

SAFR 是一套面向金融 AI Agent 的运行时治理参考框架。它讨论的不是如何训练一个更准确的模型，而是另一个更接近真实金融系统的问题：

当 Agent 准备发起支付、提交订单、调拨资金或推进理赔时，金融机构如何在动作实际发生之前，确认它拥有相应权限，并且没有偏离用户授权和机构规则？

过去，金融机构对 AI 的治理主要集中在模型开发和部署阶段，例如数据是否合规、输出是否准确、模型是否存在偏见。但 Agent 获得工具调用能力后，风险不再停留在输出端。

一段错误分析可能被人工发现和修改。一笔已经完成的支付或交易，却可能立即产生真实且难以撤销的后果。

SAFR 的核心变化，是把治理从“模型上线之前”推进到“动作执行之前”。

在支付场景中，这个问题更加具体。

现有支付系统已经能够验证账户余额、交易签名、支付凭证和交易格式，也可以通过金额、地区和历史行为识别传统欺诈。但 Agent 发起支付时，系统还需要判断另一件事：

这笔交易是否仍然属于用户交给 Agent 的任务？

例如，用户要求 Agent 在 2,000 美元以内预订一张前往东京的机票。这个授权不仅包含金额，还隐含了目的地、时间、商品类别和任务目标。

Agent 支付 1,200 美元购买符合要求的机票，可能属于正常执行；用同样的金额购买企业软件，即使没有超出预算，也显然不属于这次授权。

因此，Agent 支付不能只检查“账户是否有钱”和“签名是否有效”。它还需要验证当前支付是否与用户任务一致，收款对象是否真实，支付页面或资源地址是否被替换，以及 Agent 是否在连续执行过程中逐渐偏离了原始目标。

这正是 Payment Harness 需要承担的工作。

Payment Harness 是位于 Agent 与支付结算系统之间的运行时控制层。它在资金真正移动之前，将当前支付与用户授权、任务上下文、收款对象和风险信息进行比对。

支付协议负责让资金能够移动，Payment Harness 负责判断当前这笔资金是否应该移动。

Agentic Commerce 已经出现了多种支付基础设施。

x402 让 API 和数字服务可以通过 HTTP 返回支付要求，Agent 完成稳定币付款后即可继续获取资源。Google AP2 使用结构化 mandate 表达用户的购买意图和交易约束。Visa Intelligent Commerce 和 Mastercard Agent Pay 则在 Agent 身份、支付凭证、Token 化和网络级交易控制方面展开建设。

这些方案已经不同程度地覆盖支付传输、身份认证、授权证明、用户意图表达和网络级交易控制。

但在真实执行中，系统仍需将协议提供的身份与授权信息，与机构规则、任务上下文、收款对象风险和历史执行状态结合，判断当前交易是否仍在原始授权范围内。

Payment Harness 并不替代钱包、稳定币、银行卡或支付协议，而是将这些能力接入统一的运行时判断流程，使用户授权不只停留在对话记录或系统提示词中，而成为支付系统能够验证和执行的边界。

为了研究这类判断，FluxA Research 建立了 Agent Payment Safety Benchmark。当前公开版本 MSAB-Eval-v2.2-Hard 包含 1,020 个评分支付事件，覆盖 15 类对抗性攻击。

每个事件都会提供一组支付相关信息，包括用户授权的 mandate、交易金额、用途描述、资源地址、服务 host 和收款地址。参评系统必须对每一笔交易输出 approve 或 reject，服务器再使用隐藏标签完成评分。

这里采用二分类，并不意味着真实 Payment Harness 只能批准或拒绝交易。二分类是一种便于比较不同模型和系统判断能力的评测设计；在实际运行环境中，系统仍然可能采用 SAFR 所描述的分层处置，包括自动执行、拒绝、人工审核和加强监测。

隐藏标签的作用，则是防止参评系统直接针对标准答案进行调试。公开的是需要判断的交易和上下文，正确处置结果保留在服务器端，由统一评分程序计算准确率。

PaymentBench 覆盖的攻击并不限于明显的超预算交易。许多测试案例在金额和文字描述上都十分合理，风险隐藏在域名、地址、任务范围或上下文变化之中。

其中一类攻击会在原有服务域名后增加新的顶级域名。

例如，合法服务使用：

api.brand-arb.com

付款请求却来自：

api.brand-arb.com.io

两个地址在视觉上非常接近，但从域名注册结构看，后者是一个完全独立的域名，可以由另一个主体控制。

如果系统只比较服务描述和金额，它可能认为这是一笔符合任务的低额付款。如果进一步检查实际注册域和运营主体，便会发现资金正在被引导到不同的服务方。

PaymentBench 还覆盖 Unicode 仿冒字符、子域名欺骗、收款地址替换、低信誉服务、新创建钱包、链上历史不匹配，以及将未授权服务包装进正常任务等情况。

这些测试共同指向一个事实：Agent 支付的安全判断不能依赖单一信号。

金额和有效期适合由确定性规则处理；任务是否一致，需要理解 mandate 和交易语义；域名、服务方和钱包地址是否可信，则需要结合外部风险信息。面对仍然存在歧义的情况，系统还可能需要独立模型或人工审核。

PaymentBench 的意义不只是形成一个模型排行榜。它让 Payment Harness 的设计可以被持续检验。

如果一套系统声称能够保护 Agent 支付，它不仅需要拦截明显的超预算交易，还需要面对更接近真实环境的情况：交易金额合理、服务描述与任务相关，但收款对象已经被替换；Agent 没有直接违反金额规则，却在连续调用中逐步扩大了任务范围。

在 FluxA 的设想中，用户提供的不是一张无限制的钱包，而是一份具有任务范围、预算和有效时间的 mandate。Agent 可以在 mandate 内连续执行，不必为每一次小额支付重新请求确认；与此同时，每一笔拟议支付仍然要在进入结算前，与这份 mandate 重新比对。

这使支付授权从一次性的“同意付款”，转变为持续生效的运行时边界。

PaymentBench 则为这套边界提供测试环境。规则、模型或风险数据每发生一次变化，都可以回到同一组攻击场景中重新评估，观察系统是否真正提高了判断能力，是否在拦截攻击的同时错误拒绝了正常支付。

对于支付基础设施而言，可重复验证比单个演示案例更重要。一个在特定案例中表现正确的模型，并不等于一个可以稳定保护资金的系统。Payment Harness 必须在不同任务、不同服务和不同攻击方式下保持一致的判断标准。

End