Shadow AI is expanding enterprise attack surface through browser trust

At a glance

What this is: Shadow AI has become a browser-governed identity problem, with unsanctioned apps, extensions, and OAuth links creating unmanaged access paths across enterprise SaaS.

Why it matters: IAM, NHI, and human identity teams need one control plane for browser-based trust because the same employee session can now expose accounts, tokens, and data across approved and unapproved AI tools.

By the numbers:

• The average organization has 16 unique AI apps in active use, 17 AI browser extensions, and 17 AI OAuth integrations.
• 45% of employees are now regular AI users on corporate devices, up from 15% the year before.
• 92% allow employees to use public GenAI applications.

👉 Read Push Security's analysis of shadow AI, browser extensions, and OAuth risk

Context

Shadow AI is the unmanaged use of AI applications, browser extensions, and connected integrations that employees adopt without formal approval or visibility. The problem is now less about a single unapproved chatbot and more about browser-mediated identity trust spreading across the SaaS stack, where the same user can create accounts, grant consent, and move data between systems without security oversight.

For identity programmes, the issue cuts across human access, NHI-like OAuth grants, and emerging agentic workflows that act through browser sessions. Once an AI tool becomes a connector into Google Workspace, Microsoft 365, or downstream SaaS, it starts behaving like an access hub rather than a standalone application, which changes the governance model from app approval to session-level control and consent governance.

Key questions

Q: How should security teams govern shadow AI in the browser?

A: Security teams should govern shadow AI at the browser layer, where users authenticate, consent, and move data between systems. That means inventorying apps, accounts, extensions, and OAuth grants together, then default-denying new integrations unless they are explicitly approved and monitored. Browser telemetry is the only place the full identity and data path becomes visible.

Q: Why do AI OAuth integrations create more risk than standalone AI app use?

A: AI OAuth integrations create more risk because they convert a simple app login into persistent delegated access across enterprise systems. If the integration is compromised, the attacker may inherit tokens that survive password resets and reach multiple SaaS apps, which expands the blast radius far beyond the original AI tool.

Q: What breaks when employees use personal accounts for approved AI tools?

A: When employees use personal accounts for approved AI tools, enterprise policy controls no longer apply consistently, even if the application itself is sanctioned. Retention, DLP, admin visibility, and tenant-level controls can be bypassed, so the organisation sees activity in the platform but cannot govern it as corporate usage.

Q: How should teams reduce the blast radius of AI-driven SaaS access?

A: Teams should reduce blast radius by classifying every AI connection by the downstream systems it can reach, then removing unnecessary OAuth scopes and inactive grants. The goal is to limit how far a single compromised AI tool, extension, or user consent can travel across the SaaS estate.

Technical breakdown

Shadow AI apps, tenants, extensions, and integrations

The article separates shadow AI into four mechanisms because each one changes the trust boundary differently. Shadow apps are unapproved AI services. Shadow tenants occur when users access approved tools with personal accounts, bypassing enterprise policy. Shadow extensions run inside the browser with broad read and modify privileges. Shadow integrations are OAuth consents that create persistent programmatic access into enterprise apps. The technical point is that browser identity, account identity, and application identity are no longer aligned, so one session can carry multiple trust states at once.

Practical implication: Security teams need inventories for apps, accounts, extensions, and OAuth grants, not a single shadow AI list.

Why OAuth integrations create the largest blast radius

OAuth turns a user consent into a durable delegated access relationship. In AI toolchains, that relationship often spans multiple SaaS systems, so a compromise of the AI tool, its browser context, or a connected MCP-style workflow can expose tokens for several business apps at once. Because OAuth tokens survive password resets and often outlive the session that created them, the access path remains active even when the originating account changes state. This is why the article treats shadow integrations as the most dangerous category.

Practical implication: Treat consent grants as standing delegated privilege and review them like privileged access, not like simple app logins.

Browser extensions as hidden identity-capable software

AI extensions are dangerous because they operate with the browser's authority, not just the user's intent. Many can read page content, access cookies and session tokens, and interact with any web app visible to the user. That means an extension can observe or manipulate identity artefacts even when the underlying application is well controlled. The risk is amplified because popular extensions spread organically across employees, creating a large unmonitored software layer inside the browser.

Practical implication: Use default-deny allowlisting and monitor extension permissions before broad deployment.

Threat narrative

Attacker objective: The attacker aims to pivot from a forgotten AI consent grant into persistent access to enterprise SaaS data and credentials without needing a direct admin compromise.

1. Entry begins when an employee authorises an AI app, extension, or OAuth integration through a browser session, often without security approval or central visibility.
2. Escalation occurs when that consent creates persistent access to Google Workspace, Microsoft 365, or downstream SaaS, allowing the AI connection to reuse stored tokens across services.
3. Impact follows when a compromise of the AI app, browser extension, or connected identity path exposes internal dashboards, source code, API keys, or other sensitive enterprise data.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Browser session governance is now an identity problem, not just a web usage problem. Shadow AI lives inside the browser, where users authenticate, consent, upload data, and connect systems in one place. That means the control boundary has shifted from application inventory to session-level identity and delegated access oversight. For IAM teams, this is a signal that browser telemetry belongs in the identity programme, not only in endpoint or web security workflows.

