How a note‑taking tool breached Vercel
In April 2026, attackers reached Vercel through Context.ai, an AI note-taking tool an employee had connected. Stolen OAuth tokens were the way in.
In April 2026 attackers reached Vercel's internal systems without touching Vercel. They did not exploit the platform, or Next.js, or any code Vercel had written. They came in through Context.ai, a third-party AI note-taking tool that one employee had connected to their Google Workspace. When Context.ai was compromised, its OAuth tokens became a set of working keys to Vercel, and a group calling itself ShinyHunters listed the data for two million dollars.
The way in was a connected tool
The employee had done something ordinary. They connected an AI assistant to their work account to help with notes, the way thousands of people connect thousands of tools every week. That connection was granted through OAuth, which hands a tool a long-lived token to act on the account's behalf. The token does not care who is holding it. When the tool was breached, the attacker inherited every permission the employee had granted, and walked in as them.
Why security never saw it
The tool was never assessed by anyone in security, because it was never meant to be their decision. It was a personal productivity choice, approved by nobody and logged nowhere central. From the outside it did not look like part of Vercel's attack surface. It became the most important part of it.
Trusted integrations inherit a trust they were never audited for.MATT Research
The AI‑era version of an old problem
Supply-chain compromise is old. What is new is how many tools a modern company connects, how quickly, and how many of them are AI assistants asking for broad access to email, documents, and code. Every one of those connections is a new key to the building. Most organisations cannot say how many they have handed out, or what each one can reach.
The pattern
The lesson is about how you connect tools: treat every connected tool as part of the system it can reach. That means knowing what each integration can touch, granting the least it needs, and holding a rule for which tools may reach production and proving it holds. We map those connected-tool and identity paths the way an attacker would, from the outside. This account follows Vercel's own bulletin ↗ and Trend Micro's analysis ↗; both are linked from the Record.
Questions
How were attackers able to breach Vercel?
Not through Vercel's own platform. An employee had connected Context.ai, a third-party AI note-taking tool, to their Google Workspace. When Context.ai was compromised, attackers used its OAuth tokens to enter Vercel's internal systems as that employee. A group called ShinyHunters listed the stolen data for two million dollars.
What is an OAuth token, in plain terms?
It is a long-lived key you give a tool so it can act on your account without your password. It keeps working until it is revoked, and it does not check who is holding it. If the tool is breached, whoever holds the token inherits the access you granted.
Was Next.js or the Vercel platform at fault?
No. The attackers did not exploit Next.js or Vercel's platform. The way in was a connected third-party tool and the access it had been granted, not a flaw in Vercel's own code.
How could this have been reduced?
By treating every connected tool as part of the attack surface: inventory what is connected, grant each integration the least access it needs, and test that no low-trust tool can reach production. The tool here was never assessed because it looked like a personal choice.
Does this apply to companies using AI assistants today?
Yes. Modern companies connect many AI tools quickly, often with broad access to email, documents, and code. Each connection is a new key. The risk is less the tool itself than the access it holds and whether anyone is tracking it.