Browser-Based AI Extensions and Enterprise Data Leakage

Browser extensions don't ask permission each time they need it. They get it once, at install, and then they run continuously, inside the browser's own runtime, for as long as the extension stays installed, with no further checkpoint at which that access is reviewed. That's the architecture, not a bug in it. An extension sits next to every tab a user opens, reading page content, form inputs, session cookies, and keystrokes as a matter of normal operation. AI extensions push this further than any category before them, because summarizing a contract or rewriting an email requires reading the whole page, not a slice of it. The access is used continuously. It's used.

Three permissions do the real damage: cookie access, scripting, and tab management. Cookies hold session tokens and login state, so reading them means an extension can effectively impersonate the user's active sessions. Scripting permission allows code injection and input capture, which is a fancy way of saying an extension can watch what someone types before it's even submitted. Tab management lets an extension redirect a user silently, without them leaving what feels like their normal workflow. According to the LayerX Enterprise Browser Extension Security Report, AI extensions request cookie access at three times the average rate, scripting at roughly two and a half times, and tab management at twice the rate of extensions generally, a permission footprint far beyond typical extensions. That's a direct consequence of the permission profile involved. It's the permission profile of a tool built to read everything and act on what it finds.

The Chrome Web Store's governance model and its failure to catch what those permissions enable

The Chrome Web Store review process checks for obvious red flags at the moment of submission. It cannot catch behavior that only appears after installation, or that only occurs under specific conditions the reviewer never triggers. That's a design limit, not a staffing problem, and it's exactly the seam malicious AI-impersonation extensions have learned to thread.

The AITOPIA campaign from January 2026 shows how cleanly this seam opens. OX Security researchers found two Chrome extensions impersonating the legitimate AITOPIA AI assistant, together pulling in a substantial install base before anyone caught on. The extensions scraped the DOM to pull complete ChatGPT and DeepSeek conversation histories and ship them off to attacker-controlled domains at regular intervals. Their privacy disclosures claimed they only collected "anonymous, non-identifiable analytics data." They passed automated Chrome Web Store review because the malicious functionality stayed dormant during evaluation and only switched on later. And because the exfiltration traffic ran over standard HTTPS, it looked like any other encrypted traffic to enterprise network monitoring, which had nothing unusual to flag.

Urban VPN Proxy, from July 2025, shows a second way the same governance model fails. This wasn't an impersonator. It was a legitimate, already widely installed extension that quietly introduced data-harvesting code in a routine version update, 5.5.0, affecting more than 8 million users across Chrome and Edge. It intercepted AI conversations across ChatGPT, Claude, Gemini, Microsoft Copilot, Perplexity, DeepSeek, Grok, and Meta AI, and sold that data to advertisers without anything resembling meaningful re-consent from the people who'd installed it in good faith. Same outcome as AITOPIA, different route in: one arrived malicious, the other became malicious.

What ties both cases together is that the extension looked fine to the user, fine to the store's automated review, and fine to enterprise network monitoring, all at once. That's a structural weakness across three separate checkpoints, not a lapse at any one of them. And the signals enterprises might lean on to judge trustworthiness aren't much help either: per the LayerX report, a large share of AI extensions publish no privacy policy at all, and close to half haven't cleared any install threshold that would suggest real-world vetting by other users. None of that is enforced by the store as a requirement. It's just noise dressed up as a signal.

Data traveling through an AI extension during a normal workday

The leakage channel AI extensions open up doesn't look like the ones DLP was built around. There's no file attachment, no API call, no email to flag. It's page content moving silently through a privileged extension layer that sits above all of that plumbing.

Internal process documents. Product roadmaps. Strategic plans still in draft. Code snippets, configuration data, and, worse, API keys pasted in because someone wanted a quick sanity check. Drafts of legal or commercial language that haven't cleared review. Customer details, incident notes, the kind of operational texture nobody would dream of forwarding in an external email but will happily paste into a chat box that promises to summarize it faster. One well-placed prompt can carry enough detail to expose intellectual property or create regulatory exposure, without anyone thinking of it as a disclosure.

