Vercel Tokens Security Guide: Access Tokens, Environment Variables and OIDC

A Vercel team holds two kinds of high-value machine credentials: the access tokens that control the platform, and the third-party secrets stored as environment variables that every deployment can read. A full-account token can deploy, change settings and read configuration across every team its owner belongs to, while environment variables routinely hold database URLs, payment keys and LLM API keys. Vercel now offers project-scoped tokens, write-only Secret variables and OIDC federation that removes many stored cloud credentials altogether. This guide explains how identity and access work on Vercel, how to scope and govern each credential type, what to log and a hardening baseline. It is written for platform engineers, application security teams and developers who run production workloads on Vercel.

Key takeaways

• Scope every access token to a project where you can. Vercel tokens can be Full Account, Team or Project scoped; a project-scoped token is denied any request outside its project and cannot mint new tokens.
• Store credentials as Secret, not Config. Secret environment variables are write-only after saving and redacted from build logs, while Config values stay readable to members with access.
• Replace stored cloud keys with OIDC federation. Vercel issues short-lived signed tokens per build and function that AWS, Google Cloud and Azure can exchange for temporary credentials, so no long-lived cloud key needs to sit in an environment variable.
• Bind trust to the subject claim. Cloud trust policies should match the sub claim owner:[TEAM]:project:[PROJECT]:environment:production, not just the issuer, or any project in the team can assume production roles.
• Several URLs and headers act as bearer secrets. Deploy hook URLs and Protection Bypass for Automation secrets grant deploy or access rights to whoever holds them and need the same handling as tokens.

How identity and access work in Vercel

Vercel separates human access (team members and their roles), programmatic access (access tokens and integration credentials) and workload identity (OIDC tokens issued to builds and functions). Each has its own controls.

• Tokens act as their creator: access tokens authenticate requests to the REST API and CLI on the user's behalf, carry that user's role and are shown only once (personal access tokens begin with vcp_). When the user leaves, their tokens become orphaned risk unless they are deleted.
• Team enforcement applies to token creation: some teams require two-factor authentication or SAML before a member can create tokens scoped to them.
• Environment variables are encrypted at rest: they are set at team level (shared across linked projects) or project level, targeted to Production, Preview (optionally per Git branch), Development or custom environments, and apply only to new deployments.

Admin roles and privileged access

Team and project roles decide who can create tokens that act with their permissions, who can read and change production variables, and who can deploy to production.

• Permission groups widen roles: Environment Variable Manager, Full Production Deployment and Connector Manager can be added to lower roles. Review them as privileged grants.
• Keep Owners few but not one: Vercel recommends at least two Owners for continuity; more than a handful makes token and policy governance hard.
• Enforce SAML: Owners can switch on Require Team Members to login with SAML under Security & Privacy, so no team information is reachable without an identity provider session. SAML sessions last 24 hours by default, adjustable from one to 30 days with session_lifetime. Directory Sync (Enterprise) automates joiner and leaver changes; without it, removals are manual.

See the SaaS API Token Security Guide for the general model of user-bound tokens.

Integrations, API tokens and service accounts

Access tokens for CI and automation

• Pick the narrowest scope: a CI job that deploys one project needs a project-scoped token. Team- and project-scoped tokens also remove the need for teamId on API calls, which reduces the chance of a script acting on the wrong team.
• Always set an expiry: expiration is chosen at creation. Match it to a rotation cycle you will actually run, and record the owner and purpose in the token name. Package registry tokens used by the same builds need the same discipline; see the Artifactory Tokens Security Guide.
• Do not use personal tokens for shared pipelines: a token created by an engineer carries that engineer's role and dies, or lingers, with their account. Use a dedicated automation account with a minimal role, governed like any service account.
• Prefer Git integration over CLI tokens: deployments triggered by the Git integration need no token in CI at all. Where a pipeline must run vercel deploy, store the token in the CI system's secret store. See the CI/CD Pipeline Identity Security Guide.

Environment variables

• Secret versus Config: choose Secret for passwords, API keys and tokens. Secret values are write-only after saving, cannot be converted back to Config in place, and can now be used in Development as well as Preview and Production. Legacy Sensitive variables are treated as Secret automatically.
• Build log redaction: Secret values of 32 characters or longer are replaced with [REDACTED] in build logs, and VERCEL_AUTOMATION_BYPASS_SECRET and VERCEL_OIDC_TOKEN are always redacted. Shorter secrets are not, so do not rely on redaction alone.
• Separate production values: the Separate Production Secret Values team policy (Require Separate Values, Owner only) forces each Secret to use a different value in Production than in Preview, Development and custom environments. It replaces the deprecated Enforce Sensitive Environment Variables policy.
• Never prefix secrets with NEXT_PUBLIC_: in Next.js that prefix inlines the value into the JavaScript bundle at build time, where every visitor can read it. See the React and Next.js Security Guide.
• Integration-created variables: variables added by Marketplace integrations cannot be switched to Secret from the list. Vercel's documented route is to disconnect, rotate the provider secrets, reconnect without Development and with Sensitive enabled, then redeploy.
• Local copies: vercel env pull writes Development variables, including the development OIDC token, to a plain-text .env or .env.local file. Keep these files in .gitignore and keep production values out of the Development target.

OIDC federation to cloud providers

