AI Agent 支付

边界,而不是信任

让 AI Agent 花钱,难点从来不是技术上能不能发起一笔支付,而是出事时损失有多大。三个现实约束决定了「信任 Agent」不是一个可行方案。

提示注入是常态,不是例外:Agent 读取的网页、邮件、文档、工具返回值,都可能包含针对它的指令。任何依赖 Agent「自己守规矩」的方案,都可以被一段精心构造的文本绕过。安全边界不能建立在被攻击对象的自律上——这是几十年安全工程的基本共识,放到 Agent 身上同样成立。

机器频率:人犯错一次会停下来想想,Agent 会在几秒内把同一个错误重复几百次。「事后发现、人工干预」这套流程,是为人类操作者的节奏设计的,对机器根本来不及。密钥即全部权限:一把泄漏的钱包私钥或 API 密钥,等于无限额度、无限次数——凭证泄漏在人类系统里是事故,在 Agent 系统里是必须假设会发生的事件。

因此正确的模型是把边界放在支付基础设施这一层,而不是放在 Agent 的自律里:人类一次性批准策略(预算、有效期、商户白名单、链与币种),Agent 在边界内自由执行,每一次请求都在服务端做策略校验。Agent 可以有创造力,钱不可以。

预付即边界

给 Agent 的卡采用预付模型,风险上限因此是一个你自己设定的确定数字:卡内余额。即使 Agent 被完全操纵——提示注入成功、任务定义被篡改、凭证泄漏——能造成的最大损失也不超过这个数,不会波及公司主账户。到期或超预算自动冻结,不需要人在场做决定。

这跟「给 Agent 一张公司卡然后盯着看」有本质区别:后者的风险上限是信用额度,前者的风险上限是你上周充进去的那笔钱。前者需要你时刻在线,后者让你可以下班。

像管理部署密钥那样管理 Agent 的支付通道

工程团队早就知道该怎么管理机器身份:一个服务一把密钥、权限最小化、可随时吊销、出事时爆炸半径限定在单个服务。Agent 的支付通道应当遵循同样的纪律。

• 一个工作负载一张卡,不共用——共用意味着出事时你无法定位是哪个 Agent 干的;
• 边界收紧:预算、有效期、商户类别与白名单,能限的都限死;
• 随时可冻结,通过 API 或后台,不走人工流程;
• 爆炸半径 = 一个 Agent,永远不是整个金库。

越界即信号

大多数支付系统只认真记录成功的交易。对 Agent 场景来说,这是错的:被拒绝的请求是你最有价值的安全信号。一个 Agent 突然开始尝试白名单外的收款方、或在短时间内反复触碰额度上限,往往意味着两件事之一:它被操纵了,或者它的任务定义出了问题。两件事你都想尽早知道。

所以设计上,拒绝记录得和批准一样详细:什么时候、哪个 Agent、想付给谁、多少钱、被哪条策略拦下。这让异常在造成损失之前先被看见,而不是在月末对账时才浮现。

三种替代方案,各自的问题

区别只有一句话:边界必须在 Agent 够不到的地方执行。