Vercel Connect上线EMA：企业授权接管AI Agent访问权限

Vercel 的 Connect 功能正式进入公共测试阶段，新增了 Enterprise-Managed Authorization（EMA） 能力。这个更新的核心思路很明确：让企业管理员通过身份提供商集中控制应用和 AI Agent 能访问哪些服务，用户登录后无需为每个服务单独授权。

EMA 解决了什么问题

在传统的 OAuth 流程中，用户需要为每一个第三方服务单独点击"同意授权"。当企业内部应用需要串联 Slack、Google Workspace、GitHub 等多个服务时，这种逐项授权的模式既繁琐又难以审计。

EMA 把授权决策从终端用户上移到管理员层面。管理员在身份提供商（IdP）中统一配置哪些服务可以访问、谁可以访问，用户通过企业账号登录后，应用自动获取对应权限，整个过程不再出现独立的授权弹窗。

这对部署 AI Agent 的团队尤其有价值——当一个 Agent 需要代表用户操作多个 SaaS 工具时，权限链路的透明度和可管理性直接决定了它能否通过企业的安全审查。

OAuth（Open Authorization）是当前互联网上最主流的第三方授权协议，它允许用户在不向应用暴露密码的前提下，授权应用访问其在另一服务上的资源。典型流程中，应用会引导用户跳转到服务方页面，用户点击"同意授权"后，服务方发放一个访问令牌（Access Token）给应用。这个令牌带有一定的权限范围（scope），并在有效期后失效。OAuth 的设计以"用户"为授权主体，因此当企业内部有几十上百个 SaaS 工具需要打通时，每个用户都要重复授权动作，管理员也难以从组织层面统一查看和撤销这些授权，这正是 EMA 想要上移决策权、集中管控的根本原因。

三层机制拆解

Vercel 官方把 EMA 的工作方式分为三个层面：

管理员管控访问：管理员通过身份提供商授予或撤销对受支持服务的访问权限。授权入口收敛到 IdP，IT 团队不需要在多个平台之间切换。

企业账号登录：用户使用 Okta 等兼容的身份提供商登录应用。这意味着权限的根基是企业身份体系，而不是个人账号的零散授权。

作用域令牌（Scoped Tokens）：应用按需请求所需的 scope，Connect 负责令牌交换、缓存和续期。访问范围被限制在已批准的 scope 和用户在目标服务中已有的权限之内，不会越权。

这个设计的巧妙之处在于"双重边界"：管理员设定应用能请求什么，目标服务自身的用户权限则决定实际能做什么。两个约束同时生效，避免了管理员授权覆盖用户权限的风险。

身份提供商（Identity Provider，IdP）是企业身份与访问管理（IAM）体系的核心组件，负责存储用户目录、执行登录认证、并作为权限裁定的权威来源。Okta、Microsoft Entra ID、Google Workspace 等都是常见 IdP。当企业应用接入 IdP 后，用户登录不再由应用自己校验密码，而是走 SAML 或 OpenID Connect 标准，由 IdP 颁发身份断言。EMA 之所以能把授权收敛到 IdP，前提正是企业已经用 IdP 统一了员工身份。

作用域令牌（Scoped Tokens）中的 scope 是 OAuth 规范里的权限粒度单位，例如 channels:read 表示只读频道列表、chat:write 表示发送消息。应用在请求令牌时必须声明所需 scope，服务方在发放时进行裁剪。Connect 在此基础上做了令牌交换（Token Exchange）和缓存续期，使应用不必自己处理刷新令牌（Refresh Token）的轮转和过期逻辑，也降低了令牌泄露的风险面。

代码层面的接入方式

对于使用 Vercel Passport 的应用，接入 EMA 后的令牌获取逻辑相当简洁。开发者通过 getToken 方法，以已登录用户的身份请求 Slack MCP 服务器的令牌：

import 'server-only';
import { getToken } from '@vercel/connect';
import { requireIdentity } from '@vercel/passport';

export async function getResourceToken(scopes: string[]) {
  const identity = await requireIdentity();
  return getToken('oauth/resource', {
    subject: identity,
    scopes
  });
}

requireIdentity() 拿到当前登录用户的身份信息，getToken 则以该身份为主体发起令牌请求。令牌的交换、缓存和续期由 Connect 内部处理，开发者不需要手动管理 OAuth 的刷新逻辑。

Cross-App Access 与 MCP 授权

Connect 同时支持 Cross-App Access（XAA），并将这项能力延伸到 MCP 授权场景中。MCP（Model Context Protocol）正在成为 AI Agent 调用外部工具的标准协议，而 XAA 让 Agent 在跨应用调用时能够复用企业已经配置好的授权关系。

结合 EMA 来看，这意味着企业可以用同一套身份和权限体系，同时管理人类用户和 AI Agent 对内部工具的访问。对已经在跑 Agent 工作流的团队来说，这是一个值得关注的信号：Agent 权限管理正在从"每个团队自己造轮子"走向"由平台和 IdP 统一提供"。

MCP（Model Context Protocol）是由 Anthropic 提出并逐渐被业界采纳的开放协议，用于让 AI 模型或 Agent 以标准化方式连接到外部数据源和工具。一个 MCP 服务器会把某个服务（如 Slack、GitHub、数据库）的能力暴露成一组可被模型调用的工具，Agent 通过 MCP 客户端与之通信。由于 Agent 常需要跨多个 MCP 服务器完成任务，授权链路就会涉及多个服务方，这使得 MCP 的授权问题天然适合由企业统一身份体系来托管，而非在每个 Agent 内部各自维护一套凭证。Cross-App Access 正是让这种跨应用、跨服务的授权关系可以复用同一套 IdP 配置。

谁应该关注这个更新

如果你的团队正在做以下事情，EMA 的公共测试值得跟进：

• 在企业内部部署需要访问多个 SaaS 服务的 AI Agent
• 使用 Okta 等 IdP 管理员工身份，希望把服务授权也纳入同一体系
• 通过 Vercel 托管应用，并且需要处理 OAuth 令牌的生命周期管理

Vercel 提供了 EMA 的配置指南，涵盖身份提供商和服务的设置流程。当前功能处于公共测试阶段，正式 GA 前可能会有接口调整。