金融 Agent 如何落实最小权限

AI Agent 一旦能发起支付、退款或创建收款人，就进入了身份与访问管理（IAM）的范围。原文的核心主张很明确：Agent 应当按当前任务领取有限权限，不能因为运行在后端，就继承后端的全部访问能力。

这篇文章没有提供实测数据或完整实现，而是梳理了一组金融系统的权限边界。对正在给 Agent 接入业务工具的程序员，它最有用的提醒是：模型负责提出动作，业务服务负责判断动作能不能执行，重试机制还要保证同一笔操作不会重复发生。

后端有权限，为什么不能直接给 Agent 用

原文从一条常见调用链切入：

Mobile App → Backend → AI Agent → Financial APIs

后端已经持有内部 API 凭证，让 Agent 复用它，接入成本确实低。但后端身份可能同时拥有多个客户、账户、支付、退款乃至配置接口的权限，而当前任务可能只需要替某一个客户处理某一笔付款。

问题就在这里：部署位置决定了权限大小，当前任务却没有成为权限边界。

作者提出的授权链是：

User identity → Delegation → Agent identity → Limited capability → Resource authorization

可以把它理解为：先知道用户是谁，再确认用户委托了什么、哪个 Agent 正在代办、它这次拿到了哪些能力，最后由目标资源检查具体请求。

这里的「Agent 身份」也不能只理解成一个产品名称。原文要求每次执行都有可识别的身份与委托上下文，才能回答「这次操作到底是谁授权、由谁代办」。

认证与授权因此要分开。知道客户是 user_82741，并不能回答：这个 Agent 此刻能否从指定账户向指定收款人转出 ₹18,000？

payments:create 这样的权限，只说明可以创建支付，未必约束了客户、账户、收款人、金额和审批条件。权限检查必须落实到这一次具体操作。

Prompt 和短期凭证，为什么都不够

原文举了一个很直接的例子：系统提示词要求 Agent「转账不得超过 ₹25,000」。

这能引导模型行为，却不能承担支付系统的保护职责。如果模型提交 ₹25,001，支付服务应该直接拒绝，不能依赖模型是否记住规则、是否正确理解当前上下文。

作者强调的是职责分工：模型可以决定尝试什么，确定性的授权逻辑决定什么能够执行。所谓「确定性」，就是由明确的程序规则检查请求，不让模型临场解释自己有没有权限。

短期凭证解决的是另一部分问题。一个有效期只有五分钟的管理员凭证，在这五分钟内仍然拥有管理员权限。权限持续多久，与权限覆盖多大范围，是两个需要同时收紧的维度。

因此，作者建议按任务签发短期权限，并限制相关客户、账户、资源和动作。风险需要时，还应拆开读取、准备、批准和执行能力。

这个拆分对金融工具尤其关键：能准备一笔付款，不应自动等于能批准或执行这笔付款。若工具接口把这些能力混在一起，上层再细致的任务描述，也很难形成清晰的权限边界。

为什么权限检查过了，支付仍然可能出事故

权限正确，不代表交易只会执行一次。

原文设想：Agent 提交支付请求，支付可能已经完成，但网络在结果返回前超时。编排层随后重试，如果没有幂等机制，同一笔逻辑付款就可能形成多笔交易。

授权回答「这件事能不能做」，幂等回答「这件事是否已经做过」。两者互补，无法相互替代。

作者用一个发票付款场景串起这些控制：Agent 获得的权限包含最高金额 ₹42,000，以及有限的执行窗口。如果模型尝试 ₹43,000，由策略拒绝；如果引用其他客户的账户，由资源授权拒绝；如果超时后重试，由幂等机制阻止同一逻辑付款再次成为交易。

这里有个需要保留的细节：原文先说 Agent 可以「准备付款」，随后又讨论交易执行与重试，却没有给出准备、审批、执行之间的接口设计。因此，这个例子能解释控制职责，但不能直接充当完整支付流程。

除了授权与幂等，作者还要求结合风险控制、权限撤销和监控，并保留用户 → Agent → 策略 → 工具 → 交易的审计链。出了问题，需要能还原整条执行路径。

我的判断

我认同原文对权限边界的划分。相比只在 Prompt 中写限制，或者直接复用后端凭证，把客户、资源、动作与金额约束交给业务服务执行，能让安全规则独立于模型行为。

但这是一篇架构原则文章，没有实现代码、对照实验，也没有说明凭证如何签发、委托怎样校验、撤销何时生效。不能据此判断某种具体 IAM 方案更可靠，或宣称它已经降低了多少风险。

落到一般团队，也不必把每次 Agent 执行都做成一个永久账号。关键是执行身份和委托关系能够被识别、校验、追踪；具体如何承载，原文没说清。

同样，短期权限也不能替代已有的交易约束。Agent 的授权范围，应当叠加在支付服务原有的业务规则之上。 原文最后提到的 sender-constrained credential 讨论位于另一篇文章，当前材料没有展开，不能据此补出实现结论。

能拿来做什么

• 给 Node 后端接入支付或退款工具时，先列出当前任务需要的客户、账户、动作、金额上限和有效窗口，再检查传给工具的权限是否超出了这张清单。
• 把 Prompt 里的金额限制、账户范围和审批要求，同步落实到受保护的业务接口中。即使模型构造出越界请求，接口也应能够独立拒绝。
• 为金融操作明确「同一笔逻辑请求」的识别方式，让超时重试复用这一身份，并检查编排层重试是否会触发重复交易。
• 检查日志能否串起用户委托、Agent 执行、策略判断、工具调用和最终交易，避免只有模型对话，却无法还原资金操作。