Developer environments raise the stakes further. High-privilege API keys sitting locally in tools like Cursor IDE are reachable by any installed extension, regardless of that extension's stated permissions scope. The CursorJacking vulnerability, disclosed in February 2026 with a CVSS score of 8.2 per LayerX, proved this without requiring any action from the user at all, and as of late April 2026, Cursor had shipped no patch and no architectural fix. Cursor's maker, Anysphere, responded by framing extensions as sharing the same trust boundary as any local application, and put the burden of vetting on the user. That's a coherent position if the problem really is behavioral. It's a weaker one if the problem is architectural, which is the argument this piece is making throughout.

Not every case involves carelessness. Early in 2026, a government official at CISA, someone with security training, accidentally released restricted CISA operational data through a public AI tool. Call it a mistake, not negligence. The architecture made it possible simply by how these tools consume whatever's put in front of them. OWASP's Top 10 for LLMs, from 2025, ranks Sensitive Information Disclosure as LLM02, and the risk runs both directions: unauthorized access, privacy violations, and IP exposure can come through a model's outputs, not just through someone intercepting what went in.

Blind spots of traditional DLP, CASB, and endpoint controls inside the browser session

Enterprise security stacks were built around DLP, CASB, EDR, and SSE, and every one of them inspects processes, network traffic, or files. None of them inspect what happens inside a browser session at the exact moment an extension touches page content, grabs a keystroke, or pushes data out over HTTPS. That's three specific control failures, not one general shortfall.

DLP was built for channels you can actually inspect: an email attachment, a file transfer, a structured API call with a defined shape. Copy and paste from a confidential document into an AI prompt box leaves nothing DLP recognizes as an artifact. There's no attachment to scan, so there's nothing to catch. CASB works at the application boundary, checking what's allowed to talk to what. An extension running inside an already-approved browser session isn't a separate application CASB can see; it's infrastructure baked invisibly into a session the CASB already waved through. EDR, meanwhile, watches operating-system-level processes. An extension isn't a separate process. It runs inside the browser's own sandboxed execution context, a place EDR simply has no line of sight into.

The identity layer doesn't hold up any better on its own. LayerX's Browser Security Report 2025 found that over two-thirds of corporate logins bypass SSO entirely, which means identity-based controls can't even establish which accounts or sessions are active, let alone which extensions are running inside them. Akamai's 2026 Enterprise AI Usage Risk Report finds that nearly half of all AI conversations on enterprise devices flow through personal accounts that sit outside any audit trail.

To be fair, there's real progress happening at one layer. Microsoft Edge for Business, announced in November 2025 at Ignite with DLP capabilities highlighted again at RSAC 2026, applies existing enterprise DLP policy to Copilot and Agent Mode browsing. That's a genuine step forward. But its coverage stops at the edge of the approved browser session itself: it doesn't govern extensions installed inside that browser, and it has nothing to say about personal-account or unmanaged-browser activity happening elsewhere. A good lock on the front door doesn't help if the extension already has a key to the side entrance.

AI extensions that change permissions over time, turning one-time approvals into a moving target

Treating an approved extension as permanently safe assumes the extension stays the same. It usually doesn't. Extensions get updated, change hands between owners, and quietly expand what they're allowed to touch, and an enterprise security program built around a one-time allowlist has no natural way to keep pace with that kind of drift.

The LayerX Enterprise Browser Extension Security Report 2026 puts numbers on this. Across the board, a majority of enterprise users already have at least one extension, of any type, that changed its permissions within the past year, and AI extensions expand permissions at six times the average rate. An approval granted in January doesn't necessarily describe what's installed by December.

Urban VPN Proxy is the case that makes this concrete rather than abstract. Version 5.5.0 introduced conversation-harvesting code into an extension millions of people had already installed, trusted, and forgotten about, with no way for any of them to know the thing they'd approved had quietly become something else. Maintenance gaps push in the same direction from the opposite angle: roughly a fifth of AI extensions go unmaintained, per LayerX. Known vulnerabilities pile up unpatched while the extension stays installed and fully permissioned regardless. Nobody revokes access just because nobody's fixing bugs.

The signals an enterprise might actually use to judge an extension, install count, a published privacy policy, how often it's updated, who the publisher claims to be, aren't enforced by the store as requirements, and none of them are reliable on their own. AITOPIA proved that a high install count and a published privacy policy can sit right next to active data exfiltration without contradiction. The signals look like due diligence. They are not, despite the signals looking like due diligence. AI extensions are roughly six times more likely than average extensions to have increased their permissions over the preceding 12 months, turning one-time approvals into a moving target.

