What the Vercel Breach Reveals About Third-Party Integration Risk
On April 19, Vercel, a platform for deploying and hosting web apps, used by over 6 million developers worldwide, disclosed a security incident affecting thousands of organizations worldwide. The incident originated from a small, third-party AI tool connected to Vercel’s internal system through Google Workspace OAuth app.
A threat actor identifying as “ShinyHunters” is claiming responsibility and is allegedly offering stolen data for sale, including access keys, source code, database information, API keys, NPM tokens, and GitHub tokens associated with internal deployments and developer environments.
If your organization is using Vercel, your development pipelines, production environments, and internal tools probably have active Vercel integrations that expose you to this attack, which influences not only apps and data hosted on Vercel but also integrated internal systems.
Continue reading this blog to understand the attack flow, the associated risks, and a mitigation guide.
How the Vercel Breach Unfolded
The attack began with a compromised OAuth app – a third-party application that had been granted delegated access to Vercel’s systems. From that single foothold, attackers were able to move laterally through the web of Non-Human Identities (NHIs) connected to Vercel: service accounts, API tokens, CI/CD integrations, browser extensions, and automation workflows that organizations had installed and largely forgotten.
This is the anatomy of a modern supply chain attack: it starts in OAuth, travels through NHIs, and lands in the systems of companies that build the apps the world depends on.
What Astrix Customers Knew Immediately
Within hours of the disclosure, each affected customer received an alert listing every Vercel-connected OAuth app in their environment, organized by platform (GitHub, Google Workspace, Slack, Chrome, Microsoft 365, Jira) and categorized by exposure level.
Here is how it looked for one of our customers:
For Astrix customers, the Vercel integration had already been removed through routine Astrix workflows, as part of standard security hygiene, before the incident was disclosed.
When Astrix customers with no Vercel integrations were notified, the message was specific: no active Vercel integrations were found across any of the platforms Astrix monitors, including GitHub, Google Workspace, Slack, Chrome, Microsoft 365, EntraID. As integrations to these platforms were detected in other customer environments, we also recommended verifying that no non-monitored environments were affected.
The Pattern That Keeps Repeating
The Vercel breach follows a now-familiar playbook:
- An AI tool or third-party app requests OAuth access
- It gets approved – often by a developer, not a security team
- It sits installed, trusted, and largely unmonitored
- The supplier is compromised
- Every downstream organization is exposed – and most don’t know it yet
The perimeter is no longer the network. It’s the identity layer and, specifically, non-human identities: the service accounts, tokens, API keys, and OAuth apps that outnumber human users by orders of magnitude in modern enterprises.
Most security tools track human identity. Astrix ensures visibility into the NHI layer: the service accounts, tokens, API keys, and OAuth apps that sit outside that scope.
Why Astrix Is Built for Exactly This
The Vercel breach isn’t a one-off. OAuth-initiated supply chain attacks are becoming the preferred entry point for sophisticated threat actors, precisely because the NHI layer is invisible to most security tools. Here’s why Astrix is different:
Complete NHI inventory across every platform
Astrix continuously discovers every OAuth app, service account, API token, and automated workflow across your entire environment – GitHub, Google Workspace, Slack, Jira, Chrome, Microsoft 365, and dozens more. When a supplier is compromised, you can answer “what do we have installed?” in seconds, not hours.
Supplier compromise detection built in
The moment a supplier is flagged as compromised – by Astrix’s own intelligence or by a public disclosure – every integration tied to that supplier is automatically surfaced across all customer environments. New installations trigger immediate alerts. Existing ones are queued for review. The response is automatic; the decision-making is human.
Anomaly detection on NHI behavior
Astrix monitors how NHIs behave, not just what’s installed. Unusual access patterns, unexpected source IPs, anomalous target resources are tracked and baselined continuously. The earlier you establish behavioral baselines for your integrations, the earlier suspicious activity becomes an actionable alert.
Access-level classification
A read-only Vercel integration in a minor workspace is not the same risk as a write-privileged GitHub app in your production organization. Astrix classifies every NHI by access level and exposure, so your team knows where to focus first.
What to Do Right Now
- Audit every platform individually. GitHub, Google Workspace, Slack, Chrome, Microsoft 365, Jira. There is no single view unless you’ve built one.
- Check access levels, not just presence. A Vercel integration that only reads public repos is different from one with write access to your main branch. Presence alone tells you nothing.
- Revoke anything you can’t explain. If no one knows why it’s there or who approved it, it shouldn’t stay.
- Check whether your anomaly detection covers NHI behavior. If the answer is “our SIEM monitors user logins,” you have a gap. This incident is exactly how that gap gets found.
The Vercel breach will not be the last of its kind. The organizations that came out of it with a clear picture of their exposure are the ones that had done the work in advance.
That work is what Astrix does.
To understand your NHI exposure, reach out to your Astrix contact or submit a request here.
