Shadow AI is expanding enterprise attack surface through browser trust

At a glance

What this is: This analysis argues that Shadow AI is no longer just unsanctioned app use, but a browser-mediated trust problem created by AI apps, extensions, and OAuth integrations.

Why it matters: IAM and security teams need to govern the browser session itself because AI tools now connect users, data, and downstream SaaS in ways that expand access risk beyond approved app lists.

By the numbers:

• The average organisation has 16 unique AI apps in active use, according to Push Security.
• The average organisation has 17 unique AI browser extensions in active use, according to Push Security.
• The average organisation has 17 unique AI OAuth integrations connected into Google Workspace and Microsoft 365, according to Push Security.
• At the highest end of the dataset, some organisations reached 163 AI browser extensions, according to Push Security.

Context

Shadow AI is not just a software adoption problem. It is an identity and access governance problem that begins in the browser, where employees approve apps, extensions, and integrations outside security team visibility. In practice, that means the control plane for AI usage is already distributed across users, sessions, and third-party connections.

The article's core point is that AI tools are becoming focal integration points in the enterprise stack, not isolated apps. Once a browser session can grant OAuth access, pull data from one SaaS platform, and act on another, the trust boundary shifts from sanctioned software to unmanaged delegation paths. That is why Shadow AI now behaves more like shadow SaaS with higher interconnectivity and larger blast radius.

The governance gap is larger than a simple allowlist problem. Even when organisations approve one AI platform, employees may still use personal accounts, shadow browser extensions, and forgotten OAuth grants that survive password resets and MFA changes. Typical policy controls do not see those trust relationships, which leaves the broader SaaS estate exposed.

Key questions

Q: What breaks when employees self-authorise AI tools in the browser without security review?

A: The control that breaks is governance by approval list. Browser-based self-service creates app, extension, and OAuth trust relationships outside the security team's view, so access expands through delegated permissions rather than centrally managed entitlements. That leaves identity, data, and session controls unable to see the full trust chain.

Q: Why do OAuth integrations increase AI security risk?

A: OAuth turns access into a delegated relationship that can persist across applications and data sets. When AI features use those grants, the permissions often exceed what any human would approve interactively, which increases exposure if the integration is mis-scoped, forgotten, or reused across environments.

Q: What are the signs that shadow AI controls are failing in practice?

A: Shadow AI controls are failing when sensitive data moves through copy-paste, uploads, or API calls outside sanctioned workflows, yet the organisation has no alerting or enforcement at the point of transfer. Other warning signs include heavy personal account use, unclear approved-tool lists, and developers submitting source code or internal structures to external AI services without review.

Q: How should security teams govern browser-based AI agents in SaaS environments?

A: Security teams should govern browser-based AI agents as runtime actors, not as ordinary users or static integrations. Give each agent a distinct identity, constrain what it can do in-session, and monitor browser, identity, and SaaS logs together. The key control is not just login validation, but continuous authorization of live actions.

Technical breakdown

Why browser sessions have become the trust boundary for Shadow AI

Browser-based AI usage changes the access model because the browser is now where prompts, consent grants, extension permissions, and token reuse converge. A user can approve an AI app, install an extension, and connect SaaS accounts without any separate security workflow. That creates a stack of delegated trust inside one session, with each layer able to expand access to data and connected applications. The risk is not just the app itself, but the combination of browser permissions, user consent, and persistent OAuth tokens that outlive the session context that created them.

Practical implication: security teams need session-level visibility into AI tool use, consent, and token-bearing connections, not just sanctioned app inventories.

Why AI extensions are an identity risk, not just a browser add-on problem

AI browser extensions often operate with broad privileges inside the browser, including access to page content, cookies, and session tokens. That makes them identity-adjacent control points because they can act on behalf of the user across multiple web applications. The article notes that many extensions can support account takeover without user interaction, which means the extension permission set can become the real authorization layer. Once installed, these tools can observe or manipulate the same authenticated browser context that users rely on for SaaS access.

Practical implication: teams should treat extensions as governed software with explicit allowlisting, review, and removal processes.

How OAuth turns Shadow AI into persistent downstream access

OAuth connections are the most dangerous dimension because they create programmatic trust relationships that persist beyond a login session. When an AI tool is granted access to Google Workspace, Microsoft 365, Salesforce, or similar platforms, it can retain scoped access through tokens that survive password resets and MFA changes. The article's Vercel example shows how a forgotten third-party integration can become a pivot point into internal dashboards, API keys, and source control tokens. This is classic delegated-access risk, but amplified by AI tools that need broad integration to function.

