Vercel Connect 正式上线，用运行时短期令牌取代长期凭证

有价值的 agent 总会触达代码库之外的系统。它会向 Slack 发消息、创建 pull request、查询 Snowflake，或调用内部 API。正是这种触达让它有价值，而风险也恰恰在这里——多年来，要授予这种能力，就得配置一个长期有效的 token，然后祈祷它永远不泄露。

Vercel Connect 用代码在运行时请求的 token 取代长期 token，这些 token 按任务限定作用域，并自行过期。

在公开测试期间，我们把生态扩展到了 100 多个连接器，统一了它们的工作方式，并增加了团队在生产环境中所需的治理能力。

今天，Vercel Connect 正式可用。

保险库解决不了长期 token 的问题

管理凭证本身已经成了一项工作负载。团队编写轮换脚本、在各环境之间复制密钥、在用户之间共享 token。把 token 放进保险库让它更难被窃取，但一旦被窃取，危险程度丝毫不减。它永不过期，也没有任何保险库能限制泄露凭证能做什么。

Agent 让问题更加严重：它们以更大的自主性、更频繁地触达更多系统。然而，用来约束密钥的工具并没有改变。

使用 Vercel Connect，你的应用从不存储凭证。它请求一个凭证：

你为 Slack、GitHub、Snowflake、Shopify 或你自己的 OAuth 服务等提供商注册一次连接器

你把它附加到需要它的项目和环境中

你的代码在运行时请求 token，并自动刷新

你的应用没有可被意外提交的提供商密钥

vercel connect create slack --name acme-slack 创建一个名为 acme-slack 的 Slack 连接器

import { getToken } from '@vercel/connect'; const token = await getToken('slack/acme-slack', { subject: { type: 'app' }, }); 请求一个应用级 Slack token

请求 token 不需要另一个密钥。Vercel 上的每次部署都带有 OIDC 身份，SDK 用它来证明请求者是谁。

当访问变成一次请求，会发生什么变化

区别体现在凭证的属性上：

过去在工作完成后仍长期留在环境中的凭证，现在会自行过期。没有任何东西留给攻击者去发现。

作用域按请求划分。agent 的某一步可能读取一个仓库，下一步创建一个 issue，每一步只请求它所需的那部分权限。

token 能精细到什么程度取决于服务，GitHub 是最清晰的例子。请求可以把 token 限制到单个仓库并只给只读权限，而不是信任一个组织范围的长期授权。

开源的 GitHub Tools SDK 把这一点付诸实践。选择一个像 code-review 这样的预设，它就会只铸出带有必需作用域的 token。

身份也是按请求划分的。token 默认以应用身份行事，但传入一个具名用户作为 subject，token 就会代表该用户行事，作用域限定为该用户在一次性同意流程中授权的范围。

为你已在使用的服务提供的连接器

Vercel Connect 现在自带 100 多个预设连接器，面向开发工具和 SaaS 提供商，如 Notion、Shopify 和 Workday，以及针对 Slack、GitHub、Linear、Salesforce 等的托管连接器。

你自己的服务通过自定义 OAuth 和 API Key 认证遵循同样的模式，任何支持 OAuth 的 MCP server 都可以作为连接器。

查找和创建它们也更快了。在 Vercel 网站上浏览完整目录，用更少的步骤创建连接器，并从 dashboard、CLI 或 API 管理一切。

随团队规模扩展的治理能力

采用 Vercel Connect 的团队需要的不仅仅是限定作用域的 token。他们需要控制谁管理连接器，并追踪访问是如何被使用的。

细粒度 RBAC 控制谁可以创建和管理连接器

审计日志记录授权和连接器活动

token 和 trigger 可观测性展示跨项目的使用情况

再加上按环境附加和一键撤销，访问变成了你可以检查并证明的东西。

当审计员询问谁在何时拥有对某个系统的访问权时，答案是对审计日志的一次查询，而不是跨项目和 Slack 线程的调查。

无论你的 agent 在哪里运行

Vercel Connect 在你和你的用户所在的任何地方都可用：

支持 Custom Environments，因此 qa 环境会拥有自己的连接器，与 production、preview 和 development 并列

eve 开箱即支持 Connect，按 agent 声明连接

Chat SDK 支持把同样的模式带到对话式应用中

在 v0 中构建互联应用

在 v0 中构建的应用和 agent 使用同样的模式。

告诉 v0 你的应用需要哪个服务，它就会在构建过程中设置好连接器。Slack、GitHub 和其他托管连接器在提供商一侧无需任何配置，而且由于 token 是在运行时铸出的，生成的应用没有需要保管的密钥。

KERNEL 团队就是这样交付了一个语音驱动的浏览器 agent：

事件流入，同样无需密钥

请求 token 只是图景的一半。你的 agent 还需要获知事件。

Triggers 处理这一点，而不会把密钥重新放回你的应用。当用户在 Slack 中发帖时，提供商会把事件发送给 Vercel Connect。它在服务端验证签名，用 OIDC 身份重新认证事件，并将其转发到你的项目。即使启用了 Deployment Protection，转发的事件也能到达。

你的应用没有可用于行动的 bot token，也没有用于验证 webhook 的签名密钥，但整个闭环仍然运转。

Moonpig Group 在生产环境中基于这个闭环运行其内部法律 agent：

围绕一次调用构建

一切之下是 Vercel Connect SDK 中的 getToken。

无论你的 agent 是基于 eve 还是 AI SDK 构建、作为 Vercel Workflows 中的后台任务运行，还是你自己编写的循环，它都以同样的方式请求凭证。

围绕这次调用，适配器负责处理接线：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）