金融 Agent 的权限和额度必须由后端执行

让 AI 自动支付供应商账单，难点不只是找对发票、生成正确的转账参数。客户是否授权、收款账户是否变更、额度是否已被其他任务占用，都可能让一笔看似合理的付款越界。

作者给出的原则是「Policy Before Prompt」：金融规则的权威高于模型输出，必须由可信服务强制执行。这篇短文值得读的地方，是把「模型判断可以付款」与「系统能够安全付款」之间的距离拆了出来。

模型交出合法 JSON，为什么还不能付款

假设用户要求 Agent 在发票逾期前向已批准的供应商付款。Agent 找到发票、核对收款方，再提交一笔结构化转账操作，整个推理过程可能没有明显问题。

但付款权限不能靠推理成立。

作者明确指出，supplier_approved、approval_complete 这样的字段，即便出现在格式正确的 JSON 中，也不能因此成为可信事实。模型填写「审批完成」，与审批系统确认「审批完成」，是两件事。

后端需要自行验证资源归属，从权威服务取得授权、审批和收款方信息，再评估策略并检查执行条件。提示词可以提醒模型遵守规则，却不能代替这些检查。

身份认证也有类似边界。证明请求来自某个 Agent 工作负载，只能确认调用者身份，不能证明是哪位客户授予权限，更不能证明授权覆盖哪些账户。

Agent 可以提出操作，但不能通过自己提交的字段证明自己有权执行。

策略允许了，为什么付款仍然可能出错

原文最有价值的部分，是指出权限判断之后还有并发、审批绑定和支付状态问题。

先看额度。剩余额度为 ₹30,000，两个 worker 各自提出 ₹20,000 的付款。如果它们读取同一份额度快照，两笔操作都可能通过策略检查，合计却超过限额。因此，allow 决策不能代替额度预留，共享额度必须通过原子机制协调占用。

再看人工审批。审批应当绑定到某个固定版本的交易详情。如果金额、手续费，或者收款方底层银行账户信息发生变化，之前的审批就应失效。仅绑定供应商身份还不够，因为同一个供应商的收款账户也可能变更。

支付超时则是另一个容易误判的状态。服务商可能已经接收付款，只是响应丢失了。此时直接创建替代转账，可能造成重复支付。系统需要按服务商支持的恢复流程确认结果，不能把超时直接归为失败。

最后，策略更新及时，不代表事实也更新及时。授权、审批、收款方信息各自都有新鲜度问题，需要分别控制。

这些问题说明：授权负责回答「是否允许」，交易协调与故障恢复负责把这份许可可靠地落实到执行。

真正的检查应该放在哪一层

作者建议把强制执行放在金融操作的执行边界，也就是付款真正发出去之前、所有调用路径都必须经过的位置。

实际路径应包括：从权威服务读取关键事实，取得明确成功的 allow 决策，原子预留共享额度，把审批和幂等记录绑定到固定交易详情，并处理服务商返回结果不确定的情况。这里的幂等记录，是帮助系统识别重复操作、约束重复执行的记录。

提前拦截 Agent 的工具调用有帮助，但如果另一个调用者可以绕过检查，整套约束仍然不完整。规则需要跟着付款能力走，覆盖所有入口。

机器可读策略的价值，在于让授权规则变得明确、可审查；它能否有效，还取决于输入是否可信、边界是否强制、支付状态是否管理可靠。

我的判断

我认同作者对权限边界的划分。相比只在提示词中反复强调限制，把关键事实和执行许可交给后端，更容易检查规则是否真正生效，也能避免把模型输出误当成业务凭证。

但原文提供的是架构原则，没有实测数据、并发测试结果或故障恢复案例，不能据此判断某种实现已经可靠。文末提到的 Rego 示例和完整审批设计，也没有出现在这份正文里。

它同样没有证明独立策略引擎一定优于普通后端校验。团队可以根据复杂度选择实现方式，关键是保证规则无法绕过，并把授权检查与额度预留、交易状态协调起来。仅增加一次策略查询，并不会自动解决并发超支和重复付款。

能拿来做什么

• 如果在 Node 后端接入付款 Agent，把模型输出当作待验证的操作请求；资源归属、授权范围和审批状态都由服务端确认，不采信模型自报的完成标记。
• 如果多个任务共享额度，把「策略允许」与「原子预留」分别设计清楚，并验证原文中 ₹30,000 余额同时遇到两笔 ₹20,000 请求的情况。
• 如果前端提供人工审批界面，让审批对应明确版本的金额、手续费和收款账户详情；这些内容变更后，要求重新审批。
• 如果付款接口超时，先进入结果核实与恢复流程，依据服务商支持的机制确认状态，再决定后续动作，避免直接创建替代转账。