Stripe给AI代理套上"审批枷锁"：退款前必须等人点头

当AI代理开始直接操作真金白银，谁来踩刹车？Stripe给出了自己的答案——让代理在动钱之前，先问人。

Stripe上线了什么

据Stripe官方文档，8月26日平台新增了Approval Requests v2 API（公开预览版），入口位于Dashboard的Settings→Approvals。

这套机制的逻辑很直接：你为某个动作写一条规则，比如"退款创建"。除此之外，支付意图创建、订阅取消、贷项通知单创建以及部分账户变更也都可以被规则覆盖。

每条规则支持三类触发条件——金额（只在高出阈值时拦截）、操作者（团队成员或代理密钥触发时拦截）、频率（单位窗口内请求过多时拦截）。触发后有两种控制模式：要求审批会暂停动作直到审核人放行，直接阻止则当场拒绝。

Stripe还引入了一种新密钥类型：你可以将受限密钥标记为归属于自主代理。官方称这是"给代理授权的推荐方式"。代理密钥自带默认规则——退款和取消订阅必须等人批准。

当代理密钥命中规则时，API返回approval_required，Stripe自动归档请求，审核人在Dashboard中批准或拒绝。已批准的动作自行执行，被拒绝的不会有任何变化，请求14天后过期。

代理密钥（Agent Key）与受限密钥（Restricted Key）的区别

Stripe 原有的 API 密钥体系分为两种：Secret Key 拥有账户的完全权限，Restricted Key 则允许你按资源类型（如退款、订阅、支付意图）逐项授予读或写权限。Approval Requests v2 引入的"代理密钥"并不是一种全新的密钥格式，而是在受限密钥之上增加了一层"身份标记"——通过标记该密钥归属于自主 AI 代理，Stripe 会自动为其绑定一套默认审批规则。这样做的好处是：权限最小化（来自受限密钥）与身份可追溯（来自代理标记）叠加，审计日志中可以清晰区分"这是人发起的退款"还是"这是代理发起的退款"。对于已有大量受限密钥的团队，升级路径通常是新建一把带代理标记的密钥并逐步迁移，而不是直接改造旧密钥。

Approval Requests v2 中的"v2"意味着什么

Stripe 早在 2023 年前后就推出过初版的审批请求能力，主要面向 Issuing（发卡）场景，用于商户侧对大额或异常交易做人工确认。v2 的关键变化在于把审批对象从"卡交易"拓展到了"账户动作"——退款、订阅取消、贷项通知单、支付意图创建等都可被规则覆盖，并且引入了操作者维度（团队成员 vs 代理密钥）与频率维度。理解这一演进有助于判断：Stripe 正在把审批从风控子系统提升为账户级的基础设施，未来大概率会继续扩展到更多的写操作。

一个真正值得注意的设计

这套机制中最巧妙的一点：请求者不能批准自己的请求。即使是在单人账户中，代理密钥也被视为独立操作者。所以账户所有者来批准代理，代理无法批准自己的支出。

这个规则看似简单，却切中了AI代理安全的核心矛盾——如果代理既能发起交易又能批准交易，那审批层就形同虚设。Stripe把这个边界固化到了系统设计中，而不是留给用户去配置。

MCP服务器遵循同样的思路。某些写操作（如退款和对外支付）需要人工先点击确认链接。从10月31日起，Stripe MCP将不再接受完全访问密钥或未标记的受限密钥。每条规则的变更和每次决策都会出现在安全历史中，每个状态变化都有对应的webhook。

MCP 与"写操作需人工确认"

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的开放协议，用于让 AI 模型以标准化方式连接外部工具与数据源。Stripe 提供的 MCP 服务器让代理可以直接调用 Stripe API（查询余额、创建退款、发起支付等）。协议本身把工具分为"只读"与"写入"两类，写入类工具在执行前可以要求一次带外的人工确认（通常是点击一个一次性链接）。这与 Approval Requests 是互补关系：MCP 层负责"代理是否被允许调用这个工具"，Approval Requests 层负责"这次具体调用是否被批准"。10 月 31 日起停用完全访问密钥，本质上是把 MCP 通道的权限模型对齐到最小必要原则——因为一把能创建退款又能审批退款的密钥，会让上层的所有审批机制失去意义。

策略版本与可审计性

