Vercel Connect 能给每个 agent 单开一张受限 Stripe 密钥，轮换不用重新部署

大多数接了收款的小产品，Stripe 那边都是一把默认 secret key 走天下——它有账户的完整权限，被塞进环境变量，跑在每一个进程里，包括你让 agent 帮你写的那段脚本。

这次改的是什么

Vercel Connect 现在能为每个 agent 或任务单独创建一张 Stripe 受限密钥。创建连接器时连接方法选 Managed API Key，勾权限，绑到项目上：

vercel connect create stripe --connection-method managed-api-key --name acme-stripe
vercel connect attach stripe/acme-stripe --project my-app --environment production

运行时用连接器的 UID 取这张受限密钥：

import Stripe from 'stripe';
import { getToken } from '@vercel/connect';

const key = await getToken('stripe/acme-stripe', { subject: { type: 'app' } });
const stripe = new Stripe(key);
const customers = await stripe.customers.list({ limit: 10 });

官方给的两个例子很到位：日收入报表 agent 只给 charges 的只读权限，开户 agent 只给 customers 的写权限。

三个容易被忽略的细节

没有密钥需要你粘。 密钥由 Vercel 在你的 Stripe 账户里创建并保管，代码里拿到的只是运行时 token。
轮换不用重新部署。 在连接器设置里换，旧密钥在切换期间还能用最多 24 小时——这个宽限期是轮换能不能真正落地的关键，很多团队不敢换密钥就是因为怕一刀切断线。
MCP 与自带密钥两种方式不变。 你原来怎么用还怎么用，这是多了一个选项。

多少钱：Vercel Connect 与 Stripe 连接器本身的能力，官方这条 changelog 没提额外收费；Stripe 那边的交易费率照旧。真正的成本是你要不要把现有「一把主密钥」的写法拆开重写一遍。

不做会怎样

这不是「迟早要还的技术债」那类空话，它有很具体的爆点：

agent 读了你的环境变量，把主密钥写进日志、写进它生成的样例代码、或者发给它调用的那个模型。
你雇的临时外包拿到仓库权限，等于拿到整个收款账户。
出事之后你不知道该换什么——因为一把密钥在跑所有东西，换掉等于全站停机，于是你选择不换。

泼冷水

只解决 Vercel 上的那一半。 你的 Stripe 密钥如果还同时躺在 n8n、GitHub Actions、本地 .env 里，这张 per-agent 密钥挡不住那些地方漏。先盘一遍密钥到底有几份副本，再决定值不值得迁移。
权限勾错了跟没拆一样。 受限密钥的价值全在勾得准。如果图省事给每个 agent 都勾全量，你只是多套了一层壳。
24 小时宽限期是双刃剑。 它让轮换无痛，但也意味着旧密钥泄露后有整整一天的可用窗口。真出事要在 Stripe 后台直接吊销，别指望等它过期。
绑在 Vercel 上。 这套托管能力的前提是你的部署在 Vercel。哪天迁走，这套机制跟着失效，得自己接回来。
「每个 agent 一张」会带来密钥数量膨胀。 5 个 agent 是清爽，50 个就是另一份需要治理的清单了。命名规则和定期清理要提前想好，别等到对不上账。

具体建议

先数一遍你的 Stripe 密钥现在有几个副本、分布在哪些地方（环境变量、CI、自动化工具、外包手里）。数量本身就是风险评分。
从只读的那个 agent 开始切——日收入报表、对账、看板这类。只读权限即使配错也捅不出大篓子。
给每张密钥写清楚「谁用、干什么、什么时候建的」。等你要排查一笔异常调用时，这份记录比日志有用。
现在就试一次轮换，确认 24 小时宽限期内的行为符合预期。没演练过的轮换流程等于没有。
别急着全量迁移。先把「有 agent 在碰 Stripe」的那一两条链路换掉，剩下的一次性一把梭的收益没那么大。

原文：https://vercel.com/changelog/vercel-connect-adds-managed-stripe-api-keys