Notifications
Clear all
Topic starter
06/06/2026 2:21 am
TL;DR: A Vercel incident tied to a compromised Context.ai OAuth app shows how attackers can inherit legitimate Google Workspace access, move into internal systems, and expose customer data without breaking the perimeter, according to SlashID. The trust model, not the perimeter, is the weakness: OAuth grants persist until revoked, so one compromised third-party app can become a durable blast radius.
NHIMG editorial — based on content published by SlashID covering the Vercel OAuth breach: OAuth 2.0 supply chain risk and identity delegation abuse
By the numbers:
- The attacker could use stolen credentials within an average of 17 minutes after AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a third-party OAuth app is compromised?
A: A compromised OAuth app inherits whatever delegated scopes users already approved, so the attacker can act through legitimate tokens instead of noisy intrusion methods.
Q: Why do broad OAuth scopes increase breach impact?
A: Broad scopes turn one consent decision into multiple reachable resources, which gives an attacker a much larger blast radius if the app is compromised.
Q: How can security teams tell whether OAuth access is drifting out of policy?
A: Look for apps that request more scopes than their function requires, grants that were never revisited, and applications that suddenly gain broader permissions.
Practitioner guidance
- Inventory every third-party OAuth grant Map all apps authorized across Google Workspace, Entra, Okta, Salesforce, and similar systems, then flag dormant grants, unused apps, and broad consent bundles that still persist.
- Restrict consent to minimum viable scopes Review each application against its actual function and remove permissions that exceed the task, especially mail, drive, directory, and admin-level access.
- Create a fast revocation path for compromised apps Define who can revoke third-party grants, how bulk revocation is executed, and how affected users are identified from the identity graph before the attacker finishes lateral use.
What's in the full analysis
SlashID's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for reviewing OAuth app grants in Google Admin Console and comparing scopes against actual application use.
- Specific detection logic for risky OAuth scopes, anomalous applications, and scope escalation across identity providers.
- Operational examples for bulk revocation and affected-user identification after a compromised app is found.
- Cross-platform query patterns for searching dangerous scope combinations across multiple identity systems.
👉 Read SlashID's analysis of the Vercel OAuth breach and delegated access risk →
OAuth supply chain attacks: what IAM teams need to change now?
Explore further
06/06/2026 3:58 am
OAuth consent is now a standing identity control surface, not a one-time user action. The Vercel incident shows that a granted app can outlive the conditions under which it was approved, which turns consent into persistent attack surface. In identity governance terms, the issue is not just who approved the app, but how long the delegated trust remained in force after the app was compromised. Practitioners should treat OAuth grants as lifecycle-managed access relationships, not as static configuration.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a third-party OAuth app causes a breach?
A: Accountability usually sits across the app owner, the identity team, and the business approver because the risk is created by delegated trust and then sustained by governance gaps. The organisation remains responsible for how grants are approved, monitored, and revoked. Regulators and auditors will usually ask whether the access was necessary, monitored, and removed in time.
👉 Read our full editorial: OAuth supply chain attacks are outpacing enterprise identity controls
