Fake AI assistant extensions turn Chrome into a data broker

At a glance

What this is: This is a browser-extension threat report showing how fake AI assistant extensions used remote iframes, shared infrastructure, and privileged access to turn Chrome into a data-exfiltration path.

Why it matters: It matters because browser extensions now sit inside identity and access paths for both human and non-human workflows, so runtime control, data boundary enforcement, and extension governance all need to be treated as identity security problems.

By the numbers:

• Across 30 different Chrome extensions, published under different names and extension IDs, the same underlying codebase, permissions, and backend infrastructure were observed.

👉 Read LayerX Security's analysis of fake AI assistant extensions and Chrome data exposure

Context

Fake AI browser extensions are a governance problem because they blur the line between a local install and a remotely controlled access broker. In this case, the extension surface was not just presenting a user interface, it was also relaying page content and interaction data to backend infrastructure that could change after installation.

That matters to identity teams because browser add-ons often sit outside traditional IAM and PAM controls even when they can touch authenticated sessions, email content, and internal applications. Once an extension can observe the active tab, inject UI, and send data off-device, the browser becomes part of the identity perimeter rather than a neutral client.

The article’s starting point is typical of modern browser abuse: legitimate-looking AI branding, distributed publishing, and hidden runtime control. The difference here is the scale of the shared backend and the degree to which remote logic, not reviewed code, defined the extension’s actual behaviour.

Key questions

Q: How should security teams govern Chrome extensions that can read sensitive web content?

A: Security teams should treat extensions as privileged software components, not convenience add-ons. Approve only extensions with a clear business need, restrict them to managed policy, and block those that can read mail, internal apps, or authenticated page content unless they are explicitly required. Runtime monitoring matters because post-install behaviour can diverge from the reviewed package.

Q: Why do remote-controlled browser extensions create a bigger risk than local-only tools?

A: Remote-controlled extensions expand risk because the operator can change the interface and logic after installation without a new store review. That means the trust decision made at install time no longer matches the live runtime state. For identity programmes, this breaks the assumption that browser software remains bounded by the code that was originally approved.

Q: What do teams get wrong about AI-branded browser extensions?

A: Teams often assume an AI-branded extension is a productivity feature rather than a data-access mechanism. The real question is whether the extension can observe active tabs, extract message content, or forward page data to external infrastructure. If it can, the branding is irrelevant and the control requirement becomes access containment.

Q: How can organisations detect extension spraying across multiple browser listings?

A: Organisations should compare code fingerprints, permission sets, backend domains, and update behaviour across all browser extensions in use. Extension spraying usually hides one operator behind many listings, so a name-based review misses the pattern. The goal is to detect shared infrastructure and revoke the whole cluster, not just one visible extension.

Technical breakdown

Remote iframe control inside Chrome extensions

The core mechanism is remote UI delegation. Instead of rendering all behaviour locally, the extension loads a full-screen iframe from an external domain and uses that frame as the operating interface. Because the frame is server-controlled, the operator can alter content, prompts, workflows, and data handling without pushing a new Chrome Web Store update. That means the install-time review sees one thing, while the live runtime can become something else entirely. This is especially dangerous when the extension is allowed to sit on top of a page the user trusts, because the browser’s visual boundary is no longer a reliable indicator of control.

Practical implication: enforce runtime monitoring for remote iframe activity, not just extension approval at install time.

Page-content extraction and Gmail DOM access

The extension uses content scripts to read the active page and, in the Gmail-focused cluster, extracts visible message content directly from the DOM. In practical terms, the extension is not simply assisting with summarisation. It is programmatically collecting readable page text, metadata, and possibly draft or compose context, then forwarding that data to backend systems controlled by the operator. This is a data boundary failure because authenticated browser content can be captured outside the application’s native security controls. For identity practitioners, the important detail is that browser session trust is being converted into out-of-band data access.

Practical implication: restrict extensions that can read DOM content on sensitive domains, especially mail and internal collaboration apps.

Extension spraying and shared backend infrastructure

The campaign uses extension spraying, where multiple seemingly separate listings share the same codebase, permissions, and infrastructure. That approach gives the operator resilience against takedowns, because removing one ID does not remove the control plane behind it. The shared backend also makes policy enforcement harder: different names, themes, and extension IDs create the impression of diversity, while the operational model remains centralized. This is not just reputation evasion. It is a distribution strategy designed to keep access alive even when individual listings are removed.

Practical implication: correlate extension IDs, backend domains, and permission sets as one control object rather than reviewing each listing in isolation.

Threat narrative

Attacker objective: The attacker’s objective is to use browser trust to collect user content and session data at scale while keeping the extension control plane resilient to takedown.

