The Vercel Breach and an Hour With Claude Code: AI for Defenders

I host cryptoflexllc.com and a game dev project on Vercel. On April 19, 2026, I read Juliet.sh's writeup of the Vercel breach over morning coffee. A precautionary notification from Vercel followed, and when I opened my dashboard the console had flagged nine environment variables with a "Need To Rotate" badge on each of them. Sixty minutes later, they were all rotated, the platform was hardened, and I had as much forensic confidence as a customer-side audit can give you that nothing had been used against me.

This is the story of how Claude Code made that possible, and why the breach chain that got here should worry anyone running production on a vendor platform.

The Hook Metric#

Nine credentials flagged. One hour to rotate and harden. Zero anomalies in the deployment, event, and token history I could pull.

That is the short version. The longer version starts several degrees of separation away from my laptop, and ends with a plan file I want everyone reading this to be able to mirror.

What a Fourth-Party Breach Actually Means#

Before we get to Claude Code, I need to explain the supply chain. Not because the breach is novel (it is not), but because the language around these events is terrible and business readers keep getting confused by it.

The attacker who potentially reached my Vercel env vars never touched my laptop. They traversed a chain of trust relationships to get from a compromised personal device to Vercel's internal tooling. Here is the chain as best as it has been reconstructed from public reporting:

1. A Context.ai employee's personal device picked up Lumma Stealer, a commodity infostealer, allegedly via a disguised Roblox auto-farm script. This is the kind of malware that sells on Telegram for $250 a month. No nation-state, no zero-day, just a family member clicking the wrong link.
2. The infostealer harvested the employee's saved credentials and browser session cookies, including their Context.ai Google Workspace login.
3. From that foothold, the attacker reached a Vercel employee's Workspace. The bridge was an OAuth grant, not a cookie replay: the Vercel employee had signed up for Context.ai's consumer AI suite using their enterprise Google account and granted "Allow All" scope. That OAuth token gave Context.ai (and whoever compromised Context.ai) broad read access into the Vercel employee's Workspace.
4. With that access, an attacker enumerated non-Sensitive-flagged environment variable values across a subset of customer projects between March 2026 and April 19, 2026.

How I learned about it was the quieter part of the story. Vercel reached out to me directly, out of an abundance of caution, and the console flagged nine of my environment variables for rotation. Whether any of my values were actually read is not confirmed. Vercel's own guidance said impacted customers would be contacted directly, and when I built the impact assessment on April 19 the evidence suggested I was likely not in the confirmed-impacted subset. I rotated anyway.

That is what supply chain exposure looks like in 2026. The attacker never touched my Mac. They were five trust-hops away, and nine of my production keys sat in the potentially-readable pool until I rotated them.

Click to enlarge

The Screenshot I Did Not Want To See#

Here is what greeted me when I opened my Vercel Environment Variables page after reading the Juliet.sh writeup and receiving the precautionary notice.

Click to enlarge

Nine of my thirteen environment variables, each flagged by Vercel as "Need To Rotate". The other four were not flagged because they are public identifiers (team ID, GA ID, project ID) or an email address. Vercel's own UI was telling me exactly what to do. The question was how fast I could do it, and how confident I could be after the fact that the flagged values had not been used against me.

Scoping the Blast Radius#

Before touching anything, I opened Claude Code with a single prompt: "Here is the breach disclosure. Read my cryptoflexllc repo and my Vercel account. Tell me what I have exposed and what I need to do."

What happened next is the first place the AI force multiplier showed up. Claude Code did this in parallel, in a single turn, without me micromanaging the order:

• Grepped src/ for every process.env reference, building a complete list of environment variables the code actually uses.
• Cross-referenced that list against vercel env ls output to find variables that were provisioned but no longer referenced (there were none).
• For each credential, opened the relevant file and inferred the minimum scope it needs. For GITHUB_TOKEN, it looked at src/lib/github-api.ts and determined the only operation is file CRUD on a specific repo: "Contents: Read and write" on a fine-grained PAT, not the classic repo scope.
• Checked ~/.claude/secrets/secrets.env for any shadow copies of the exposed keys. Result: none. That file held UniFi, Obsidian, Exa, Firecrawl, and Ollama keys, all unrelated.
• Grepped .env* files across the cryptoflexllc project directory. None on disk.
• Ran git log -p --all against every branch for any pattern matching the exposed variables. Zero matches. The repo has always been clean.

Within ten minutes I had a structured scope document. Nine credentials to rotate, local exposure confirmed zero, one coordination concern flagged: the ANTHROPIC_API_KEY might also be in use by my Home Network Mission Control Dashboard project, and if so I would need to update that project's .env after rotating on Vercel.

The Plan File Pattern#

Before executing anything, Claude Code wrote a plan file at docs/plans/2026-04-20-cryptoflexllc-credential-rotation-plan.md. This is a pattern I use for every non-trivial operation now, and it is the single thing I would recommend any reader adopt.

The file is in a private config repo, so I cannot link to it, but the structure is trivial to mirror. Here is the skeleton:

