Why Browser Extensions Became Shadow AI's Blind Spot

Most shadow AI governance programs are chasing the wrong artifact. They inventory apps, they classify vendors, they ask procurement to flag anything with "AI" in the product description. None of that touches the thing moving data out of the enterprise right now. A browser extension sitting quietly in the toolbar, already logged in as the employee, already trusted by every system that employee touches.

That is the uncomfortable finding inside the Cloud Security Alliance's April 2026 research note on AI browser extensions. The research found that 53 percent of enterprise users now run at least one browser extension carrying high or critical permission scopes, the kind that can read cookies, capture passwords, and see the full contents of every page the user opens. Fifty-three percent of users, not of companies. In an organization of five thousand employees, that is thousands of people carrying a silent second login into every SaaS tool they use.

Here is the part that should change how security teams think about this category. An AI browser extension does not need to steal a credential. It is handed one, automatically, every time the user opens Gmail, Salesforce, Workday, or the internal wiki, because the extension executes inside the same browser tab as an already-authenticated session. The access problem is not detection. It is that nobody ever decided this tool should have access in the first place, and no control in the stack was built to ask.

The same research note cites a separate survey wave in which 80 percent of organizations had already encountered risky behavior from an AI agent of some kind, work the CSA attributes to Netwrix. Only 37 percent had adjusted their security strategy in response. That gap, between what security leaders fear and what their programs have changed, is where this post lives.

Key Takeaways

  • The extension inherits the session, it does not request one. A browser-based AI tool operates inside the user's already-authenticated tab, which means it carries the user's cookies and trusted identity into every site it touches without ever triggering a separate login or access review.
  • Fifty-three percent of enterprise users carry high-risk extension permissions. Research cited by the Cloud Security Alliance puts over half of enterprise browser users on extensions with scopes broad enough to read passwords, cookies, and full page content, not a fringe behavior but a majority one.
  • Two 2026 incidents moved from theory to scale. A hijacked Urban VPN Proxy update reached more than 8 million users across nine extensions, and a separate campaign impersonating ChatGPT and Claude clients reached over 900,000 installs before researchers caught it.
  • DLP, CASB, and EDR were not built to see inside a browser tab. These controls inspect file transfers, email attachments, and network anomalies. An extension reading the DOM and exfiltrating over ordinary HTTPS traffic generates nothing that looks unusual at any of those layers.
  • Governance must move to the point of use, not the point of procurement. Blocking extensions at the device management layer catches sanctioned software. It does nothing for an extension already installed, and it does nothing at all for the data once it has left the page.

The Access Problem Nobody Named Until Now

Enterprise security has spent a decade building identity programs around a simple question. Who is this, and what should they be allowed to touch? Single sign-on, multi-factor authentication, conditional access policies, all of it assumes the thing requesting access is a known actor making a discrete request. A browser extension breaks that assumption at the root. It is not a new identity requesting new access. It is a passenger riding inside an identity that already cleared every gate.

The permission model makes this almost comically explicit. The CSA researchers note that the browser extensions driving the riskiest behavior typically request a short, familiar list of scopes: tabs, activeTab, scripting, cookies, and the host permission that Chrome labels simply as access to "all websites." The cookies permission is the one worth sitting with. It does not grant access to a file or a folder. It grants access to the session tokens that authenticate the user to every cloud service that tab touches, which is functionally the same as holding a live, valid login credential for Salesforce, SharePoint, or the company bank portal, without ever typing a password.

Put that mechanism next to how most enterprises still think about shadow AI and the mismatch gets sharper. A typical shadow AI inventory asks which unsanctioned apps employees have signed up for with a work email. That question catches ChatGPT accounts and rogue API keys. It does not catch an extension an employee installed from the Chrome Web Store on a Tuesday afternoon because it promised to summarize their inbox, which then sat quietly reading every page they opened afterward. Access control built around named applications has nothing to say about a passenger process.

Two Incidents That Moved This From Theory to Scale

Skeptics of the browser extension threat model tend to ask for a real number, not a hypothetical. 2026 supplied two.

The first involves Urban VPN Proxy, an extension installed by millions of users for an entirely different purpose than AI. In July 2025, the extension pushed version 5.5.0 as an automated silent update, the kind users never see and never approve individually. That update quietly added code built to harvest data tied to eight separate AI platforms, including ChatGPT, Claude, Gemini, Microsoft Copilot, Perplexity, DeepSeek, Grok, and Meta AI. More than 6 million Chrome users and 1.3 million Edge users, roughly 7.3 million people, had the extension installed before the update shipped. When researchers traced the same harvesting code into seven additional extensions from the same publisher, the combined affected user base crossed 8 million. The disclosure came in December 2025, more than five months after the silent update went out.