企业合规审计关心的不只是"这次调用被允许了"，还包括"依据的是哪一版策略"。如果一条退款规则从 100 美元调整到 200 美元，那么调整前后同一笔 150 美元的退款会有不同的处置结果。Stripe 的安全历史记录了规则变更和每次决策，但跨平台场景下，各家的策略版本号、变更时间戳、原因码往往彼此独立。这也是 Axiru 之类上层控制层试图解决的问题：把策略集中定义、统一打版本，再分发到各个支付通道执行，从而让"为什么放行/拦截"这个问题有单一可查的答案。

它覆盖了什么，没覆盖什么

Stripe Approvals治理的是你的Stripe账户——这是它的职责，而且它做得不错。但代理不会只生活在一个支付处理商里。

一个客服代理今天在Stripe上退款，明天团队可能为另一个区域接入第二个处理商。一个运营代理用信用卡向供应商付款，一个研究代理用稳定币支付API调用。每个地方都有自己的规则界面、自己的限额、自己的日志——或者根本没有。

于是策略出现了分叉。Stripe里设了一个200美元的退款上限，另一个平台上设了不同的上限，没有人掌握全貌。

对Stripe此举持肯定态度的Axiru团队指出了这个盲区。他们认为，核心规则——"AI不能批准自己的支出"——应该适用于每一条支付通道，而不仅仅是一个。

Axiru自称是一个跨AI模型、代理框架和受支持支付通道的独立控制层，提供统一策略、独立于支付通道的检查机制、去重窗口、白名单、方法匹配，以及带原因码的allow/hold/deny决策。

"去重窗口"与影子模式

去重窗口（dedupe window）指的是在一段时间内，对语义上相同的操作只允许执行一次，即使它们来自不同的调用路径。例如代理因超时重试而两次发起同一笔退款，单看金额和频率都不触发规则，但去重窗口可以识别出"这是同一笔"。影子模式（shadow mode）则是不真正拦截、只记录"如果策略生效会怎么处置"的运行方式，适合在正式启用新策略前用历史数据评估误伤率。这两个概念在传统的反欺诈与支付风控中已经成熟，把它们迁移到 AI 代理场景，意味着代理的支出管理可以复用大量已有的工程实践，而不必从零设计。

实用的组合方式

Stripe Approvals和上层控制层不是二选一的关系。如果你在Stripe上运行代理，开启Approvals、标记代理密钥、保留默认规则是基本操作。

然后可以问自己几个问题：

• 你的代理除了Stripe，现在或下季度是否会在其他地方动钱？
• 是否需要一个人在一个队列中看到所有代理资金流出？
• 是否需要捕获同一笔重复退款，而不仅仅是金额大的退款？
• 能否向审计师证明每次调用使用的是哪个策略版本？

任何一个答案为"是"，你就需要支付通道之上的一层控制。

对开发者的意义

Stripe这次更新传递了一个清晰信号：AI代理的支付权限需要被当作独立的安全边界来对待。不是因为代理会作恶，而是因为代理会犯错——而犯错的钱一旦出去，就很难追回。

代理密钥的默认规则设计尤其值得借鉴。它不是在用户犯错后才提醒，而是默认收紧、按需放开。这个思路可以迁移到任何涉及AI自主决策的系统设计中。

Axiru还提供了一个免费的过去数据审计服务——将过去90天的退款在影子模式下回放，看看哪些会被允许、拦截或拒绝。这种"用历史数据验证策略"的方法，对于任何正在考虑引入代理审批机制的团队都有参考价值。

"默认收紧、按需放开"的权限设计原则

这一思路在安全工程中被称为 fail-safe defaults 或 secure by default，最早由 Saltzer 和 Schroeder 在 1975 年的经典论文《The Protection of Information in Computer Systems》中系统提出，是访问控制设计的八项基本原则之一。与之相对的是"默认放开、出事再收紧"，后者在人类用户场景下尚可接受（因为人会主动阅读文档并配置权限），但在代理场景下风险被放大：代理会以远高于人的频率调用 API，一旦默认权限过宽，损失会在几分钟内累积。Stripe 把"退款和取消订阅默认需审批"写进代理密钥，正是把这条老原则应用到了新场景。开发者在设计任何涉及 AI 自主决策的系统时，都可以问自己：新接入的代理，默认获得的是最小权限还是全部权限？