Some security incidents are complex. The Vercel incident is more troubling because it was predictable. The attackers did not exploit a procurement gap. They exploited a definition gap.

Here’s what happened. A Vercel employee signed up for Context.ai’s AI Office Suite using a corporate Google account and clicked something effectively equivalent to “Allow All,” granting broad read access across Google Workspace. That tool was not an Vercel vendor, not under contract, and not in any third‑party inventory. Later, when Context.ai was compromised upstream, attackers reused those OAuth permissions to access Vercel’s internal environment and data.

No zero‑day was required. No controls were bypassed. The access was already approved.

The Freemium Fallacy At Work

This reflects a persistent and dangerous assumption dangerous assumption inside third‑party risk management (TPRM): if the company does not pay for a tool, it is not really a third party. That assumption quietly shapes how enterprises define third‑party risk, scope controls, and allocate accountability. In Vercel’s case, a self‑service, consumer‑style AI application gained enterprise‑grade access. It behaved like a third party in every way that mattered to risk, but without any of the friction that typically forces governance or accountability.

There was no contract, no vendor onboarding, and no TPRM workflow. Yet the application could read enterprise data and operate on behalf of a trusted identity. The breach did not occur despite controls. It occurred outside them. This wasn’t “shadow IT” in the narrow sense of unsanctioned hardware or rogue infrastructure. It was something more insidious: shadow vendors where external applications have real access and zero formal recognition in the TPRM program.

Why This Matters Beyond Vercel

This is not an edge case. It is an operating condition. Today’s enterprise ecosystems are saturated with self‑serve and freemium tools connected through OAuth, SSO, and APIs. They are easy to adopt (one click, one login); easy to forget (no invoice, no renewal cycle), and difficult to govern, especially for TPRM programs anchored to contracts and spend.

The result is structural risk nose blindness where organizations believe they understand their third‑party exposure because their vendor lists are complete, while real access‑based risk accumulates elsewhere.

Free Of Cost Does Not Mean Free Of Risk

The deeper failure is treating self‑service, individually adopted tools as out of scope for TPRM.  When TPRM programs only recognize “vendors we pay” as in scope, they systematically underestimate exposure in identity‑driven environments. The moment an external application can:

  • read data
  • impersonate a user
  • integrate with internal systems

… it becomes a third party in every way that matters to enterprise risk, regardless of the commercial terms.

What CISOs And Risk Leaders Must Do Now

Change how third‑party risk is defined, scoped, and operationalized. To do this, security and risk pros must:

  1. Redefine third‑party scope around access, not contracts. Any external application with access to employee data, customer data, intellectual property, or internal systems is in scope for TPRM, whether they are paid for or free. Access determines risk, not procurement status. Vendor masters reflect contracts. OAuth and SSO logs reflect the ecosystem. Only one of those shows where risk actually resides.
  2. Treat self-service access as a tiering decision, not an exception. High‑risk access demands high‑risk treatment. Tier third parties based on data sensitivity, identity privilege, and operational dependency, not contract value. If a free tool wants broad access into enterprise systems, it must meet enterprise expectations or be blocked.
  3. Measure success by mitigation, not documentation. If elevated risk does not automatically trigger review, restriction, or deprovisioning, your TPRM program is still observational, not operational. Mature TPRM is continuous, access-aware, and tied to access revocation. Use TPRM Platforms that lean into automated, AI‑assisted mitigation and remediation that activate the moment thresholds are crossed so you move from passive reporting to targeted intervention to do this.
  4. Anchor product security in practice, not just certifications. The breach highlighted the importance of secure by default features. Probe vendors on secure software development and secure by design practices. If they have gaps or don’t match your standards, implement mitigations to protect your organization.

Remember, not all third parties are captured in your inventory or vendor master.  TPRM programs that don’t expand to reflect this reality, are not managing third-party risk, they’re simply mislabeling it.

Schedule a guidance session with us to discuss third-party risk or software supply chain at your organization.