Shadow AI identity bridges are the real enterprise breach path

At a glance

What this is: This is an analysis of how Shadow AI becomes an identity attack path when employees grant unreviewed AI tools corporate OAuth access.

Why it matters: It matters because IAM, IGA, and NHI teams need to control the adoption moment, not just detect abuse after third-party access has already been established.

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.

👉 Read Unixi's analysis of the Vercel Shadow AI breach path

Context

Shadow AI creates an identity problem before it becomes a data problem. When an employee authorises a consumer AI application with corporate credentials, the organisation has already created a third-party trust relationship that may sit outside procurement, review, and lifecycle governance.

In a Vercel-like scenario, the risky moment is not the later compromise of the AI service. It is the initial OAuth grant that converts a browser login into delegated access across corporate systems. That pattern sits squarely in the overlap between human identity behaviour, NHI-style third-party access, and governance controls that were designed for approved applications rather than self-adopted ones.

The primary failure is not visibility after the fact. It is the absence of a control point at adoption, where identity delegation can be approved, blocked, or routed for review before the bridge exists.

Key questions

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. Detect the login or consent event, classify the application against an approved ecosystem, and block or route high-risk OAuth grants before a token is created. That prevents a user from turning a consumer AI tool into an enterprise trust bridge without review.

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. Unlike a simple authentication event, OAuth creates delegated authority that may persist after the original user interaction, so an unreviewed grant can become a standing bridge into identity and data systems.

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. Employees can use approved tools, personal accounts, or embedded AI features in ways that bypass policy even when the app itself is not explicitly blocked. Governance has to follow the interaction, not just the endpoint.

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.

Technical breakdown

OAuth consent turns a login into delegated trust

OAuth is often treated as a convenience layer, but in practice it is an identity delegation mechanism. A user grants scopes, and the application receives tokenised access that can persist beyond the original interaction. In Shadow AI scenarios, broad consent can create a standing bridge from a third-party AI tool into email, files, calendars, or admin-adjacent workflows. The security problem is that the organisation may never have formally approved the application, yet the user’s consent still creates an authoritative access path. That makes discovery at the browser or login point materially different from later log analysis.

Practical implication: Treat OAuth consent as a governance event and gate broad-scope grants before the token exists.

Browser-based discovery catches self-adopted AI apps earlier

Traditional discovery methods miss much of Shadow AI because they look at network flows, SaaS inventories, or procurement records after the fact. Browser-level observation sees the adoption moment: the application name, the identity used, and the point at which a user attempts to connect corporate credentials to an unreviewed service. That matters because consumer AI tools often enter through informal use, not through sanctioned onboarding. Once discovered, the app can be classified, risk-scored, and routed into policy before it becomes part of the enterprise identity surface.

Practical implication: Place discovery controls where users actually adopt apps, not only where administrators later inventory them.

Lifecycle governance must cover third-party AI bridges

A third-party AI application connected through OAuth behaves like a governed identity relationship, even if it is not a service account in the traditional sense. It needs approval, review, scope limits, and revocation criteria. The key technical issue is lifecycle: who authorised the access, what data it can reach, how long it remains trusted, and when the relationship must be removed. Without that lifecycle view, AI tools accumulate privileged bridges that no one formally owns, especially when users self-adopt them outside standard onboarding paths.

Practical implication: Put AI app approvals, review, and revocation into the same lifecycle discipline used for other high-risk third-party access.

Threat narrative

Attacker objective: The attacker aims to exploit a trusted third-party identity bridge so corporate data and access tokens can be abused without starting from a direct compromise of the target organisation.

1. Entry occurred when an employee self-adopted a consumer-grade AI application and granted it broad Google Workspace OAuth access.
2. Escalation followed because the OAuth consent created a trusted bridge that allowed the compromised AI application to operate with corporate-authorised access.
3. Impact emerged when attacker-controlled access downstream of that bridge could be used to reach corporate data and related identity assets.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Klue OAuth Supply Chain Breach — OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Ungoverned OAuth consent creates what we call identity bridge debt. That is the growing inventory of third-party access paths created by user action but never brought under formal ownership, review, or revocation discipline. The debt accumulates because the granting event is easy, while the later cleanup depends on controls many organisations never wired into browser, consent, or application workflows. Practitioners should treat this as a lifecycle deficit across human identity and third-party access, not as a one-off exception.

Browser-observed adoption is the right control point for self-service AI use. The breach pattern shows that procurement records and delayed inventories are too slow to matter. What matters is whether the organisation can see the consent event before a consumer AI application becomes a trusted bridge into cloud identity. The implication is clear: identity governance must move upstream into the interaction layer where delegation actually happens.

Third-party AI access now behaves like NHI governance, even when a human initiates it. The user is the trigger, but the resulting access path is machine-mediated and persistent enough to require NHI-style lifecycle controls. That means approval, scoping, monitoring, and revocation need to be consistent across human actions that create non-human access. Security teams should stop treating the human click and the machine bridge as separate problems.

Shadow AI will keep expanding until organisations classify it as a governance domain, not an awareness problem. Awareness campaigns alone do not stop delegated trust relationships from forming. The field needs enforceable policy around unapproved AI apps, broad-scope OAuth grants, and lifecycle offboarding when a tool falls outside policy. Practitioners should reframe the issue as delegated-access governance across the identity lifecycle.

From our research:

• 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.
• For a broader lifecycle view, see Ultimate Guide to NHIs for the governance patterns that should extend to delegated AI access.

What this signals

Identity bridge debt: enterprises are accumulating third-party access paths created by user consent but never fully owned, reviewed, or retired. That debt will keep widening unless browser-level discovery and approval workflows are moved closer to the point of adoption, where the trust relationship is created.

The governance model has to treat self-adopted AI tools as lifecycle-managed access, not as casual productivity software. Once a consumer AI app receives corporate OAuth consent, the question is no longer whether the app is useful, but who owns the access, how it is recertified, and when it is removed.

For practitioners aligning to external guidance, the control gap maps naturally to the NIST Cybersecurity Framework 2.0 around protect and govern activities, and to the OWASP Non-Human Identity Top 10 where credential and trust management failures expand attack surface.

For practitioners

• 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.
• Tie AI governance to identity lifecycle controls Use the same approval, recertification, and offboarding discipline for AI app access that you already apply to other high-risk delegated identities.

Key takeaways

• Shadow AI becomes a breach path when employees can delegate corporate identity to unreviewed tools outside policy.
• The critical failure is upstream of token theft, because the OAuth bridge itself creates the trust an attacker later abuses.
• Teams need adoption-time governance, browser-level discovery, and lifecycle offboarding for third-party AI access paths.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Identity Bridge: An identity bridge is an integration layer that connects a legacy directory to modern applications, devices, or cloud services. It can preserve access during transition, but it also adds translation complexity, can obscure control paths, and often becomes a long-lived governance dependency.
• OAuth consent governance: OAuth consent governance is the discipline of approving, limiting, and revoking delegated application access created through OAuth authorisation. It matters because the user’s click can create machine-mediated access that outlives the original session and becomes part of the enterprise identity attack surface.
• Identity bridge debt: Identity bridge debt is the accumulation of third-party trust relationships that were created by users but never fully reviewed, owned, or retired. It is a lifecycle problem, not just a discovery problem, because each unmanaged bridge can extend corporate access to tools that no longer meet policy.

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

👉 The full Unixi post covers the browser-level detection flow and lifecycle control model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.