支付 Agent 上线前先厘清授权边界

把支付 API 包装成 MCP 工具，演示里让 Agent 付出一笔钱，可能几天就够了。真正难的是回答：它凭谁的授权付款，额度由谁控制，遇到重试又怎么避免重复扣款？原文的结论是，工程重心应该放在授权层。

这篇解读值得程序员关注的地方，是它把「让模型调用接口」拆成了身份、规则、审批和审计几个可实现的环节。但原文仍是 2026-11-12 创建、等待合作伙伴审阅的草稿，也带有团队服务推广，建议与验证结果需要分开看。

为什么现有 API key 管不住 Agent

传统 B2B 支付接口通常用长期 API key 识别公司，再按角色分配权限：管理员能付款，只读角色不能。对于每天执行固定流程的 ERP 集成，这套设计容易理解。

Agent 改变了三个前提。它的调用顺序不固定；它读取的发票 PDF 可能夹带诱导指令；它虽然代表某个人行动，那个人却未必看过具体付款。于是，「哪个 key 调了哪个接口」只能证明请求来源，不能回答「谁批准向这个供应商付这笔钱」。

有接口调用权限，不等于有每一笔付款的决定权。

作者用欧盟监管说明这个缺口：PSD2 的强客户认证要求认证码与金额、收款人动态关联，对应 Commission Delegated Regulation 2018/389 的 Article 5；DORA 自 2025 年 1 月起适用，涉及 ICT 第三方风险和事件可追溯性。不过，原文没有展开具体业务的适用条件，不能据此认定某套代码已经满足合规要求。

他们观察到的常见路径，是先把所有 endpoint 映射为工具，复用客户 API key，再依赖模型遵守提示。演示可以成功，系统却没有位置表达「这笔钱必须先找人确认」。

因此，作者建议在 Agent 工具入口和支付核心之间增加授权层。它负责判断具体业务动作能否执行，而不只是确认调用者有没有登录。

授权层要把四件事连起来

第一件事是按委托签发凭证。同一个客户的不同委托，应使用各自的短期 token，记录委托人、Agent 身份和权限范围，避免直接交出客户的长期 API key。

原文建议采用 MCP HTTP transport 已定义的 OAuth 2.1 授权流程，并用 OAuth Rich Authorization Requests（RFC 9396）表达最大金额、允许的收款人等结构化权限。这里要保留一个问号：原文将这些字段描述为放进 token，却没有解释授权请求如何映射到最终凭证，实际实现还需要补齐协议细节。

第二件事是每次写入都在服务端检查规则。下面这段代码处理委托过期、陌生收款人、单笔超额和日累计超额，保留了原文实现：

type Delegation = {
  principalId: string;
  agentId: string;
  maxAmountMinor: number;       // per payment, in cents
  dailyCapMinor: number;
  allowedPayeeIds: Set<string>; // pre-approved suppliers only
  expiresAt: Date;
};

async function authorize(d: Delegation, p: PaymentIntent): Promise<Decision> {
  if (d.expiresAt < new Date()) return deny('delegation_expired');
  if (!d.allowedPayeeIds.has(p.payeeId)) return requireApproval('new_payee');
  if (p.amountMinor > d.maxAmountMinor) return requireApproval('over_limit');
  const spent = await ledger.spentToday(d.principalId, d.agentId);
  if (spent + p.amountMinor > d.dailyCapMinor) return requireApproval('daily_cap');
  return allow();
}

最关键的是返回 requireApproval 的几行。它把结果从「允许或拒绝」扩展成「暂停执行，等待人工批准」，审批界面必须展示准确金额和收款人。作者希望将这次批准与最终付款关联，用于支撑 SCA；但关联记录本身是否足够，原文没有证明。

提示词可以告诉 Agent 额度，真正拦住越权付款的必须是服务端代码。

第三件事是让幂等跟着业务意图走。Agent 可能在困惑时重试，还会换参数。如果每次请求都由客户端生成新的幂等 key，同一张发票可能产生两笔付款。作者建议用委托人、收款人、发票引用和金额的哈希识别同一个付款意图，让重复尝试归并到已有记录。

第四件事是保留一条关联完整、只能追加的审计链：工具调用、使用的委托、命中的规则、审批人以及最终 payment ID 都能串起来。作者给出的起点很朴素：Postgres 插入表，并撤销应用角色的 UPDATE、DELETE 权限。

我的判断

我认同它把授权放回确定性代码的方向。相比共享 API key 加提示词约束，独立委托凭证和服务端规则更容易界定责任；相比所有付款都人工确认，预先批准的收款人与额度又能保留一部分自动化价值。

但这是一组架构建议，原文没有给出事故减少比例、误拦截率、延迟或吞吐量的对照数据。「几天接通 MCP」「每一部分需要几周」也只是作者的工期估计。

示例还有两个生产环境必须补的缺口。其一，ledger.spentToday 先查询、后付款，并没有展示并发控制：两笔请求可能同时看到剩余额度充足。其二，幂等哈希包含金额，而作者又强调 Agent 会改参数重试；如果金额变了，哈希也会变。是否允许同一发票多次付款、如何识别修改后的意图，仍需业务规则决定。

撤销应用角色的更新和删除权限，是审计表的基础保护，也不足以单独证明整条记录不可篡改。

组织建议同样有前提。作者描述的环境是 Java/Kotlin、Spring Boot、Kafka，变更可能跨四个代码库、四组评审者，因此主张成立专门小组，支付核心团队参与评审。对于 TypeScript on Node 的小团队，未必需要新增组织，但需要明确一个负责人贯通身份、风控和审计。

文章最后推广 SifrVentures 的专属工程团队服务。它提到首个客户从一名工程师扩展为跨职能团队，却没有披露支付授权方案的实际运行结果。团队配置可以参考，不能当成方案效果的证据。

能拿来做什么

• 给 Node 服务接入支付 MCP 时，先列清每项写操作的委托人、允许收款人、金额限制和过期条件，再决定开放哪些工具。
• 把 allow、deny、requireApproval 做成明确的服务端结果；前端审批页展示准确金额和收款人，并让审批记录关联最终 payment ID。
• 验证 Agent 重试时，覆盖更换幂等 key、修改金额和并发付款，检查重复付款识别与日累计额度能否同时成立。
• 为每笔付款串起工具调用、委托、规则结果和审批记录，并明确由谁负责这条链路，避免问题停在多个团队的交界处。