# <project> Credential Rotation Plan

Trigger: <link to disclosure>
Date opened: <date>
Owner: <name>

## 1. Scope and Compromise Assessment
- Table of credentials with issuer and blast radius
- What is NOT at risk (public identifiers, etc.)
- Local exposure audit results

## 2. Prerequisite: CLI auth or access

## 3. Rotation Checklist
- One section per credential
- Each section has the exact commands, in order
- Revoke old at issuer, create new, update platform, verify

## 4. Platform Hardening (non-rotation)
- 2FA, deployment protection, OAuth audits

## 5. Post-rotation Monitoring (7-day window)
- Table of where to watch for auth failures on the old credential

## 6. Completion criteria
- Checkbox list: all done when every box is ticked

The AI-Assisted Response Loop#

This is the part the user reading this actually cares about: what does "AI for defenders" look like in practice? Not marketing. Not demos. The actual loop, as it ran.

Five stages, and the one that does the heavy lifting is stage three: parallel execution. Traditional incident response is serial. Read the docs for the first service, rotate the key, verify, move on to the next. Claude Code does not do that. It fires off the read calls in parallel, waits for all of them, then coordinates the write calls with appropriate dependencies (e.g., revoke at issuer before update on Vercel).

Here is one practical example. The rotation plan called for me to review the last ~60 days of Vercel activity to make sure nothing unusual had happened during the breach window. I did not want to click through the activity log by hand. I gave Claude Code a freshly rotated VERCEL_API_TOKEN (so I was reading Vercel state with a clean key) and asked it to pull the forensic evidence.

In a single turn, in parallel:

# All four of these ran in parallel as one Claude Code message.
# SINCE_MS is an epoch-ms anchor covering the breach window (2026-03-01).
SINCE_MS=1740787200000

curl -sS -H "Authorization: Bearer $NEW_VERCEL_API_TOKEN" \
  "https://api.vercel.com/v6/deployments?teamId=$TEAM_ID&limit=100"

curl -sS -H "Authorization: Bearer $NEW_VERCEL_API_TOKEN" \
  "https://api.vercel.com/v3/events?teamId=$TEAM_ID&limit=12&since=$SINCE_MS"

curl -sS -H "Authorization: Bearer $NEW_VERCEL_API_TOKEN" \
  "https://api.vercel.com/v5/user/tokens"

curl -sS -H "Authorization: Bearer $NEW_VERCEL_API_TOKEN" \
  "https://api.vercel.com/v1/teams/$TEAM_ID/members"

100 deployments, 12 team events, my own user's token creation history, and the team membership list. All pulled, parsed, and summarized in under a minute. The review result: every deployment author was me, every event timestamp matched a commit I had made, and there was exactly one "Chrome on Windows" session active during the incident window. That was me too: my work machine is Windows, my personal machine is the Mac I am writing this post on. Dual-machine workflow.

Click to enlarge

Rotation Order by Blast Radius#

Nine credentials. They are not equal. Rotating them in the wrong order can let an attacker with a stale but still-working key interfere with the rotation of the others. The rule: rotate the credential with the largest downstream blast radius first.

The top of the ladder is VERCEL_API_TOKEN. If an attacker still has it while I am rotating the others, they can modify the env vars I just updated. So it goes first. The HMAC secrets are at the bottom because they only sign cookies locally; they cannot be used to rotate anything else.

This ordering fell out of a two-minute conversation with Claude Code: "What order should I rotate these in, and why?" The answer was correct, and the explanation was good enough that I could sanity-check it and push back on one item I disagreed with.

I bumped DATABASE_URL to position 2 instead of 3 because Neon downtime during a password reset is the most user-disruptive step in the chain, and I did not want it sitting in the back half of the rotation window. A pure blast-radius ordering would put GITHUB_TOKEN at position 2, because repo write access can re-inject secrets into future builds. I accepted the downtime-weighted reorder on the theory that I could revoke GITHUB_TOKEN at GitHub instantly, so its effective rotation was fast even at position 3.

Click to enlarge

The HMAC Secrets Trick#

Six of the rotations were UI-gated. Open the issuer's dashboard, click buttons, copy a new value. But three of them were pure signing keys generated by me, for me, used by my own code. Claude Code generated a fresh 256-bit value for each and re-added them to Vercel with the Sensitive flag on:

for name in ANALYTICS_SECRET SUBSCRIBER_SECRET CRON_SECRET; do
  value=$(openssl rand -hex 32)
  vercel env rm "$name" production --yes
  printf "%s" "$value" | vercel env add "$name" production --sensitive
done

Three fully scriptable rotations in under thirty seconds, each with the Sensitive flag turned on this time.

The Platform Hardening Pass#

Rotating secrets closes the door on the stolen values. It does not close the door on the attacker coming back through another path. So after the nine rotations, I spent another fifteen minutes on platform hardening:

