Vercel Connect Launches EMA: Enterprise Authorization Takes Over AI Agent Access Control

Vercel's Connect feature has officially entered public beta, adding a new Enterprise-Managed Authorization (EMA) capability. The core idea behind this update is straightforward: let enterprise administrators centrally control which services applications and AI Agents can access through their identity provider, so users don't need to authorize each service individually after logging in.

What Problem Does EMA Solve?

In traditional OAuth flows, users need to click "approve authorization" separately for every third-party service. When internal enterprise applications need to connect Slack, Google Workspace, GitHub, and other services, this per-item authorization model is both cumbersome and difficult to audit.

EMA moves the authorization decision from the end user up to the administrator level. Administrators configure centrally in the identity provider (IdP) which services can be accessed and who can access them. After users log in with their enterprise account, applications automatically obtain the corresponding permissions, and no separate authorization pop-ups appear throughout the process.

This is especially valuable for teams deploying AI Agents — when an Agent needs to operate multiple SaaS tools on behalf of a user, the transparency and manageability of the permission chain directly determines whether it can pass enterprise security review.

OAuth (Open Authorization) is currently the most mainstream third-party authorization protocol on the internet. It allows users to authorize an application to access their resources on another service without exposing their password to that application. In a typical flow, the application redirects the user to the service provider's page, and after the user clicks "approve authorization," the service provider issues an access token to the application. This token carries a certain permission scope and expires after a validity period. OAuth is designed with the "user" as the authorization subject, so when an enterprise needs to connect dozens or hundreds of internal SaaS tools, each user has to repeat the authorization action, and administrators find it difficult to uniformly view and revoke these authorizations at the organizational level. This is precisely the fundamental reason EMA wants to move decision-making upward and centralize control.

Breaking Down the Three-Layer Mechanism

Vercel officially divides EMA's operation into three layers:

Administrator-Controlled Access: Administrators grant or revoke access to supported services through the identity provider. The authorization entry point converges into the IdP, so IT teams don't need to switch between multiple platforms.

Enterprise Account Login: Users log in to applications using a compatible identity provider such as Okta. This means the foundation of permissions is the enterprise identity system, rather than scattered authorizations from individual accounts.

Scoped Tokens: Applications request the scopes they need on demand, and Connect handles token exchange, caching, and renewal. Access scope is limited to approved scopes and the permissions the user already has in the target service, preventing privilege escalation.

The clever part of this design is its "dual boundary": administrators define what an application can request, while the target service's own user permissions determine what it can actually do. Both constraints take effect simultaneously, avoiding the risk of administrator authorization overriding user permissions.

Identity Provider (IdP) is a core component of an enterprise's Identity and Access Management (IAM) system. It stores the user directory, performs login authentication, and serves as the authoritative source for permission decisions. Okta, Microsoft Entra ID, and Google Workspace are all common IdPs. Once an enterprise application integrates with an IdP, the application no longer verifies passwords itself during login; instead, it uses SAML or OpenID Connect standards, and the IdP issues identity assertions. The premise for EMA to converge authorization into the IdP is precisely that the enterprise has already unified employee identity through an IdP.

In Scoped Tokens, a scope is the unit of permission granularity in the OAuth specification. For example, channels:read means read-only access to the channel list, and chat:write means sending messages. Applications must declare the required scopes when requesting a token, and the service provider trims them when issuing it. On top of this, Connect performs token exchange and cache renewal, so applications don't have to handle refresh token rotation and expiration logic themselves, reducing the exposure surface for token leakage.

How to Integrate at the Code Level

For applications using Vercel Passport, the token acquisition logic after integrating EMA is quite concise. Developers use the getToken method to request a token for the Slack MCP server as the logged-in user:

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() retrieves the identity information of the currently logged-in user, and getToken initiates a token request with that identity as the subject. Token exchange, caching, and renewal are handled internally by Connect, so developers don't need to manually manage OAuth refresh logic.

Cross-App Access and MCP Authorization

Connect also supports Cross-App Access (XAA) and extends this capability into MCP authorization scenarios. MCP (Model Context Protocol) is becoming the standard protocol for AI Agents to call external tools, and XAA allows Agents to reuse authorization relationships already configured by the enterprise when making cross-application calls.

Combined with EMA, this means enterprises can use the same identity and permission system to manage both human users' and AI Agents' access to internal tools. For teams already running Agent workflows, this is a signal worth watching: Agent permission management is moving from "each team building its own solution" to "uniformly provided by platforms and IdPs."

MCP (Model Context Protocol) is an open protocol proposed by Anthropic and increasingly adopted by the industry. It allows AI models or Agents to connect to external data sources and tools in a standardized way. An MCP server exposes the capabilities of a service (such as Slack, GitHub, or a database) as a set of tools that can be called by a model, and Agents communicate with it through an MCP client. Because Agents often need to complete tasks across multiple MCP servers, the authorization chain involves multiple service providers, which makes MCP authorization naturally suited to being hosted by an enterprise's unified identity system rather than each Agent maintaining its own set of credentials. Cross-App Access is precisely what allows this cross-application, cross-service authorization relationship to reuse the same IdP configuration.

Who Should Pay Attention to This Update

If your team is doing any of the following, EMA's public beta is worth following:

• Deploying AI Agents internally that need to access multiple SaaS services
• Using an IdP such as Okta to manage employee identity and wanting service authorization to be part of the same system
• Hosting applications through Vercel and needing to handle OAuth token lifecycle management

Vercel provides an EMA configuration guide covering the setup process for identity providers and services. The feature is currently in public beta, and interfaces may change before general availability.

One-line Summary

Vercel Connect launches the public beta of enterprise-managed authorization EMA, letting administrators centrally control application and AI Agent service access through an IdP.

Paragraph Summary

Vercel announced that Connect has entered public beta and introduced the Enterprise-Managed Authorization (EMA) capability, aiming to move OAuth authorization decisions from end users up to enterprise administrators. Administrators configure centrally in an identity provider such as Okta which services can be accessed and by whom. After users log in, applications automatically obtain permissions, and per-service authorization pop-ups no longer appear. EMA consists of three layers: administrator-controlled access, enterprise account login, and scoped token exchange, caching, and renewal, constrained by both administrator scopes and the user's own service permissions. Connect also supports Cross-App Access and extends it to MCP authorization scenarios, enabling enterprises to use the same identity system to manage both human users' and AI Agents' access to external tools. Developers can integrate through Vercel Passport's getToken and requireIdentity. The feature is currently in public beta, and interfaces may change before GA.