Vercel Passport is now generally available for Enterprise customers. It protects deployments with an organization’s identity provider, then forwards a signed identity token to the deployment so application code can reason about the authenticated visitor.
The mechanics are important. Passport works with Okta, Microsoft Entra ID, or any OIDC provider. Vercel strips client-supplied x-vercel-oidc-passport-token headers and injects a verified token after Passport validates the session. The getIdentity() helper in @vercel/passport then reads the verified visitor identity from the Vercel request context.
The package install path is simple:
pnpm add @vercel/passportPassport can also carry additional provider claims, including group membership, when the provider and Vercel Connect application are configured for those scopes. For downstream services, verifyIdentity() checks the forwarded token’s signature, Passport claims, project, and environment. Non-JavaScript services can verify the token as a standard JWT using the published JWKS.
Operationally, Passport records successful access as passport-access-granted events in both Activity Log and Audit Logs. For automation, Vercel supports the existing protection bypass header or query parameter, and Trusted Sources can use short-lived OIDC tokens instead of a shared secret. Custom environments such as staging and QA can also be protected.
New Runtime Read
Identity is becoming part of the deployment boundary, not just application middleware.
That matters for agent-facing systems because the same protected surface needs to handle humans, webhooks, CI runs, and external services. The useful distinction is not “browser traffic versus automation.” It is verified identity, verified automation, and explicit bypass paths with auditable evidence.