Practical implication: consent grants, token scope, and dormant integrations need continuous audit across the full SaaS estate.

Threat narrative

Attacker objective: The attacker wants to convert a single unmanaged AI trust relationship into persistent access across connected SaaS applications and the sensitive data they expose.

1. Entry occurs when an employee self-authorises an AI app, extension, or OAuth integration inside a browser session outside security team oversight.
2. Credential or token exposure follows when the approved connection stores scoped access that can be reused across sessions or harvested by a compromised third party.
3. Escalation happens when that trust relationship is used to access connected SaaS platforms, internal dashboards, files, or developer tokens with the user's delegated permissions.
4. Impact is achieved by widening the blast radius across multiple downstream applications, turning one forgotten consent grant into broader data and access compromise.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is now a browser-governed identity problem, not an application inventory problem. The article shows that app approvals, extension permissions, and OAuth grants now happen inside the same user-controlled session. That collapses the old separation between software discovery and access governance. The implication is that programmes built only around sanctioned app lists are already behind the real control boundary.

Persistent OAuth consent is the trust debt that Shadow AI introduces into SaaS estates. Every unmanaged integration creates a standing delegation path that survives login hygiene and account resets. That makes the blast radius of one approval much larger than most teams assume, because the token continues to operate after the original browser session is gone. Practitioners need to recognise consent as a lifecycle event, not a one-time user action.

Shadow extensions turn the browser into a privilege layer with its own governance model. Extensions that can read content, access tokens, and manipulate pages are effectively sitting on top of the user's SaaS identity. That means browser governance and identity governance are now coupled, especially when extensions are used to move data between AI tools and core enterprise apps. Security teams should treat extension risk as part of identity surface management, not as an endpoint footnote.

Browser-layer controls are becoming the only enforceable boundary for AI use at scale. The article makes clear that secure web gateways and app-level policy alone cannot tell whether a user pasted source code into an AI prompt or connected an unapproved integration. That visibility gap is the practical reason browser telemetry is rising in importance. The field now needs governance that sees prompts, consent, and tokens together.

Shadow AI expands the identity blast radius because AI tools increasingly sit at the centre of delegated access chains. When an AI assistant connects to several SaaS platforms, each new grant widens the effective trust graph. That changes the governance question from whether the tool is approved to how far its delegated access can reach. Practitioners should map trust paths, not just catalogue tools.

From our research library:

• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Shadow AI is becoming a trust-graph problem before it is a model-governance problem. When browser sessions can approve extensions, OAuth grants, and personal-account access in the same workflow, the practical control point shifts to delegated access paths. Teams that do not inventory those paths will keep mistaking adoption for sanctioned use.

Browser visibility is now a prerequisite for enforceable AI policy. Secure web gateways can show that a user visited an AI site, but they cannot show what data was pasted, what tokens were issued, or which SaaS systems were connected. That gap is why browser-layer telemetry is becoming central to AI governance.

For practitioners

• Inventory AI usage by browser session Establish a baseline of which AI apps, extensions, and OAuth integrations employees are actually using, and tie each one back to the account and browser session that granted access.
• Allowlist browser extensions with explicit review Block unapproved AI browser extensions by default, then maintain a vetted allowlist for tools that have been assessed for permission scope, publisher identity, and update behaviour.
• Audit OAuth consent grants across the full SaaS estate Review AI-related consent grants in Google Workspace, Microsoft 365, and the broader SaaS estate, then remove dormant or forgotten integrations that still hold persistent tokens.
• Apply browser-layer controls to prompt and token activity Use browser telemetry to see prompt submission, extension execution, and token-bearing actions in the same workflow, because app-level controls cannot reconstruct that sequence on their own.
• Treat personal accounts on corporate devices as a governance risk Detect when approved AI platforms are accessed through non-corporate accounts, because shadow tenants bypass the retention, DLP, and admin oversight applied to sanctioned tenants.

Key takeaways

• Shadow AI is expanding enterprise attack surface because employees are creating browser-level trust relationships that outgrow traditional app approval models.
• The article's evidence points to widespread sprawl, including 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations on average.
• The practical response is to govern consent grants, extension permissions, and browser sessions as part of one identity and access control surface.

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.
• 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: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Browser Layer Governance: Browser layer governance is the control of identity, access, and data activity at the browser session rather than only at the application or network perimeter. It is increasingly relevant for AI because prompts, extension permissions, and OAuth approvals all happen in the browser.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.