Persistent OAuth consent has become a non-human identity problem hiding inside human activity. The moment a user grants an AI tool access to core SaaS, that consent acts like a delegated NHI relationship with standing privilege characteristics. Persistent consent debt: this is the accumulation of forgotten OAuth grants, personal-tenant connections, and lightly reviewed extensions that outlive the business purpose they were created for. Practitioners should treat the residual grant itself as the governance object.

Shadow extensions expose a control gap that traditional SaaS governance does not see. Many teams believe app approval is enough, but extension permissions can read cookies, modify content, and observe session tokens across every browser tab. That is a different failure mode from ordinary shadow IT because the software sits inside the trust boundary of the logged-in user. The implication is that extension governance must be tied to browser identity and permission scope, not only software allowlists.

The Vercel-style breach pattern proves that one forgotten consent can become a multi-system compromise. The attack path is not novel, but the scale of AI-connected SaaS makes it easier to repeat. When one AI tool holds tokens for multiple services, a single compromise can expose dashboards, source control, and API secrets without ever touching a traditional privileged admin account. Practitioners need to rethink blast radius as a consent-management problem.

Browser-based AI adoption is accelerating faster than enterprise review cycles can absorb. The governance model many programmes use assumes new software is discovered, approved, and then reviewed on a predictable cadence. Shadow AI breaks that assumption because employees can add apps, accounts, extensions, and integrations in hours. The practical conclusion is that identity governance must move closer to real-time consent visibility, or it will always trail the user's browser activity.

From our research:

• 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 with nearly 1 in 4 for securing human identities.
• For broader lifecycle governance, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding should be treated as one control surface.

What this signals

With 67% of GenAI users on corporate devices using non-corporate accounts, the control issue is no longer just unsanctioned software but unsanctioned identity context. Browser-based AI adoption is collapsing the gap between personal and corporate use, which means identity programmes need tenant-aware policy, session visibility, and stronger consent governance across the full SaaS stack.

Consent debt: forgotten OAuth grants, personal accounts, and over-permissioned extensions are accumulating faster than most review cycles can retire them. The immediate programme shift is toward real-time visibility and default-deny approval models, because the risk is not a one-off app download but a durable trust relationship that persists after the user stops thinking about it.

For practitioners

• Inventory AI activity across the browser layer Build a live register of AI apps, accounts, extensions, and OAuth integrations that are actually used in the browser. Separate corporate tenants from personal tenants so you can see where approved tools are being accessed through unmanaged identities.
• Default-deny new OAuth consent grants Require explicit approval for new consent grants in Google Workspace, Microsoft 365, and high-value SaaS apps. Review existing grants for long-lived tokens, broad scopes, and connections that no longer match a current business need.
• Apply allowlisting to AI browser extensions Approve only vetted extensions, block everything else, and re-check permission changes that would expand access to cookies, session tokens, or page content. Monitor for imitation tools that present themselves as official companions but are not.
• Treat AI integrations as blast-radius multipliers Map which AI tools can reach downstream SaaS systems and which tokens they hold. Prioritise the integrations that can touch source code, internal dashboards, or finance and customer data before they are forgotten or over-shared.

Key takeaways

• Shadow AI is now an identity and consent governance problem because the browser has become the control point for app access, data movement, and delegated trust.
• Persistent OAuth grants and over-privileged extensions create the largest blast radius, because one compromised AI connection can reach multiple enterprise systems.
• Practitioners should inventory browser-based AI use, default-deny new consent grants, and treat extension permissions as part of identity governance, not just endpoint hygiene.

Key terms

• Shadow AI: AI applications, browser extensions, or connected integrations that employees use without formal approval or security visibility. In practice, it includes both obvious unapproved tools and approved tools being accessed through personal accounts or unmanaged consent grants, which makes governance harder than standard shadow IT.
• Shadow Tenant: A separate account context inside an otherwise approved platform, usually created when an employee uses a personal account instead of the corporate tenant. It looks legitimate from the application side, but it sits outside enterprise policy, retention, and monitoring controls, which creates hidden governance gaps.
• OAuth Consent Grant: A user-approved permission that lets one application access data or actions in another application on the user's behalf. For identity teams, it functions like delegated standing access, because the grant can persist after login sessions end and can survive routine password or MFA changes.
• Browser Extension Governance: The control practice of inventorying, approving, restricting, and monitoring browser add-ons based on the permissions they hold and the data they can reach. For AI use cases, extension governance matters because extensions can read session data, modify content, and observe nearly everything a user sees in the browser.

Deepen your knowledge

Shadow AI browser governance and OAuth consent risk are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to align browser activity, delegated access, and identity controls, this is a relevant place to start.

This post draws on content published by Push Security: shadow AI telemetry and the four categories of unmanaged AI risk. Read the original.