AI Breaches: The Beginning of a New Norm

Introduction

The recent breach at Vercel has drawn a lot of attention, not because the initial entry point was unusual, but because of what the incident quietly demonstrates about how modern workflows shape the impact of a compromise. This did not begin with a phishing email or an exposed service. It began with an AI tool.

According to Vercel’s own disclosure, the incident originated with the compromise of Context.ai, a third-party AI tool used by a Vercel employee, with additional reports indicating that the employee’s credentials were initially harvested by Lumma Stealer (or LummaC2) malware in February 2026. From there, the attacker pivoted through additional systems to access the employee’s Google Workspace account, ultimately accessing Vercel’s environment information.

In the days that followed, data allegedly belonging to Vercel was listed for sale on BreachForums for $2 million under the ShinyHunters name. Vercel’s CEO, Guillermo Rauch, later noted that the attackers “moved with surprising velocity and in-depth understanding of Vercel” and that they appeared to have been “significantly accelerated by AI”.

This post takes the Vercel incident as a case study to explore how AI tools are reshaping the risk profile of the modern enterprise, why traditional controls struggle to keep up, and what organisations should be doing about it.

Where the Traditional Model Starts to Break?

In a more traditional breach, data exposure tends to follow relatively well-understood paths, such as file access, database queries, and API calls. These are observable, governable, and in most mature environments, monitored.

In modern engineering environments, however, workflows are increasingly mediated by AI tools. Debugging, code generation, documentation, analysis, and even architecture decisions are now often assisted by external or embedded AI models. The Vercel incident is a clear example of this shift in two distinct ways:

• The AI tool itself became the entry point. Context.ai was the initial foothold, not a downstream risk.
• The attacker’s tradecraft appears to have been accelerated by AI, according to Vercel’s CEO.
• This introduces a different class of exposure that many existing controls are simply not designed to see:
• Sensitive credentials and configuration are routinely passed into AI tools as part of normal development workflows.
• AI tools commonly integrate with identity providers via OAuth, extending the trust boundary in ways that are not always obvious.
• Context is aggregated across prompts, often combining multiple sources of internal data into a single interaction.
• Data handling beyond the organisation’s boundary becomes opaque, particularly in third-party or embedded AI systems.

The challenge is that none of this necessarily triggers traditional controls. An employee connecting a new AI tool, granting it OAuth scopes, and using it through the working day does not look like exfiltration. It simply looks like usage. And in most organisations today, usage is largely unmonitored.

The Compounding Effect of Context

One of the more subtle risks in AI-assisted workflows is the way context compounds over time.

An API key on its own may have limited value. A snippet of infrastructure code may appear harmless. Internal documentation might be considered low sensitivity. However, when these elements are combined within a single prompt, or aggregated across a sequence of interactions, they create a much richer representation of the system. That context can often be sufficient to reconstruct access paths, identify weaknesses, or accelerate lateral movement.

The Vercel case is a useful illustration of this. The attackers did not access Vercel’s most tightly protected secrets. According to Vercel, the encrypted environment variables were not exposed. What was accessed, however, was a set of non-sensitive environment variables and reportedly, items such as API keys, deployment credentials, GitHub and npm tokens, internal database records, and employee details.

Individually, some might consider several of these items to be of lower risk. However, together can create a map of how Vercel operates internally, and that is where the value sits for an attacker. The issue is not a single piece of leaked data. It is the slow accumulation of context that no traditional control is designed to see.

The Financial Impact as a Second-Order Effect

The $2 million figure that has been referenced in reporting is not a ransom attack but the asking price for the stolen data on BreachForums under the ShinyHunters name.

The distinction matters, even if the outcome for the victims is similar. Once an attacker has enough context, the value is no longer limited to the data itself, but in what the data enables. Intellectual property, system access, and the ability to disrupt services all become leverage, whether used to extort the organisation directly or monetised through underground markets.

