Breach Lessons - First Look: Vercel and Context AI
We usually wait for the investigation to complete, but there are already a ton of useful lessons here.
We’ll come back and update this post as new information comes out. Early breach information is often wrong or missing important context, so we’re going to focus on lessons that are broadly useful, even if the breach details fundamentally change later.
In other words: you should take the breach details here with a grain of salt, but take the lessons to heart.
Attackers know that buying hacking in bulk is a good value
Third party and supply chain attacks have been en vogue for a few years now and this trend only seems to be increasing. Why hack one company when you can hack thousands of companies or users through a software/services supplier?
The hack once, exploit many nature of these attacks isn’t the only attraction. Integrating with third party software often requires creating OAuth applications or tokens that grant the third party access to your own data and systems, or another third party software supplier your company uses. Unfortunately, session hijacking via token theft is still an unsolved problem, meaning that attackers who obtain OAuth keys and other types of auth tokens get to bypass the authentication process.
We covered this on Enterprise Security Weekly back in December (jump to the 34:40 mark in the video).
Token theft works so well, it has led to a rise in the use of infostealer malware and ClickFix social engineering techniques over the past two years. The rationale here is that the employees with high-level privileges to systems typically use MacOS. Macs are harder to attack directly and infect with malware, so attackers pivoted to the ClickFix social engineering technique, which has proved effective.
Convince a Mac user to copy a command and paste it into their terminal (under the guise of fixing a problem or installing harmless software), and the infostealer runs, scooping up crypto wallets, plaintext passwords, SSH private keys, environment variables, auth tokens from logged-in sessions, ~/.openclaw/credentials/oauth.json and anything else not nailed down.
The high price of convenience and forgetfulness
These session keys exist, because no one wants to spend the first 40 minutes of every work day logging into Teams, email, Slack, Github, Dropbox, Google Calendar, LinkedIn, Claude Code, Mastodon, Microsoft 365’s Office apps, the Apple App Store, and everything else we might need to be productive. In addition to simply logging into the apps of our choosing, there are also 3rd party integrations that require auth keys to function.
For example, if I want ChatGPT to be able to locate files in Dropbox, I can integrate the two, but this requires granting ChatGPT at least read access to Dropbox. Sometimes (ahemGoogleahem) the third party doesn’t allow this access to be as fine-grained as you might want and you grant too much access. Sometimes, you don’t want to spend an extra 10 minutes figuring out permissions, so you just click the “Grant Full Access” option.
Creating these integrations often takes mere seconds. Then, we immediately forget the integration exists. This is a problem.
When I was working at Valence Security, we observed that 100% of our customers at the time of joining, had granted tenant-level access to third parties that they were not using. In other words:
they did a proof-of-concept with someone
gave the product full control of all employees’ email, files, and calendar in Google Workspace or Microsoft 365
didn’t buy the product
forgot to revoke a token that granted FULL ACCESS to nearly everything the company cared about
Third Party Breach Turducken
This brings us to the Vercel and Context AI breaches: a third party breach within a third party breach. Let’s start with Context AI1.
In June 2025, Context AI released a consumer product that was designed to be an agent-driven productivity monster. Give it access to your chats, your email, your files and it can build slides, spreadsheets, and reports using all the context from your existing files and conversations.
Of course, for this to work, you need to give it access to all your stuff. Everyone reading this was probably familiar with the dangers of doing this a year ago. If not then, certainly now, post-OpenClaw.
While Vercel was never a Context AI customer, one of their employees was. This employee gave Context’s AI Office Suite full access to their Vercel Google Workspace email, calendar, and files. In Context’s words:
Vercel wasn’t a customer, but at least one of their employees granted access to Vercel’s Gooogle Workspace and granted “Allow All” permissions
At some point, Context AI pivots to an enterprise product called Context Bedrock and deprecates their AI Office Suite. From what I can gather from the state of their website according to the Wayback Machine, this pivot happened well before this attack began. Shared responsibility failed during this pivot. Based on what we know so far, after this product was deprecated:
The Vercel employee didn’t revoke the tokens Context was still storing.
Context didn’t delete customer tokens and didn’t shut down the infrastructure used by AI Office Suite
We don’t know if Context notified AI Office Suite customers that the product was being deprecated, but I couldn’t find any public notice of this fact on the company’s websites, LinkedIn, or Twitter accounts.
Context Gets Breached
In March 2026, Context “independently identified and stopped a security incident involving unauthorized access to our AWS environment.” They hired CrowdStrike, who identified one affected customer. Context notified this customer and shut down the remainder of the AI Office Suite infrastructure.
Given Context’s description, it seems possible that there was never a hard shut down of the old product and that the company simply started work on a new product while letting the old product continue running, unsupervised and unmonitored.
In light of the Vercel breach, Context put out its own security notice, noting that perhaps AI Office Suite OAuth tokens were also compromised in its own breach the previous month. Sadly, Context’s security notice doesn’t share any information about how they got breached, but in their defense, they mention that they’ve restarted their investigation, which is ongoing.
Vercel Gets Breached
Vercel is a vibe-coding product that specializes in building application/website front-ends (the part you can see). On April 19th, they became aware that one of their employees’ accounts was compromised and being used to access customer environments. They don’t mention what tipped them off to the attacker’s presence, or how long the attacker was present. Again, I’m writing this only one day after they detected the attack, so they’re likely far from completing their investigation.
Vercel contacted affected customers and recommended immediate credential rotation. They’re still working to determine what data was exfiltrated, if any.
Vercel provides some advice on how customers can protect their environments with a few built-in security features, like ‘sensitive environment variables’ and ‘deployment protection’. They also share the identifier for the Context OAuth app that was used to compromise them through Google Workspace: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Lessons/Control Failures
Vercel’s corporate collaboration suite was over permissive - the employee should not have been able to hand over full control of their work account to a third party without business justification and/or security review.
Failure to revoke access once no longer needed - both the employee and Context failed to revoke the access after the product was deprecated.
Access token theft (T1134.001)
Lack of regular access reviews - given how this attack occurred, and the fact that Context’s product didn’t even last a year, suggests that annual reviews of employee-initiated integrations would be far too infrequent. Monthly may be more appropriate, given the velocity of AI app development and adoption (both sanctioned and shadow).
Too much employee access to customer data/workloads - we’ve all seen SaaS products where access to customer data is far too permissive. Travis Kalanick’s abuse of Uber’s God View is perhaps one of the most egregious cases of this.
Timeline
2025 - A Vercel employee signs up for Context’s AI Office Suite product
2025 - This employee grants AI Office Suite full access to their Vercel Google Workspace resources (Email, Calendar, and Files at a minimum).
March 2026 - Context becomes aware of a breach in its AWS environment and hires Mandiant to investigate. One customer is notified.
April 19, 2026 - Vercel becomes aware of a breach and traces the source of the breach back to an OAuth token granted to Context AI by one of its employees
Both Vercel and Context continue to investigate - hopefully more details will come out and they will be transparent about how both breaches were initiated and detected.
Conclusion
How often do we perform a security review of our personal or corporate third party integrations? Does a Blackberry Curve from 2012 still have full permissions to access your Gmail? Surely that access would expire, right? Think again.
The first big lesson here is that, in a cloud-first/SaaS-first world, we have to regularly review all the access we’ve given to third parties: access to our data, to our devices, to our employers, to our kids. In an ideal world, this access control model should be reversed. By default, access granted to third parties should come with an expiration date by default.
There are examples of how to do this correctly! I have a Linux laptop with the Signal app installed. I haven’t used this laptop in nearly a month. The other day, Signal on my iPhone notified me that my Linux laptop would lose access to Signal if it remained idle for a full month. I didn’t use the laptop and Signal is now disconnected there.
From a corporate perspective, this should also be a bigger priority. SaaS Security Posture Management (SSPM) tools are fairly easy to come by these days and specialize in bringing attention to these risks.
The other big lesson here regards employee access to customer data. When I was an Industry Analyst at 451 Research, I’d look forward to going to AWS reInvent every year. At reInvent, I’d get a chance to talk to Stephen Schmidt, who was the AWS CISO at the time. His perspective, as the security leader for the largest hyperscaler, was interesting - every year, he took great pride in how much he was able to reduce employee access to customer data. Over anything else, he seemed most concerned about an insider threat or compromised employee impacting customers. A concern that appears to have been well founded.
For anyone trying to research Context, this isn’t the Context AI that was acquired by OpenAI in early 2025. Nor is it the UK Context AI, or ContextAI - it’s this one. It was called “Context Inc” until after the OpenAI acquired one was shut down and then rebranded as Context AI. Joseph Semrai is the founder and CEO.