Five months is the number that should bother a CISO more than the user count. A credential-theft campaign that runs undetected inside browsers for five months is not a near-miss. It is a demonstration that nothing in the enterprise security stack was looking in that direction at all.

The second incident, disclosed by OX Security in January 2026, is smaller in scale but more deliberate in design. Two Chrome extensions, marketed under names like "Chat GPT for Chrome with GPT-5, Claude Sonnet & DeepSeek AI" and "AI Sidebar with Deepseek, ChatGPT, Claude, and more," positioned themselves directly as the AI assistants employees were already searching for. Between them they reached a combined install base exceeding 900,000 users. The extensions exfiltrated data to two command-and-control domains every 30 minutes, while their own privacy disclosures claimed they collected only "anonymous, non-identifiable analytics data." The gap between that disclosure and the actual behavior is the entire shadow AI governance problem compressed into one sentence.

Neither incident required a sophisticated attacker to breach a perimeter. Both required nothing more than an employee clicking install on a tool that looked like the one their colleague was already using.

Separate research from Cato Networks, published under the name HashJack, mapped six distinct risk categories tied to this same attack surface, covering callback phishing, credential theft, misinformation, malware guidance, medical harm, and data exfiltration carried out through agentic workflows. That range matters because it moves the conversation past simple data theft. An AI assistant with browser-level access becomes a channel an attacker can manipulate directly, feeding it poisoned page content and letting the assistant's own trusted access carry out the rest of the attack on the attacker's behalf. The pattern keeps repeating across vendors because the underlying mechanism, an AI tool inheriting a user's trusted session, is the same regardless of which company built the assistant.

Why DLP, CASB, and EDR Never Saw It Coming

Every major enterprise has invested in data loss prevention, cloud access security brokers, and endpoint detection and response, and every one of those controls has a structural blind spot in exactly this spot. DLP tools were designed to inspect file transfers, email attachments, and recognizable structured data leaving through known channels. A browser extension reading page content through the DOM and transmitting it over standard outbound HTTPS does not produce a file transfer, an attachment, or a flagged data pattern. It produces traffic that is indistinguishable from the user simply browsing the internet.

CASB tools fare no better, because their visibility is built around sanctioned cloud applications and the API-level activity those applications generate. An extension is not a cloud application in that sense. It is a piece of code running client-side, inside the browser's own execution context, several layers below where a CASB is watching. EDR tools, meanwhile, are tuned to catch process-level anomalies on the endpoint. A browser extension operating entirely within the sanctioned, signed browser binary rarely trips an EDR rule designed to flag an unrecognized executable.

This is the gap the CSA note describes directly. These controls "have limited or no native visibility into DOM-level browser extension behavior," and exfiltration carried over ordinary HTTPS generates no anomaly detectable at the network perimeter. It is not that these tools are poorly configured. It is that they were never pointed at this layer, because the layer barely existed as a meaningful risk until browser-native AI assistants made it the easiest, lowest-friction way for an employee to get AI help inside their actual workflow.

Microsoft has effectively confirmed the scale problem from its own vantage point. The company reported browser extension-related AI risk activity active across more than 20,000 enterprise tenants, a figure large enough that it stopped being an edge case inside Microsoft's own telemetry. The company's response, inline data loss prevention through Microsoft Purview inside Edge for Business, announced at RSAC 2026, is a genuine step forward. It is also an admission that the fix must live inside the browser itself, because nothing sitting outside it can see what is happening.

What Must Change

Treating this as a procurement problem, something solved by a longer list of banned extensions pushed through Intune, Google Workspace Admin Console, or Jamf, mistakes the symptom for the disease. Block one extension and the same employee installs a near-identical one under a different name the following week, exactly as the OX Security campaign demonstrated by cloning the branding of tools people were already searching for. Device management policy can reduce the surface. It cannot govern what happens to data once an approved, even useful, extension is already reading it.

The frameworks built for this moment already exist, and they start from a premise device management policy does not share. Zero trust means no tool or agent is implicitly trusted based on user identity and network location alone, including a tool that happens to be riding inside that user's own browser session. An extension asking for cookie access and full page content is making an access request as real as any API call, and it deserves the same scrutiny, covering what data it can touch, what it can do with that data, and who reviews that scope before it ships to the entire workforce.

That scrutiny must happen at the point where the data lives and moves, which is the content itself, not the application wrapper around it. An entity-aware enforcement layer that understands what a piece of content is, who is requesting it, and why, can apply a control at the moment a browser-based AI tool tries to read a customer record or a legal contract, regardless of whether that tool ever appears on an approved-software list. Contextual Data Enforcement is built around exactly that premise. Govern the data at the point of use, so the control does not depend on having named and approved the tool in advance.

