Stripe 让智能体动公司账户，限额还没上线

小公司的银行账户开始向智能体开放付款权限，而按金额给智能体设上限的护栏还没上线，眼下靠的是每一笔由人点一次批准。

先说结论。Stripe 10 月 21 日推出 Treasury for agents，让 ChatGPT、Claude 这类智能体通过 Stripe 的 MCP 服务器（一种让智能体调用外部工具的标准接口）操作企业的 Treasury 账户：查余额、付发票、在账户间转账、换汇。我们的看法是：这一步把智能体从「替你看账」推到了「替你动钱」，但它目前的护栏是逐笔人工批准，按金额设上限的花费限额要「未来几周」才上线。在那之前，更稳妥的用法是让智能体把付款准备好、由人确认，而不是把付款交给它。

一个人的公司，一个看账的智能体

Stripe 在发布稿里只点名了一个客户。Kubrio 是一个让 6 到 13 岁孩子做电影、游戏、漫画和机器人设计的平台，创始人 Vlad Stan 是唯一的员工，他的原话是「Kubrio 靠一个创始人加 AI 智能体运转」。他今年早些时候把 Kubrio 的主账户搬到 Treasury，他的 Grok 智能体 Stash 通过 MCP 连着这个账户。每天早上，Stash 检查余额、新增和取消的订阅、失败的扣款和退款，再给 Stan 发一份报告，Stan 每天读，发现问题再介入。

这件具体的事说明了现在的分寸：智能体在读数、写报告，钱还没交给它。发布稿写的下一步是「计划」让 Stash 在 Kubrio 的账户之间转账、给平台的承包商和创作者付款，并且「所有付款都由 Stan 批准」。也就是说，Stripe 拿来展示的唯一客户，还没有让智能体动过一分钱。这里的人数和流程都是企业宣称，我们无法核对。

能做什么，靠什么拦

据 Treasury for agents 的文档，这项功能处于公开预览，新增五个工具：查看余额汇总、换汇、向收款人付款、设置收款人、在 Stripe 余额之间转账，每个工具要求不同的读写权限。文档写明，接入时可以给每项能力分别设权限，并且「默认情况下，智能体发起的任何会让真实资金流动的操作，都要你审核并批准」。发布稿补充，企业可以选择智能体能看哪些账户和数据、只读还是能操作、什么时候动钱要人批；按智能体设花费限额、让智能体开卡，则是「即将」和「未来几周」的事。

批准具体怎么发生，写在 Stripe 的 MCP 文档里：用本人账户经 OAuth 授权接入时，退款、对外付款这类写操作要人工确认，确认方式是点开智能体给出的链接、查看请求细节后批准；批准后 Stripe 给智能体一个批准凭证，还要你再让智能体重试一次，24 小时内不批就失效。同一份文档建议打开 MCP 客户端自己的工具审批开关，并提醒与其他 MCP 服务器混用时要防范提示注入（藏在网页、邮件里诱导智能体执行指令的文字）。

授权方式有两种：OAuth 代表你本人的账户，「智能体 API 密钥」给需要独立、长期访问的 AI 应用。文档还写明，从 12 月起 Stripe MCP 不再接受完全权限的密钥和没有智能体标签的受限密钥，要换成新建的智能体密钥或改用 OAuth。

据 WebProNews 的报道，Stripe 强调自己不是银行，Treasury 的支票账户由 Fifth Third Bank 提供；报道转述的产品页称，符合条件的美元资金经 Fifth Third 享受最高 25 万美元的 FDIC 保险，审批流转会把每笔交易送到对应的审批人，「不论由人还是智能体发起」。报道把这次发布放在同一周的另一件事旁边：10 月 20 日 Visa、BILL 与 Billtrust 宣布智能体在供应商门户里替买方付已批准的发票（我们此前写过这件事）。

为什么额度比工具更要紧

分析推断（依据：上述两份文档的权限说明与发布稿的上线时间表）：Treasury 这次开放的工具，本身不新，余额、转账、付款早就有 API；新的是这些动作被放进了人每天开着的对话窗口。工具一多，真正决定风险的是「智能体最多能付多少、付给谁」。在限额上线之前，企业能调的是哪些工具可写、哪些账户可见、动钱要不要人批，却还不能设定「每天最多付多少、只付给哪些已登记的收款人」这样的规则。

对照很清楚。Stripe 给个人消费者的智能体钱包，文档里已经给每个用户设了单笔、每日和三十天的额度（见我们写过的智能体代购那篇）；企业账户这边，余额更大、收款人更多，额度反而排在后面。分析推断（依据同上）：这意味着现阶段一家公司要么接受逐笔批准，把智能体当成「付款单起草员」，要么在权限设置里放宽批准，把账户的安全押在模型不出错和不被注入上。前一种安全但省不了多少事，后一种省事但没有兜底。

最强反方

最有力的反驳是：对 Stripe 瞄准的一人公司和极小团队，逐笔批准恰恰是合适的形态，而不是缺陷。Stan 这样的创始人每天本来就要看账，智能体替他汇总、把付款单填好，他只点一次批准，省下的是切换系统和填表的时间，这已经是实打实的效率；限额反而会让人放松核对。何况 Stripe 写明限额几周内就上线，拿预览版的缺口下判断，可能过不了一个月就过时。

我们在第一点上让步：对一两个人的公司，逐笔批准不是负担，Stripe 把默认值设成「动钱就要人批」也是对的。但我们仍坚持论点的核心：这次开放的「付款权」在今天的实际含义是「起草权加一键确认」，判断它值不值，要看限额上线后能不能按金额和收款人细分、能不能与智能体密钥一起生效。如果几周后上线的限额做到了这两点，我们会改口说护栏到位了。

我们不知道什么

• 用智能体 API 密钥（而不是本人 OAuth 会话）接入时，付款是否同样要逐笔人工确认；MCP 文档关于确认的那一节只写了「用你的用户凭证连接」的情形。
• 「未来几周」上线的花费限额，能否按单笔、按天、按收款人分别设定，是否在智能体侧绕不过去。
• 公开预览期间有多少企业接入、实际发生了多少笔由智能体发起的付款；发布稿与文档都没有给出数字。
• 一笔付款如果是智能体在提示注入下发起、又被人误批，责任和追回怎么处理，文档没有写。

接下来看什么

一看花费限额上线时的文档，限额的粒度和是否适用于智能体密钥；二看 Stripe 有没有公布智能体发起付款的笔数或金额；三看 Kubrio 这类点名客户，什么时候从「智能体读数」走到「智能体付款」，以及批准是否仍是逐笔。