This aligns with a broader pattern seen across AI-related incidents. Risk does not remain contained within security teams. It escalates to legal, compliance, and executive leadership very quickly, because the consequences are rarely only technical.

What makes this more concerning is how closely it aligns with what we are seeing across wider enterprise environments. Our recent research highlights a persistent gap between perception and reality:

• 72% of security leaders believe they have full visibility into AI usage, yet 65% still uncover unauthorised or shadow AI usage.
• 67% report that AI is already widely used across teams, and 91% expect that usage to increase.
• Over 50% of organisations cite data leakage and compliance violations as top concerns.

Even in highly regulated industries, where governance maturity is high, shadow AI usage remains persistent. Behaviour does not align cleanly with policy, particularly when AI tools are embedded into the everyday workflows employees already rely on.

The Control Plane Has Shifted

What incidents like Vercel’s breach really suggest is that the control plane is moving. Historically, security teams have focused on questions such as:

• Which applications are approved?
• Where is data stored?
• Who has access to systems?

These questions still matter, but they no longer address how a lot of data is actually used in practice, or how trust is extended to the growing number of AI tools employees adopt. The relevant layer has shifted closer to the interaction itself:

• Which AI tools are employees connecting to corporate identities?
• What is being shared in those tools, and how is that data being used?
• When does usage deviate from expected patterns?
• Do users receive any feedback or guardrails in real time?

Without visibility at this level, organisations are effectively relying on policy without enforcement. Policies may be well written, well communicated, and well intentioned, but they will not stop a Lumma Stealer infection on an endpoint from cascading into a third-party AI tool, or stop that AI tool from becoming a pivot point into the organisation’s wider estate.

A More Practical Framing

It is tempting to frame this as an AI security problem. That framing tends to lead back to familiar approaches such as blocking tools, restricting access, or tightening acceptable use policies. These measures have their place, but on their own, they rarely succeed.

A more accurate way to think about this is as an AI usage problem. The risk is not emerging from clearly malicious actions or unauthorised tools alone. It is emerging from legitimate activity carried out in new contexts, by employees doing their jobs with the tools available to them, and by attackers who, as Vercel’s CEO put it, appear to be “significantly accelerated by AI” themselves.

The implication is that control needs to be applied differently. Not by preventing usage, but by making it observable and governable as it happens. That means:

• Visibility into what is being submitted to AI tools, not just which tools are in use.
• Oversight of how AI tools are authorised against corporate identity.
• Guardrails that can intervene in real time, before sensitive context leaves the environment.
• Analytics that help leadership understand usage patterns, not just policy compliance.
• Education and feedback delivered at the point of interaction, so that behaviour adjusts naturally over time.

This is not about slowing adoption. It is about enabling it in a way that does not quietly expand the organisation’s risk surface with every interaction.

Conclusion

The Vercel breach is not unique, and it will not be the last of its kind. What makes it instructive is the way it exposes how traditional security models are starting to break down. An infostealer infection, a third-party AI tool, an OAuth pivot, and a set of “non-sensitive” environment variables were enough to produce a security incident, a CEO statement about AI-accelerated attackers, and a $2 million listing on an underground forum.

AI has rapidly become a core part of how work gets done, and with it, the boundaries of sensitive data and trusted identity have moved. AI tools now sit alongside core SaaS platforms in the daily workflows of most employees, often connected directly to corporate identity, yet remain largely invisible to the teams responsible for protecting the organisation. In that environment, a compromised endpoint is no longer just a door into traditional systems. It is a door into everything the organisation has shared with, and delegated authority to, its AI tools.

The organisations that will navigate this shift successfully are not those that attempt to block AI use, but those that make it visible, measurable, and governable. AI usage control, shadow AI discovery, OAuth and identity oversight, and real-time guardrails are no longer optional extras. They are quickly becoming essential components of any modern security strategy.

Incidents like Vercel’s are a reminder that the next generation of breaches will not always look like breaches. Sometimes, they will look like usage. The task now is to make sure we can tell the difference.