智能体自主发起付款的风险与应对:Pink 的核对清单
智能体自主发起的付款反复出现六类风险:预算失控、收款方漂移、提示词注入引发的付款、审计记录缺失、缺少人工审核环节,以及凭证授权范围过宽。Pink 智能体支付(Pink Agentic AI Payments)把每一类风险都对应到一条在发出任何凭证之前就会检查的服务器端控制措施上,而不是寄希望于智能体自己遵守某个承诺。本文逐一列出每种风险、对应的控制措施,在确实存在空白的地方,也直接说清楚,而不是含糊其辞。
"智能体承诺不会超支"不是一种控制措施,那只是一个期望。真正的控制措施,是一条由智能体无法绕过的系统强制执行的规则,对每一笔请求都用同一种方式检查,无论触发与否都用同一种方式记录下来。
六类风险对应的控制措施
| 序号 | 风险 | 具体会出什么问题 | Pink 的控制措施 | 在哪个环节生效 |
|---|---|---|---|---|
| 1 | 预算失控 | 重试循环、程序缺陷,或被攻破的智能体,试图花掉远超预期的金额。 | 在任何规则之前就检查的三道断路器:智能体的月度预算、所有智能体共享的公司每日上限,以及资金库余额。预算用尽的智能体会被直接停止,而不是排队等待。 | 服务器端,在每一次 pink.request_payment / POST /v1/payments 调用时 |
| 2 | 收款方漂移 | 智能体付给了一个本不该付的供应商、类别或账户。 | 收款方白名单(approved 与 new 区分)加上按类别的拦截(cat:blocked 按名称匹配礼品卡、加密货币交易所、类现金转账和赌博类),无论金额多少都适用。 |
规则评估,按每笔付款 |
| 3 | 提示词注入引发的付款 | 一份恶意文档、邮件或工具输出诱导智能体发出一笔本不该发的付款请求。 | 用 action: block 且完全不配 approvers 的拦截规则,意味着根本不存在一条攻击者能说服智能体走通的审批路径。按 Pink 自己的安全文档所说:"一个失控的流程说不动它们,一个巧舌如簧的智能体也说不动。"这并不能检测或过滤注入本身,它只是让一个被骗的智能体最终的付款结果变得无关紧要,因为决策从来不取决于智能体相信了什么或被告知了什么。 |
规则评估,独立于智能体的推理过程 |
| 4 | 审计记录缺失 | 没人能还原一笔付款为什么会发生、是哪条规则放行的、谁审批了它。 | 每一次规则变更都会发布一个带编号的新策略版本,并记录作者。每一条付款记录都存有当时生效的策略版本、命中的规则、完整的决策追踪记录、涉及的审批人,以及发出的凭证。被拦截和被拒绝的请求也会被保留,日志可导出用于审计。 | 每次请求都会记录,无论成功与否 |
| 5 | 缺少人工审核环节 | 高风险或异常的付款在没有真正询问过任何人的情况下就自动通过了。 | 一条 ask 规则会指定具体的人,或某个组内的法定人数。请求会变成一个带超时时间的待批状态;如果没人在超时前作出回应,这个待批状态会过期,智能体收到的是 expired,而不是被默认批准。没有任何东西会被默认批准。 |
规则动作 ask,配合具名的 approvers |
| 6 | 凭证授权范围过宽 | 一个泄露或被滥用的智能体密钥,能做的事远超这个智能体本应被允许的范围。 | 一个智能体只持有一样东西:一个密钥。它读不到自己没有被绑定的余额,看不到公司卡,也碰不到银行登录信息。审批通过后拿到的是一个一次性凭证(卡或转账),锁定在那一个收款方和金额上,发出 15 分钟后过期。一个泄露的密钥,能做的事被限定在这个智能体自己的预算、上限和资金库之内;它改不了规则,提不高预算,也付不了被拦截的收款方。 | 凭证发放 + 密钥权限范围限定 |
为什么"智能体承诺不超支"不算一种控制措施
一个承诺活在智能体的提示词或训练里;一条控制措施活在智能体没有写入权限的服务器上。这个区别对上表第 3 条风险尤其关键:一个被一份被污染的文档或工具输出说服、认定"现在超支是对的"的智能体,在尝试同一笔付款时,仍然会撞上和一个诚实的智能体完全相同的拦截规则,因为这条规则从不询问智能体相信了什么,它只检查收款方、金额和时间。
重试或重复请求时会发生什么
有两类风险值得单独说一下,因为它们很容易被忽略:一次重试请求导致重复扣款,以及一张重复的发票被付了两次。Pink 对这两种情况都有应对:request_payment 带有一个 idempotency_key(或 REST 的 Idempotency-Key 请求头);用相同的键重复请求,返回的是原来的决策结果并附带 replayed: true,而不会产生第二笔付款。另外,在 90 天窗口内检查重复发票号,是 Pink 参考策略里一种标准的欺诈规则模式,会在金额分级规则之前被检查。
Pink 目前还没覆盖到的地方
直接说清楚,不回避:
- 沙盒里的凭证验证是自我声明的。 一条规则可以要求某个标志存在,比如
po(采购订单)或scan(仓库扫描记录),才允许一笔付款通过,但在沙盒里,这个标志是否存在,是由智能体自己声明的。Pink 自己的文档说明,生产环境会对照已接入的系统(ERP 采购订单、工单系统、仓库扫描记录、承运商单据)来验证这些标志;沙盒不会。 - 检测注入本身不在覆盖范围内。 Pink 的控制措施让一次成功的提示词注入对付款结果变得无关紧要;但它们并不会识别或标记出智能体的推理过程里上游发生过一次注入尝试。
不只是理论上说得通,也在并发压力下测过
一次真实测试,从单个智能体并发发出 40 笔 200 美元的付款请求,对照一个 6,000 美元的公司每日上限:恰好 30 笔被放行(合计恰好 6,000 美元),10 笔被拦截,与服务器自己的账本记录完全一致。另一次测试,在同样的并发压力下检验了单个智能体的月度预算:8 笔请求在预算用尽前被放行,其余全部被拦截。
还有一项测试检验了第 1 条风险(预算失控)背后的那道共享每日上限,在多个智能体同时撞向它时,而不只是单个智能体时,是否依然站得住。三个智能体(采购、库存、薪酬与账单)分两轮并发发出共 40 笔付款请求,共用同一个 6,000 美元的上限:第一轮,40 笔中 27 笔被放行,合计 5,720 美元(加上当天已花掉的 180 美元,合计 5,900 美元,仍低于 6,000 美元);第二轮,40 笔中 32 笔被放行,合计恰好 6,000 美元。两轮加在一起被拦截的 21 笔请求,全部提到了"Company daily ceiling reached"(已达到公司每日上限)并附带当时的累计总额,两轮测试中放行总额都和服务器自己的账本完全一致。这只是单次测试会话中观察到的沙盒行为,并不代表这项检查在所有条件下都是原子的或基于锁实现的,也没有在生产环境中验证过。
Pink 还运行着一个公开的 Overspend Challenge(超支挑战),邀请外部开发者直接尝试击败这些控制措施;截至目前报告的 3 个发现中,2 个已修复(一个货币代码漏洞和一个时间规则中的时区漏洞,均于 2026-10-10 上线修复),1 个(一个亚分位舍入的边界情况)正在修复中。
上线前的风险自查清单,逐条过一遍
在接入一个生产环境的智能体之前,逐一确认这六类风险背后都有一条真实的规则,而不只是默认设置:
- 这个智能体是否设置了
monthly_budget、company_daily_ceiling,以及资金库余额检查,而你是否确认过资金库里真的有那么多钱? - 收款方名单是一份白名单(
approved),而不是完全开放的(any),并且配置了你需要的拦截类别吗? - 那些你永远不想被批准的付款,是写成了没有配
approvers的block规则,而不是某个人迟早可能会批准的ask规则吗? - 事后你能不能拉出一笔付款当时的策略版本和决策追踪记录?你的合规团队知道导出日志存在哪里吗?
- 对于每一条
ask规则,是否有一个具名的审批人或组,会在待批状态超时之前真正看到这条请求? - 智能体的密钥是否只能触及它需要的资金库和收款方,完全没有通往管理员密钥或其他智能体预算的路径?
当前的限制
以上所有内容都是在 Pink 的公开沙盒 agentic-sandbox.pinkwallet.com 上演示的:免费、无需注册、仅使用测试凭证,没有任何一笔动用真实资金。将这些控制措施用于公司真实付款的生产环境,目前处于早期访问阶段,需通过 pinkwallet.com/agentic/developers/ 的候补名单申请,尚未对所有用户开放。
常见问题
让 AI 智能体自主发起付款,最大的单一风险是什么? 预算失控,比如程序缺陷、重试循环,或被攻破的智能体花掉远超预期的金额,是实践中最常见的失败模式。Pink 的应对方式是在任何其他规则之前就检查的断路器(预算、每日上限、资金库余额),这样无论智能体为什么会发出这个请求,这类失败都会被拦住。
提示词注入攻击能让智能体付钱给它本不该付的对象吗? 攻击仍然可能在上游发生,但 Pink 的拦截规则并不询问是什么说服了智能体;它们只检查收款方、金额和时间,对照完全没有审批路径的规则。一个被骗的智能体,会撞上和一个诚实的智能体完全相同的那道墙。
Pink 会不会保留每一笔付款决策的审计记录,包括被拦截的那些? 会。每一条付款记录,包括被拦截和被拒绝的请求,都存有当时生效的策略版本、命中的规则、完整的决策追踪记录、涉及的审批人,以及(如果有的话)发出的凭证。日志可导出用于审计。
"缺少人工审核环节"这个问题,是真的解决了,还是只是多加了一个更慢的人工步骤?
一条 ask 规则需要一个具体的人或一个组的法定人数真正做出回应;如果没人在超时前回应,这个请求会直接过期,而不是被默认批准。这并不是一个走形式的橡皮图章,但确实意味着一个迟迟不回应或根本不存在的审批人,会拦住这笔付款,而不是放它通过。
如果智能体的密钥被盗了会怎样? 一个泄露的密钥是被限定范围的:它只能做这个智能体本来就能做的事,被限定在这个智能体自己的预算、上限和资金库之内,只能付给它的策略允许的收款方。它改不了规则,提不高预算,也付不了被拦截的收款方。在控制台里轮换密钥,旧密钥会在几分钟内失效。
这些控制措施是经过真实攻击者验证的,还是只做过内部测试? 两者都有。Pink 的团队先对这套引擎做了内部红队测试,之后才开放了一个公开的 Overspend Challenge,让外部开发者可以用自己的智能体直接尝试击败它;目前已经报告了 3 个外部发现,2 个已修复,1 个正在修复中。