Autonomous AI agents inside the browser and the same architectural risk without per-step human oversight

AI browser agents take everything already true about extensions and remove the one thing that used to slow it down: a person deciding, step by step, whether to proceed. An agent operates with a user's full authenticated access across every service that user is logged into, and it runs multi-step tasks without stopping to ask permission along the way.

The agent doesn't authenticate separately to anything. It uses whatever tokens, cookies, and sessions are already sitting in the browser, whether that's email, a source-code repository, a bank's web portal, a CRM, or an HR system⟚. One grant of browser access hands over the user's entire digital identity, all at once, across every service that identity touches.

Prompt injection is how attackers exploit this in practice. An attacker plants instructions inside a web page, a document, or an email the agent is going to encounter while doing something completely legitimate, and the agent follows those instructions as though they were part of the job, because large language models treat instructions and ordinary data content the same way. OWASP classifies this as LLM01:2025 Prompt Injection. SquareX ran a demonstration where an agent told to log into Salesforce instead submitted the user's credentials to a phishing site made up to look like Salesforce, and in a separate case, an agent doing what looked like routine research was manipulated into granting attackers full access to the user's email and Google Drive through an OAuth attack.

Akamai's 2026 telemetry names three attack techniques built for exactly this blind spot: Vibe Hacking, CursorJacking, and CometJacking, each aimed at AI coding assistants, browser extensions, or agents that sit outside what enterprise monitoring tools are built to see. Because agents act without approval at each step, the window where a human could have caught the problem, the same window that at least existed with extension-mediated leakage, closes completely. Gartner named shadow AI governance a top cybersecurity trend for 2026, pointing out that most organizations don't even know the full scope of AI tools their own employees use. Agents make that worse: some run as background processes with no visible interface at all, so there's nothing on a screen for a security team to even notice, let alone flag.

Blocking AI tools outright and the resulting worse data exposure problem

Banning AI extensions outright doesn't remove the demand behind them. It just pushes that demand toward personal accounts, local models, and unmanaged tools, all of which create more exposure, not less.

This isn't a hypothetical. Akamai's 2026 Enterprise AI Usage Risk Report found that nearly half of all AI conversations on enterprise devices already flow through personal accounts outside any audit control, and that's the baseline before a company enacts a single new blocking policy. LayerX's Browser Security Report 2025 found that a large majority of data pasted into GenAI prompts already comes from personal accounts rather than corporate ones. Gartner's naming of shadow AI governance as a top 2026 trend makes the same point from a different angle: most organizations already lack visibility into what AI tools their people are using, well before anyone reaches for a block list. Blocking pushes demand into a shadow that already existed. It just deepens one that was already there.

The CISA case complicates the instinct to blame the user. That official was trained, security-aware, and not cutting corners. What happened wasn't someone dodging a rule; it was ordinary workflow behavior that the architecture never constrained in the first place. No block would have caught it, because nothing about it looked like circumvention.

Cursor's line, that vetting extensions is the user's job, deserves a fair hearing, because it's the strongest version of the counterargument here: if enterprises just enforced strict vetting and trained people well, wouldn't that be enough? AITOPIA answers that directly. Roughly 900,000 users installed extensions that cleared every trust signal available to them, install count, apparent legitimacy, a published privacy policy, precisely because the malicious behavior was engineered not to show up during vetting. Training helps. It doesn't help against something designed to be invisible to training.

Controls matched to the architectural reality of how extensions and agents operate

The risk documented across every section here lives in one place: inside the browser session, where extensions run and agents act and data moves before any file, API call, or network log ever gets generated. Controls built for files, processes, or network perimeters were never going to see it, no matter how well-funded or well-staffed the security team behind them is.

That's the uncomfortable part of this argument, and also the useful part. The architecture that makes extensions and agents so effective at their jobs, continuous access, broad reach across page content and sessions, no per-step friction, is the same architecture that makes them structurally hard to monitor with tools built for a different layer. Fixing this isn't about better training, stricter vetting, or another blocklist bolted onto the endpoint. It requires visibility and enforcement placed where the activity actually happens: inside the browser runtime itself, watching what extensions do after install, beyond what they claimed to need at the moment someone clicked "add to Chrome."