Shadow AI security programs built for this threat model specifically account for browser-based AI tools as their own category, distinct from sanctioned enterprise AI deployments, because the governance question is different. The question is not whether to approve ChatGPT for the finance team. It is whether any extension, approved or not, should be able to read a spreadsheet full of unreleased earnings data the instant finance opens it in a browser tab.

The pattern matches what Kiteworks has already documented across the broader shadow AI identity gap. The riskiest access in most enterprises today belongs to tools that were never issued a formal identity at all, which means no identity governance program ever reviewed them. Shadow AI governance research has already established that this is not primarily a DLP problem, because DLP assumes a known data flow to inspect. A browser extension reading a page in real time is not a flow. It is a point-in-time access event, and it needs a control built for that shape of risk.

The credential-theft angle deserves one more comparison, because it is not unique to browser extensions. The same pattern, a trusted tool inheriting access it was never individually vetted for, shows up when a third-party AI tool quietly opens the door to systems nobody meant to expose, and again when Codex authentication tokens were stolen through a supply chain compromise that relied on exactly this kind of implicit trust. Each incident looks different on the surface. Underneath, they are the same failure. Access granted by inheritance rather than by decision.

Security teams that have internalized the AI policy gap findings, that roughly nine in ten employees already use AI tools while only a quarter of organizations have written rules governing that use, should treat browser extensions as the sharpest version of that gap, not a separate problem. An employee does not need written permission to install an extension. They need five seconds and a Chrome Web Store listing that looks legitimate. Governing shadow AI well means accepting that employees will keep finding these tools faster than any approval process can review them, then building the control around the data those tools touch instead of trying to win a race against installation speed.

For teams managing a mixed estate of Microsoft 365, Google Workspace, file stores, and browser-based tools at once, the practical answer is a unified policy layer rather than a separate point solution for each surface. A policy written once, for a type of content, should apply whether that content is opened in SharePoint, pasted into a Copilot prompt, or read by a browser extension nobody in IT has ever heard of. AI assistant data exposure research makes the same point from the opposite direction. Once an AI tool can see your content, the application layer stops being where the real control must live.

A companion piece on this blog already tracked the shift from desktop shadow AI to browser-based shadow AI, and the trajectory has not reversed since. If anything, the incident count from the past year confirms the direction was right and the pace was faster than most security programs budgeted for. Blocking known extensions one at a time, the approach most enterprises are still running, repeats a pattern documented elsewhere on this blog. It blocks today's list and leaves tomorrow's extension invisible.

None of this is an argument against browser-based AI tools themselves. Employees reach for them because they solve a real, immediate problem faster than filing an IT request. The argument is that the access model underneath those tools must be governed with the same rigor applied to any other identity touching sensitive data, and that governance must happen at the content layer, because that is the one layer every one of these tools eventually must pass through.

Frequently Asked Questions

1. What permissions make a browser extension high risk for enterprise data?

The highest-risk combination includes cookies access, the activeTab and scripting permissions, and the broad host permission covering all websites. Cookies access is the most consequential of these because it exposes the session tokens that authenticate a user to cloud services, which functionally hands the extension a live, valid login rather than requiring it to steal or guess a credential separately.

2. Can traditional DLP tools detect data leaving through a browser extension?

Generally not in real time. DLP tools are built to inspect file transfers, email attachments, and structured data moving through recognized channels. An extension reading page content through the browser's DOM and transmitting it over ordinary outbound HTTPS does not generate a file transfer or an attachment, so it produces no signal that conventional DLP is positioned to catch.

3. How is a browser AI extension different from a sanctioned enterprise AI tool?

A sanctioned tool goes through a procurement and security review before deployment, typically with a defined data processing agreement and a named identity in the access management system. A browser extension usually arrives through self-service installation from a web store, inherits the user's existing session rather than requesting its own credentials, and in most organizations never passes through any formal review at all.

4. What should security teams do first about this risk?

Start by inventorying installed extensions across managed browsers using the enterprise management console already in place, whether that is Microsoft Intune, Google Workspace Admin Console, or Jamf, and flag any extension with cookie or all-sites permissions. Pair that inventory with a content-level control that governs what sensitive data can be read or acted on regardless of which tool is doing the reading, since the extension list will keep changing faster than any approval process can track.

5. Is blocking AI browser extensions at the device level enough?

No. Blocking known extensions reduces exposure from tools already identified as risky, but it does nothing for extensions not yet flagged and nothing at all for data already read before a block takes effect. Durable governance requires a control at the point where sensitive content is accessed, so that even an unrecognized or newly published extension cannot read content it has not been authorized to see.

To learn more about governing AI access to sensitive data, schedule a custom demo.