1. Enabled 2FA on my Vercel account. If you are still running with password-plus-GitHub-SSO in 2026, stop that today.
2. Verified Deployment Protection was set to Standard. It was; no change needed.
3. Audited Deployment Protection bypass tokens. Zero existed. Good.
4. Revoked the Context.ai OAuth grant in my Google Workspace, which was the actual root-cause trust relationship that started this whole cascade upstream.
5. Audited every other third-party OAuth grant in my Workspace. Revoked a handful of apps I had signed into once years ago and forgotten about.
6. Pushed my Workspace third-party app policy from default-allow to "only trusted apps" (explicit allowlist). This means any future OAuth grant has to be approved by me before it takes effect.

Every state change was verified programmatically. After enabling 2FA, Claude Code hit the Vercel API to confirm my account reported MFA enabled. After rotating DATABASE_URL, it ran psql "<old-connection-string>" and confirmed the old password is no longer valid. Password rotation alone does not rule out a rogue role the attacker could have created with valid creds, so Claude Code also listed Neon roles and confirmed none existed beyond the ones I had provisioned. Trust, but verify. Better: do not trust the UI, verify the API.

Actionable Caution: What You Should Do Today#

If you host anything on Vercel, whether or not you received a direct notification from them, read this section and act on it. I have tried to make it scannable enough to execute on a phone.

Click to enlarge

The Hour in Numbers#

The actual numbers from my session:

• 9 environment variables rotated, each verified as Sensitive afterward.
• 100 deployments pulled and reviewed via /v6/deployments.
• 12 team events pulled via /v3/events and read for anomalies.
• 1 old Vercel API token revoked (the one that could have been used against me if it had leaked).
• 6 Google Workspace third-party OAuth apps revoked in the hardening pass.
• 0 anomalies found in the 100 deployments or 12 events I could pull. Env var read events on the internal tooling path are not in the customer-visible audit log, so this is a clean customer-side audit, not a breach-negative result.
• 0 shadow copies of the nine credentials found in local config.
• ~60 minutes wall time from "reading the breach disclosure" to "hardened and documented".
• ~6 to 8 hours, estimated, if I had done the same work without Claude Code.

The delta is not magical. Every step I just described I could have done manually. None of them are individually complex. But the aggregate work would have taken me a full day under normal circumstances, and longer under the emotional load of "you might have been breached, hurry up". With Claude Code orchestrating the session, the checklist stayed alive in working memory even while I was context-switching into external dashboards to click buttons, and every verification step happened as soon as the preceding action completed.

What "AI For Defenders" Actually Looks Like#

I have been writing this blog about AI agents since February of this year. I have written about agents that write code, agents that audit code, and agents that run security sprints. This post is different. This was not a planned exercise. This was me, rattled, with a production system I care about, responding to someone else's breach disclosure.

And here is the honest version of what helped:

1. Parallel tool calls. Not sequential. Not "do one thing at a time". Claude Code fires off the grep, the API pull, and the config read in the same turn and tells me when all three finish. That is the force multiplier.
2. The plan file. Not the chat. A durable checklist that survives context compaction and can be reviewed by a peer.
3. Programmatic verification. Every UI-gated action was followed by an API-level confirmation. The UI lies. The API does not.
4. Persistent working memory across a long session. I never had to stop and ask "which ones did I rotate already". Claude Code kept the board.

This is not an autonomous agent neutralizing threats in real time. That is marketing. What it is, is a patient co-pilot that turns a day of recovery work into an hour and makes sure you do not miss a step while you are still rattled from reading the breach disclosure.

What Is Next#

I am going to keep monitoring the upstream service logs across the 7-day window and beyond: Neon, Anthropic, Resend, GitHub, Gmail, and Vercel. If anything tries the revoked credentials, or if Vercel's post-mortem surfaces new detail worth writing about, I will come back with a follow-up. If nothing shows up, the silence is itself the outcome, and I will let the monitoring just be monitoring.

In the meantime, the plan file I described above is the single most reusable artifact from this incident. It lives in a private config repo, so I cannot link it, but the structure is in the section above and takes about fifteen minutes to adapt to any stack. Write it once. Use it every time something upstream goes wrong. You will thank yourself.

Your Move If You Run On Vercel#

You do not need to wait for a direct notification. Right now, in the next fifteen minutes:

1. Open vercel.com/account/environment-variables in your project, rotate anything without the Sensitive flag, and re-add each value with --sensitive so the internal tooling path cannot read it again.
2. Turn on 2FA and set Deployment Protection to Standard or better.
3. If you use Google Workspace, revoke any third-party app grant you do not actively use, especially any consumer product you signed up for with an enterprise account.
4. Protect your default branch on GitHub and scope every PAT to one repo and one permission set, with an expiry.
5. Open a plan file for your next rotation before you need one. Ten minutes today, one hour saved the next time something upstream goes wrong.

If that list looks long, good. That is what supply chain defense looks like in 2026. It is not glamorous, it is not autonomous, and it is mostly checkbox work. Which is exactly the kind of work a patient AI co-pilot is built to keep alive in your working memory while you are still rattled from reading the disclosure.

Stay safe out there. And flag your env vars Sensitive.