• How it works: Vercel signs a JWT for each build and function; the cloud provider validates it against Vercel's JWKS (discovered at https://oidc.vercel.com/[TEAM_SLUG]/.well-known/openid-configuration in team mode) and returns short-lived credentials. For AWS this is AssumeRoleWithWebIdentity, helped by @vercel/oidc-aws-credentials-provider; for Azure and others, getVercelOidcToken() from @vercel/oidc.
• Use the team issuer: Vercel recommends the Team issuer mode (https://oidc.vercel.com/[TEAM_SLUG]) over the global issuer, so a trust relationship cannot be satisfied by another team's tokens.
• Constrain on sub and aud: match sub exactly to one project and environment, and the default aud of https://vercel.com/[TEAM_SLUG] or a custom audience. Grant production cloud roles only to environment:production, and give preview and development their own lower-privilege roles. Claims such as project_id and owner_id are stable identifiers when the provider supports conditions on them.
• Plan for renames: renaming a team or project changes the token claims and can break, or unexpectedly widen, trust policies. Update policies before the rename.
• Do not cache the token: Vercel's helpers read the current token on every call; caching it outside the request breaks rotation.

See the Workload Identity Federation Guide and the AWS IAM Policies and Roles Guide.

Choosing a credential pattern

Logging and detection

The Activity Log (all plans) records team and project events and can be filtered with vercel activity. Enterprise Owners also get Audit Logs with CSV export and external storage through Vercel Drains.

On the cloud side, log the role assumptions made with Vercel OIDC tokens (for example AWS CloudTrail AssumeRoleWithWebIdentity events) and alert when a non-production subject assumes a production role.

Metrics that show it is working

• Token scope mix: share of active tokens that are project-scoped, and the number of full-account tokens used by automation, target zero.
• Token hygiene: tokens without expiry or without a named owner, target zero.
• Secret coverage: percentage of credential-bearing variables stored as Secret.
• Static cloud keys: number of AWS, Google Cloud or Azure keys stored in Vercel variables, falling as OIDC replaces them.
• Rotation time: hours from a rotation trigger to the old credential being invalidated across all redeployed projects.

Hardening baseline

1. Inventory: export the list of tokens per member, team and project variables with their type and targets, deploy hooks, bypass secrets and integrations.
2. Lock down sign-in: enforce SAML (or at least two-factor enforcement), so token creation also requires a strong session. Remove leavers and delete their tokens.
3. Reissue tokens narrowly: replace full-account automation tokens with project-scoped tokens with expiry, owned by a dedicated automation identity. Revoke the old ones after the pipeline is proven.
4. Convert credentials to Secret: recreate credential-bearing Config variables as Secret, enable Require Separate Values, and move production secrets out of the Development target.
5. Adopt OIDC: set the Team issuer, create cloud trust policies bound to project and environment, deploy, verify, then delete the static cloud keys.
6. Review bearer URLs: rename, re-create or revoke deploy hooks and bypass secrets, one bypass secret per tool, sent as the x-vercel-protection-bypass header.
7. Rotate in the safe order: generate the new credential at the provider, update the Vercel variable, redeploy every project linked to it (check Link to Projects for team-level variables), verify, then invalidate the old value. Old deployments keep old values, so redeploy any you still serve.
8. Monitor: alert on the Activity Log events above and export them where your plan allows.

Small team or large estate

• Small teams: project-scoped tokens with expiry, Secret type for every credential, Git integration for deploys and two-factor enforcement deliver most of the benefit without Enterprise features.
• Enterprise: Contributor plus project roles to separate production variable access, SAML enforcement with Directory Sync, Audit Logs exported to the SIEM, and OIDC federation as the default for every cloud dependency.

Common misconfigurations

• Credentials stored as Config or legacy non-sensitive variables: in the Vercel Context.ai OAuth Breach 2026, an attacker who reached Vercel's internal environment through a compromised employee Google Workspace account decrypted customers' non-sensitive variables; Vercel said it had no evidence sensitive variables were accessed.
• Full-account tokens in CI: one leaked token reaches every team the creator belongs to and can mint more tokens.
• OIDC trust on issuer only: a trust policy that checks aud but not sub lets any project or preview deployment in the team assume a production role.
• Secrets in NEXT_PUBLIC_ variables: shipped to every browser and cached in CDNs long after rotation.
• Bypass secrets in query strings: the query parameter form is meant for tools that cannot set headers; elsewhere it leaks the secret into access logs and third-party webhook settings.
• Rotation without redeploy: the variable is updated but running deployments still use the old value, so the old credential is never safely invalidated.

Framework mapping

Practitioner checklist

• Replace every full-account token used by automation with a project-scoped token with expiry and a named owner.
• Enforce SAML or two-factor authentication for the team and delete tokens of departed members.
• Store every credential as a Secret variable and enable Require Separate Values for production.
• Check that no secret uses a NEXT_PUBLIC_ prefix and that .env* files are ignored by Git.
• Move cloud access to OIDC federation with Team issuer mode and trust bound to sub per environment.
• Treat deploy hook URLs and bypass secrets as credentials: inventory, store in secret stores, revoke when exposed.
• Rotate in the documented order and redeploy every linked project before invalidating the old value.
• Alert on token creation, production variable reads and changes, and role updates in the Activity Log.

Standards and references

• Vercel: Access tokens
• Vercel: Config and Secret environment variables
• Vercel: OpenID Connect (OIDC) Federation
• Vercel: OIDC Federation Reference
• Vercel: Access Roles
• Vercel: Rotating environment variables
• Vercel: Using the Activity Log
• Next.js: How to use environment variables in Next.js

Related NHI Mgmt Group resources: Secrets Management Guide · Workload Identity Federation Guide · CI/CD Pipeline Identity Security Guide · Token Lifetime Policy Design Guide · Firebase Credentials Security Guide