Vercel’s Breach and Why We Don't Gamble With 'Non-Sensitive' Secrets
Vercel got hit, and the pivot point was a third-party AI tool. Here is why Sweent's strict security protocols would have kept our clients safe while others were rotating keys in a panic.
We woke up to the news that Vercel got hit. If you're in the web development world, that is like hearing the main vault at the bank just got picked. Vercel isn't some amateur operation; they're the backbone for millions of sites, including the Next.js ecosystem. But even the giants can stumble when convenience starts winning the tug-of-war against security.
The breach didn't start with a direct hit on Vercel's servers. It started with a third-party AI tool called Context.ai. A Vercel employee had it connected to their Google Workspace via OAuth. The attackers hit Context.ai, rode that OAuth connection into the employee's Google account, and from there, they had a map to the internal kingdom. It is a classic supply chain pivot, and it is messy.
But here is the part that really gets us at Sweent: the attackers were able to read environment variables that weren't marked as sensitive. Vercel has a system where developers can choose whether a variable is sensitive or not. If you don't check that box, those secrets are stored in a way that makes them readable if an attacker gets inside. At Sweent, we look at that design choice and see a massive, unnecessary risk. We don't believe in giving developers the option to be less secure for the sake of convenience.
The Fallacy of the 'Non-Sensitive' Secret
In the Vercel dashboard, there is a distinction between sensitive and non-sensitive environment variables. The idea is that some things, like a public API key or a non-critical config string, don't need the high-level encryption that a database password does. But in practice? Developers are busy. They're shipping code at 2:00 AM. They take the path of least resistance. If the default isn't 'Maximum Security,' secrets will leak. It's not a matter of if, but when.
We've seen this happen across dozens of projects before they come to us. A developer thinks a specific token is 'low risk,' so they don't bother with the extra layer of protection. Then a breach happens, and that 'low risk' token becomes the pivot point for a full system takeover.
At Sweent, our protocol is simple: there is no such thing as a non-sensitive environment variable. If it's a variable that lives in a .env file or a CI/CD pipeline, it's treated as a critical secret. Period. We don't offer a 'convenience' toggle that leaves keys in the clear. By enforcing a strict policy where every single variable is encrypted and restricted, we eliminate the human error that led to the exfiltration of data in the Vercel incident. If an attacker had managed to get into one of our environments during a similar breach, they would have found a wall of encrypted data they couldn't read, rather than a list of 'non-sensitive' keys they could use to escalate their attack.
Fighting AI-Accelerated Attackers with Protocol
Vercel's CEO mentioned that the attackers moved with 'surprising velocity' and were likely accelerated by AI. This is the new reality. We're no longer just defending against a guy in a hoodie manually typing commands. We're defending against automated agents that can analyze a system architecture, identify vulnerabilities, and execute an exploit in seconds.
When the adversary is moving at machine speed, your defense can't rely on a human deciding which checkbox to click. It has to be baked into the infrastructure. That is why we've built our internal workflows to assume a breach is always possible. We don't just monitor for intrusions; we reduce the attack surface so there is nothing for the AI to find once it gets through the door.
One of the biggest issues in the Vercel breach was the OAuth connection. OAuth is incredibly useful, but it's a massive security hole if it isn't managed with extreme discipline. You click one button to try a new AI productivity tool, and suddenly that tool has read access to your entire Google Workspace. If that tool gets hacked—like Context.ai did—your whole organization is exposed.
Our team at Sweent enforces a zero-trust policy for third-party integrations. We don't let 'shiny new tools' get connected to our core systems without a full security audit. And even then, we restrict the scopes to the absolute bare minimum. If a tool only needs to read one calendar, it doesn't get access to the whole Workspace. It sounds like a lot of work, and it is. But it's the difference between a minor incident and a $2 million ransom demand from a group like ShinyHunters.
The 24-Hour Secret Rotation Rule
Even with the best defenses, things can go wrong. The mark of a professional team isn't just how they prevent a breach, but how they respond to one. Vercel recommended that their customers rotate their credentials immediately. But 'immediately' is a vague term in the corporate world. For some companies, that means next week. For others, it means after the long weekend.
At Sweent, we have a hard rule: in the event of any suspected compromise, every single secret, API key, and database string is rotated within 24 hours. We don't wait for a full post-mortem. We don't wait to see if the data was 'actually' exfiltrated. We move faster than the attacker.
By the time an attacker realizes they have a key, that key is already dead. We use automated scripts and infrastructure-as-code to handle this. If we had been using Vercel during this breach, our clients' keys would have been cycled and secured before the news even hit the major tech blogs. Speed is the only defense against an attacker moving with AI-driven velocity.
Supply Chain Security and the 7-Day Rule
The Vercel breach also raised concerns about the NPM supply chain. Since Vercel owns Next.js, an attacker with the right tokens could potentially ship a 'poisoned' release to millions of developers. This is the nuclear option of cyber warfare. If you're blindly updating your dependencies every time a new version drops, you're playing Russian Roulette with your codebase.
We protect our clients by implementing a mandatory delay on all non-critical dependency updates. We typically wait at least 7 days before pulling in new versions of major libraries. Why? Because most supply chain attacks are identified and neutralized within that first week. By not being the 'early adopters' of every minor patch, we ensure that our clients aren't the first ones hit when a package gets hijacked.
It might feel like we're being overly cautious, but look at the alternative. ShinyHunters is allegedly selling Vercel's internal database for $2 million. They have 580 employee records, internal dashboards, and source code. That is a catastrophic failure that could have been mitigated by stricter internal protocols and a less 'convenient' approach to secret management.
Why We Don't Skip the 'Hard' Parts
Security is often seen as a friction point. It slows down development. It makes it harder to try new tools. It adds steps to the deployment process. And that is exactly why so many startups skip the hard parts. They want to move fast and break things. But when the thing you break is your customers' trust, you might not get a chance to fix it.
We built Sweent on the idea that digital transformation shouldn't come at the cost of security. We handle the friction so our clients don't have to. We're the ones doing the security audits on AI tools. We're the ones enforcing mandatory encryption on every environment variable. We're the ones staying up to rotate keys within 24 hours while the rest of the industry is still reading the headlines.
If you're on Vercel right now, you should probably go check your dashboard. Audit every single variable. Mark them all as sensitive. Sever any OAuth connections you don't absolutely need. But if you want to stop worrying about whether your developers checked the right box at 2:00 AM, you need a partner that doesn't treat security as an optional feature.
At the end of the day, Vercel will likely recover from this. They have elite engineers and plenty of capital. But for a smaller company, a breach like this is a death sentence. Don't wait for the next big headline to realize your 'non-sensitive' variables are a liability. The attackers are moving at machine speed. Are you?
Frequently Asked Questions
The attackers didn't go after Vercel directly. They breached Context.ai, a third-party AI tool a Vercel employee had connected to their Google Workspace via OAuth. From that OAuth grant the attackers rode into the employee's Google account and from there had a map to Vercel's internal systems. It's a classic supply-chain pivot — you're only as secure as the least-audited integration any team member has clicked "Allow" on.
Giving developers a toggle between "encrypted" and "readable" secrets is a design choice that bets on every developer, every time, picking the secure option at 2 AM under shipping pressure. They don't. The Vercel breach confirmed it: the attackers walked out with values that were technically marked "not sensitive" but turned out to be plenty sensitive when combined with other findings. Our policy: there is no such thing as a non-sensitive secret — everything in a .env or CI/CD pipeline is encrypted the same way, no toggle.
Every key rotates within 24 hours, full stop. We don't wait for a post-mortem to confirm whether data was actually exfiltrated — by the time that's clear, the attacker has already used what they stole. Infrastructure-as-code and automated rotation scripts make this mechanical, not heroic. By the time an attacker realizes they have a key, that key is already dead.
Most supply-chain attacks in the npm ecosystem are detected and neutralized within the first week of a malicious release — because other teams running tighter canaries find the problem and the registry pulls the package. Waiting 7 days before pulling in new major versions means our clients aren't the first ones hit when a popular package gets hijacked. It costs a small amount of delay; it avoids a class of attack entirely.
Treat every OAuth grant as a permanent hole in your perimeter until proven otherwise. Run a security audit on the tool before connecting it. Restrict scopes to the absolute minimum — if a tool only needs one calendar, it doesn't get the whole Workspace. Review active grants quarterly and sever anything not demonstrably in use. The convenience of single-click integration is how Context.ai became the pivot into Vercel; apply friction deliberately where it costs you the least and saves you the most.