Notifications
Clear all
Topic starter
14/05/2026 12:39 pm
TL;DR: A third-party AI tool with Google Workspace OAuth access was implicated in a Vercel incident affecting thousands of organisations, with claims of stolen keys, tokens, and source code that could extend into connected development systems, according to the source article. The real issue is not one compromised app, but the unmanaged NHI trust chain that lets delegated access persist until it is abused.
NHIMG editorial — based on research published by Astrix Security
Questions worth separating out
Q: How should security teams govern OAuth apps that have access to developer systems?
A: Security teams should treat OAuth apps as privileged NHIs and inventory them continuously, not just at approval time.
Q: Why do NHIs create a larger attack surface than human users?
A: NHIs create a larger attack surface because they are numerous, persistent, and often granted broad access to automate work across systems.
Q: What is the difference between access review and true NHI governance?
A: Access review checks whether an identity still exists and whether its permissions look acceptable at a point in time.
Practitioner guidance
- Inventory every delegated OAuth connection Build a live list of all OAuth apps, service accounts, tokens, browser extensions, and automation workflows across GitHub, Google Workspace, Slack, Chrome, Microsoft 365, and Jira.
- Map downstream access paths for each integration For every third-party app, document which repositories, deployment systems, secrets stores, and collaboration tools it can reach.
- Classify integrations by privilege and exposure Separate read-only from write-capable, production from non-production, and internal from externally linked identities.
The governance question is no longer whether an integration exists, but how much of the environment it can expose if it is abused?
👉 Read Vercel's incident analysis on compromised OAuth access and NHI exposure →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/05/2026 12:39 pm
A few things worth adding from our research at NHI Mgmt Group.
OAuth compromise is now an NHI governance problem, not just an application security problem. The article’s core pattern is that delegated access created a trust chain across multiple platforms, which is exactly where traditional IAM reviews become too shallow. If teams only assess the first approval step, they miss the downstream identities, tokens, and workflows that actually determine exposure. The practical conclusion is that OAuth app governance must be treated as part of the NHI control plane.
A few things that frame the scale:
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to the same report.
A question worth separating out:
Q: When does an OAuth integration become too risky to keep?
A: An OAuth integration becomes too risky when its purpose is unclear, its permissions are broader than its function, or no one can confirm who approved it. It also becomes high risk when it can reach secrets, production systems, or repositories. In those cases, the control should be removal first, not monitoring first.
👉 Read our full editorial: OAuth app compromise shows the real NHI risk in Vercel integrations
