The leaked variables were the readable ones — what developers should do after the Vercel security incident

Vercel says it contacted the affected customers directly and recommended an immediate rotation of credentials. Its April 22 update adds that an expanded review found a small number of additional compromised accounts, which were also notified. First confirm which addresses receive Vercel's messages (team owners, billing contacts). But Vercel presents the steps below as best practices you should follow regardless. Not hearing from Vercel is not a reason to do nothing.

Vercel asks you to treat environment variables that were not marked sensitive — API keys, tokens, database credentials, signing keys and so on — as potentially exposed and to rotate them as a priority. In the dashboard's environment variable table, each variable carries a Config (readable) or Secret (write-only) label. Secrets sitting under a Config label are today's work list. Check team-level shared variables as well as project variables.

Vercel's documentation gives this order for rotating without downtime: (1) in the third-party service (database or API provider), issue a new credential and keep the old one for now; (2) update the Vercel environment variable; (3) redeploy (for a team-level variable, every project that uses it); (4) after verifying it works, invalidate the old credential. Editing the variable alone leaves running deployments on the old value, and only step 4 makes the leaked value useless.

Save the new values you created as Secrets (write-only). In its bulletin, Vercel says the sensitive feature protects secret values from being read in the future. As of September 30, 2026, the documentation says a Secret's value is hidden after saving and is changed by providing a new value, and that Secrets, once limited to Production and Preview, are now allowed in Development too. See the comparison later in this article for what belongs where.

Vercel states plainly that deleting your projects or account is not sufficient to eliminate risk, because a leaked secret stays valid at the database or API it unlocks. If you are cleaning up old projects or leaving Vercel, invalidate the keys at the provider first, then delete.

Vercel recommends reviewing the activity log for your account and environments (in the dashboard or via the CLI) for suspicious activity, and investigating recent deployments for anything unexpected or suspicious-looking. It says to delete any deployment in question. Use the same log to look for signs that someone viewed environment variable values.

Vercel recommends setting Deployment Protection to Standard at a minimum and, if you use Deployment Protection tokens, rotating them. Vercel's documentation describes Standard as the recommended option for most projects: it protects preview and per-deployment URLs, while current production URLs stay public.

Vercel recommends multi-factor authentication with an authenticator app or a passkey. Why these beat SMS is covered in Choosing multi-factor authentication.

Vercel published the identifier of the AI tool's Google Workspace OAuth app and recommends that Google Workspace administrators and Google account owners check for use of that app immediately. According to Vercel, that OAuth app was the subject of a broader compromise, potentially affecting hundreds of users across many organizations — so organizations that do not use Vercel may be in scope too. Get the identifier from Vercel's bulletin, linked in the sources below.

Google's admin help page "Control which apps access Google Workspace data" says the Admin console shows which apps have accessed organization data, which users authorized them, and the OAuth scopes each app requested. Pull the list and flag apps nobody can explain and apps with scopes that can read all of Drive or Gmail.

The same page says each app can be set to Trusted, Limited, Specific Google data, or Blocked. Restrict the apps you decide to keep to only the data they need, and block the rest.

You can set an organization policy for whether users may authorize third-party apps the admin has not configured. Allowing only apps that request basic sign-in information puts an admin review in front of every new AI tool. For Gmail and Drive you can also restrict high-risk scopes individually, such as sending email or deleting files.

This is this site's suggestion. In this incident, the Google account an AI tool was connected to became the door into a Vercel account. People with admin rights on production or hosting should consider not connecting trial AI tools to the account they use to sign in there. If a tool must be connected, use a separate account with narrowed access to business data.