Notifications
Clear all
Topic starter
01/08/2026 10:44 pm
TL;DR: A self-adopted consumer AI tool with broad Google Workspace OAuth scopes created the trust bridge that enabled the Vercel breach, according to Unixi's analysis of the 2026 incident. The governance failure was not token theft alone but allowing corporate identity to be delegated to an unreviewed AI application before any security control intervened.
NHIMG editorial — based on content published by Unixi covering the Vercel OAuth breach and Shadow AI identity risk: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams control self-adopted AI apps before they become trusted access paths?
A: Start by moving control to the adoption moment.
Q: Why do unreviewed OAuth grants create more risk than a normal SaaS login?
A: Because the grant can hand a third-party tool durable, scope-based access to corporate data and workflows.
Q: What do security teams get wrong about shadow AI governance?
A: They often treat shadow AI as a banned-app problem when it is usually an identity and accountability problem.
Practitioner guidance
- Gate AI app adoption at the consent point Inspect browser-side login and consent events so broad-scope OAuth grants to unapproved AI tools can be blocked or routed for approval before the token is issued.
- Classify self-adopted AI tools as governed access paths Add consumer AI apps to the approved application ecosystem and assign ownership for review, scope restriction, and revocation when usage falls outside policy.
- Review third-party OAuth grants as lifecycle assets Inventory existing OAuth relationships, identify who authorised them, and remove access paths that no longer have a clear business owner or current security approval.
What's in the full article
Unixi's full post covers the operational detail this post intentionally leaves for the source:
- Browser-extension detection logic for self-adopted AI applications at the point of login
- Step-by-step policy workflow for classifying, restricting, or blocking unapproved AI tools
- The breach timeline mapping from adoption to OAuth grant to downstream compromise
- How the model applies to MCP and other integration paths once a tool is in the approved ecosystem
👉 Read Unixi's analysis of the Vercel Shadow AI breach path →
Shadow AI identity bridges: what IAM teams should gate at adoption?
Explore further
01/08/2026 10:53 pm
Shadow AI is an identity governance failure before it is a security incident. The central mistake is assuming that only sanctioned applications can become part of the enterprise control plane. Once an employee delegates corporate identity to an unreviewed AI tool, the organisation has already accepted a new trust relationship outside normal lifecycle controls. The practical conclusion is that app adoption has to be governed as identity creation, not as a post-hoc SaaS hygiene issue.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 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 an employee uses an AI tool to trigger harmful access?
A: Accountability stays with the organisation's identity governance and control owners, because the risky behaviour arises from delegated access paths that the business permitted. The right question is whether the delegation chain, review process, and containment controls were defined for AI-assisted execution. The NHI Lifecycle Management Guide is a useful reference for that governance.
👉 Read our full editorial: Shadow AI identity bridges are the real enterprise breach path
