How a Third-Party AI Tool Led to Vercel's Environment Variable Exposure

What happened in the incident

Vercel said an attacker got into a third-party AI tool used by one of its employees, then used that access to take over the employee's Google Workspace account and Vercel account. From there, the attacker moved into Vercel systems and enumerated non-sensitive environment variables.

The interesting part is the path, not any single control failure. This was a chain that crossed identity boundaries:

1. a third-party AI tool was compromised,
2. the employee's Google Workspace account was accessed,
3. the employee's Vercel account was reached,
4. the attacker pivoted into Vercel,
5. environment variables were read and decrypted where possible.

That is the pattern I expect when one trusted integration has too much reach. The first system does not need to be production. It only needs a route into it.

How the compromise moved from a third-party tool into Vercel

The employee account takeover path

Vercel's bulletin says the origin was a compromise of Context.ai, a third-party AI tool used by a Vercel employee. The attacker used that access to reach the employee's Google Workspace account, which then led to the employee's Vercel account.

That sequence matters because many teams still talk about “the app” as if the app were separate from identity. In practice, identity is the app when the app is a cloud console, Google Workspace, or an admin panel. If an OAuth app can reach mail, profile data, or session-linked state, it can become the first step into your internal platform.

Why environment variable enumeration mattered

Once inside Vercel, the attacker moved through systems to enumerate and decrypt non-sensitive environment variables. Vercel called out values that decrypt to plaintext, which can include API keys, tokens, database credentials, and signing keys if teams stored them that way.

That is not a small read-only issue. Environment variables often hold the keys to production systems. Even when a variable is labeled “non-sensitive,” the secret it points to may still be usable somewhere else.

What Vercel confirmed and what stayed unproven

Non-sensitive environment variables and why they still matter

Vercel said the initial impact was a limited subset of customers whose non-sensitive environment variables stored on Vercel were compromised. It later expanded the review and found a small number of additional accounts affected by the same incident, plus a separate set of accounts with signs of compromise that did not appear to originate on Vercel systems.

For defenders, the lesson is simple: “non-sensitive” in a platform UI is not the same as “safe if exposed.” If the value can help reach production, sign requests, reset sessions, or query infrastructure, treat it as exposed.

No evidence of npm package tampering

Vercel also said that, with GitHub, Microsoft, npm, and Socket, it confirmed no npm packages published by Vercel were compromised. That closes off one common supply-chain fear, at least for this incident.

So the public evidence points away from package tampering and toward identity compromise plus secret exposure. That distinction matters when you build your incident response plan.

What teams should check in their own Vercel accounts

Audit activity logs and recent deployments

Start with the Vercel activity log and recent deployments. Look for:

• unfamiliar login or account events
• environment variable read activity
• unexpected team changes
• deployments you do not recognize
• changes to deployment protection settings

If you find anything odd, do not just delete the project and move on. Preserve the timeline first.

Rotate secrets before deleting projects or accounts

Vercel explicitly warned that deleting a project or account is not enough to remove risk. If a secret has already been read, deleting the container does not put the secret back.

Rotate before deletion, not after. If the secret touched production, assume it is reusable somewhere else until proven otherwise.

Treat non-sensitive variables as potentially exposed

This is the uncomfortable part: review and rotate variables that were not marked sensitive. A lot of teams use those slots for values they mentally treat as “not exactly secret.” In practice, many of those values still unlock production behavior.

A useful rule is to classify by blast radius, not by label.

Practical hardening steps that reduce the blast radius

MFA, passkeys, and authenticator apps

Vercel recommended multi-factor authentication, and that is the right call. If an attacker gets one upstream account, MFA can stop the pivot. I prefer passkeys where possible, then authenticator apps, then other strong second factors.

If your account depends on password-only access to Google Workspace, Vercel, or your identity provider, you are one token theft away from a bigger incident.

Sensitive environment variables and deployment protection

Use Vercel's sensitive environment variables feature so secret values are protected from being read in the future. Also keep Deployment Protection at Standard or higher, and rotate any Deployment Protection tokens.

That does not make secrets invulnerable, but it does reduce how far a single account compromise can move.

Token rotation and account review workflow

Make token rotation a workflow, not an emergency exercise. I usually want a simple playbook:

1. identify the exposed secret,
2. map every system that trusts it,
3. rotate the secret,
4. verify the old credential no longer works,
5. review logs for use before and after the suspected exposure.

If you cannot do step 2, that is already a problem.

How to respond if a third-party AI tool is involved

Review OAuth app access in Google Workspace

Vercel published an OAuth app identifier for the compromised third-party AI tool so Google Workspace admins and account owners can check for it. If you rely on Workspace, review granted apps immediately and remove anything you do not actively need.

The useful check is not just “is this app installed?” It is “what scopes does it have, and what internal state can it touch?”

Look for signs of lateral movement, not just the first account

Do not stop at the first compromised account. Look for mailbox forwarding changes, new sessions, unusual device logins, admin console activity, and token creation in adjacent systems.

A clean initial login record does not mean the attacker stayed there. In incidents like this, the real damage usually happens one hop later.

Conclusion

This incident is a clear example of why third-party AI tooling deserves the same scrutiny as any other privileged integration. The attacker did not need a direct path into production at the start. They only needed one account with enough trust to keep moving.

If you use Vercel, audit logs and rotate secrets now. If you run Google Workspace, review OAuth apps now. And if you store environment variables anywhere, assume that anything useful to an attacker should be treated like a secret, even when the platform says otherwise.