1. Entry begins with users installing Chrome extensions that impersonate AI assistants and appear legitimate through branding, store presence, and featured placement.
2. Credential and data access occurs when the extension reads page content from the active tab and Gmail DOM, then relays that information through a remote iframe and backend infrastructure.
3. Impact follows as authenticated browser-session data, including email content and page text, can be moved outside the application boundary and repurposed by the operator.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

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 extensions have become identity-adjacent control points, not harmless productivity add-ons. When an extension can read authenticated page content, inject UI, and relay data to mutable backend infrastructure, it is operating inside the access path, not beside it. That means browser governance now belongs in the same conversation as session control, secret exposure, and delegated access. Practitioners should treat extension runtime behaviour as part of identity risk management, not as a separate endpoint hygiene issue.

Remote iframe control is a runtime governance gap, not just a suspicious implementation pattern. The security problem is that the reviewed extension package is no longer the whole trust object once live server-side components can rewrite behaviour after installation. That breaks the assumption that Chrome Web Store review meaningfully bounds what the extension will do tomorrow. For practitioners, the implication is that approval models based only on install-time review are structurally incomplete.

Identity blast radius in the browser now includes content, context, and conversation state. These extensions did not need privileged backend credentials to be dangerous; they exploited the fact that a trusted browser session already contains rich authenticated data. That makes the browser a high-value identity broker even when no classic NHI secret is stolen. Security teams should recognise that browser-controlled data access can create an identity blast radius larger than the extension’s declared permissions suggest.

Extension spraying shows how governance fails when control is evaluated per listing instead of per operator. Multiple names, IDs, and themes can conceal one shared backend and one operational actor. The governance mistake is to think each store record is a separate risk decision. The practitioner conclusion is straightforward: identity and access control for browser extensions must correlate code lineage, backend infrastructure, and permission reuse, not just package names.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader breakdown of how non-human identities fail in practice, review The 52 NHI breaches Report alongside the pattern analysis in Top 10 NHI Issues.

What this signals

Remote control is the real issue here: once a browser extension can change behavior after install, the security team no longer owns the full trust boundary. That pushes extension governance into runtime monitoring, network inspection, and domain correlation, especially for mail and collaboration tools where browser context already contains valuable identity data.

With only 44% of organisations having implemented any policies to govern AI agents, per AI Agents: The New Attack Surface report, the broader market signal is clear. Identity governance is moving toward runtime enforcement across humans, NHIs, and agent-adjacent browser control points rather than static approval lists.

For practitioners

• Audit browser extensions against managed policy, not user preference. Inventory all installed extensions in managed environments, identify those installed outside approved policy, and remove any extension that can read page content on mail, collaboration, or internal application domains.
• Block remote iframe-backed extension UIs on sensitive workflows. Flag or deny extensions that render a server-controlled iframe as the primary interface, especially when the iframe can change behavior without a new store release or code review.
• Correlate extension lineage across IDs and domains. Treat shared JavaScript logic, shared permissions, and shared backend domains as one risk object, even when the extensions carry different names or appear to be separate products.
• Monitor DOM manipulation and outbound web requests at runtime. Use behavior-based controls to detect unauthorized DOM reads, injected UI elements, and suspicious network calls from extensions that should not be exporting page content.

Key takeaways

• Fake AI assistant extensions can turn a trusted browser session into an unmanaged data broker without touching traditional perimeter controls.
• Shared code, shared infrastructure, and remote iframe control make extension spraying a governance problem, not just a malware problem.
• The practical response is runtime extension governance, tighter domain controls, and lineage analysis across IDs, permissions, and backend hosts.

Key terms

• Browser Extension Spraying: Browser extension spraying is the practice of distributing the same malicious capability across many extension IDs, names, or listings to reduce takedown impact. It hides operational continuity behind apparent product diversity and makes governance harder when reviewers inspect only one listing at a time.
• Remote Iframe Control: Remote iframe control is a pattern where an extension loads its primary interface from an external server instead of rendering all logic locally. This lets the operator change behavior after installation and separate the reviewed package from the live control plane that handles data and interaction.
• Identity Blast Radius: Identity blast radius is the amount of sensitive access or data movement a single identity or session can influence when trust is misplaced. In browser contexts, it includes page content, email text, authentication state, and downstream systems that can be reached through the session.

Deepen your knowledge

Browser extension governance and runtime identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern browser-mediated access with the same discipline you apply to other non-human identities, it is worth exploring.

This post draws on content published by LayerX Security: AiFrame fake AI assistant extensions targeting Chrome users via injected iframes. Read the original.