AI browser extensions are becoming a new NHI data loss path

At a glance

What this is: This analysis examines malicious AI browser extensions that silently captured AI chat content and browsing data at scale, showing how extension trust can become an NHI governance problem.

Why it matters: IAM and NHI teams should treat browser extensions with site-wide read access as high-risk third-party identities because they can exfiltrate prompts, URLs, and session context outside approved controls.

By the numbers:

• The extensions exfiltrated captured data every ~30 minutes to attacker-controlled infrastructure.

👉 Read Astrix Security's analysis of malicious AI browser extensions and data theft

Context

AI browser extensions sit at a difficult intersection of productivity and trust. They can read page content, observe browsing behavior, and interact with web applications in ways that ordinary users do not fully understand. In NHI governance terms, that makes them a form of high-privilege software identity that often escapes the controls applied to service accounts, tokens, and API keys.

This case matters because the browser has become a live workspace for AI use, not just a place where people search and browse. When an extension can scrape chat interfaces, record open-tab URLs, and transmit data on a timer, the issue is not just endpoint security. It is unmanaged access to sensitive workflows, which is exactly where NHI governance gaps tend to appear.

Key questions

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

A: Security teams should treat AI browser extensions as privileged software identities and require allow-listing, permission review, and outbound monitoring. Any extension that can read page content, observe tab URLs, or access AI chat interfaces should be subject to the same scrutiny as other delegated access paths. If it cannot be reviewed and constrained, it should not run in managed browsers.

Q: Why are AI browser extensions risky for NHI governance?

A: They are risky because they operate with delegated browser authority rather than a simple user click. Once installed, they can observe high-value content across many sites, including AI chats and internal tools, which makes them function like unmanaged non-human identities. The governance problem is scope, visibility, and revocation, not just malware detection.

Q: What is the difference between browser extension trust and identity trust?

A: Browser extension trust is a user or marketplace decision, while identity trust is a governance decision about what a software actor is allowed to see and do. In practice, extension trust is weaker because it can grant broad page access without the review discipline used for NHI credentials. Teams should align extension approvals with identity governance, not convenience.

Q: When should organisations block AI helper extensions outright?

A: Organisations should block them when the extension needs broad read access, cannot explain its data handling clearly, or operates outside an approved supplier list. If the tool can observe prompts, tab URLs, or session identifiers, the risk is usually broader than the productivity value. In managed environments, uncertainty should default to denial.

Technical breakdown

How malicious extensions turn browser access into data exfiltration

Chrome extensions with broad permissions can observe page content, tab changes, and URL updates across a user’s browsing session. That means they can reach into AI chat interfaces rendered in the DOM, capture prompt and response text, and stage it locally before sending it out. The extension does not need to break encryption or exploit a kernel flaw. It simply operates inside the trust boundary that the browser has already granted. For security teams, that makes extension permissions a practical identity and data boundary, not a convenience setting.

Practical implication: Treat extension permissions as privileged access and review them with the same discipline used for NHI entitlements.

Why AI chat interfaces are exposed to page-level scraping

AI chat applications display conversation content in the browser after authentication, which makes the rendered page itself a data source. Any extension with site access can read that content from the document object model, including prompts, responses, and session context such as identifiers embedded in the page. This is a structural weakness of browser-based AI usage. The application may be secure at the transport layer, but the local page environment remains readable to anything granted access to it.

Practical implication: Assume browser-visible AI conversations can be copied by any permitted extension and govern accordingly.

Why lookalike extensions are an identity and supply chain risk

A convincing extension can borrow trust from marketplace signals, branding, and familiar user experience. In this incident, the malicious package imitated a legitimate AI sidebar product and benefited from store visibility cues. That combination creates a supply-chain style risk: users install something they believe is safe, then grant broad read access that persists until removal. The real control failure is not just malicious code, but the mismatch between user perception and the authority the extension receives.

Practical implication: Create an allow list for browser extensions and block unreviewed AI helpers from managed browsers.

Threat narrative

Attacker objective: The attacker objective was persistent collection of sensitive AI conversation content and browsing intelligence that could support theft, phishing, and corporate espionage.

1. Entry via Chrome Web Store listings that mimicked a legitimate AI sidebar product and persuaded users to install them.
2. Escalation through broad browser permissions that allowed page-wide visibility into AI chats, tab URLs, and session context.
3. Impact through periodic exfiltration of prompts, responses, and browsing data to attacker-controlled infrastructure on a recurring schedule.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• 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 extensions are now part of the NHI attack surface. An extension that can read content across sites, monitor tabs, and transmit data behaves like an unmanaged software identity with delegated authority. That authority is often broader than teams realize because the trust decision happens at install time, not at runtime. Security programs should therefore classify AI browser helpers alongside other high-risk non-human access paths, not as routine productivity tools.

Ephemeral access does not help if the identity itself is ungoverned. The extensions in this case did not need long-lived credentials to cause harm because they operated inside the browser’s permission model. That shifts the control problem from credential lifetime to permission scope, consent quality, and supplier trust. Practitioners should focus on blast radius reduction, because the threat is not just theft of a token but theft of whatever the extension can see.

AI chat leakage is becoming a new form of shadow AI exposure. When employees use browser-based AI tools, the organization inherits a second layer of risk through the extensions and add-ons that sit beside those tools. Those add-ons may capture prompt content, internal URLs, and workflow context without being visible in standard IAM reviews. The governance lesson is simple: unmanaged AI helpers create hidden access paths, and hidden access paths become hidden loss paths.

Marketplace trust signals are not a sufficient control. A badge, popular listing, or familiar interface can still mask high-risk behavior. That means security teams should not use store popularity as a proxy for trust, especially when the tool requests broad read access. The better control is a combination of allow listing, runtime monitoring, and explicit review of what data the extension can observe and transmit.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, including 38% with no or low visibility and 47% with partial visibility.
• The visibility gap is the forward risk signal, so readers should examine Guide to the Secret Sprawl Challenge for the controls that reduce hidden exposure paths.

What this signals

The browser is becoming a governance boundary, not just an endpoint surface. As AI work moves into extensions and sidebars, the distinction between user productivity tooling and delegated non-human access keeps eroding. Security teams should expect more shadow AI pathways to appear first in the browser, then in identity reviews, which means extension governance now belongs in the same program conversation as secrets management and third-party access.

Identity blast radius: when a browser add-on can see prompts, URLs, and session context, the effective blast radius is defined by page access rather than by login state. That changes how teams should think about risk acceptance. According to The State of Non-Human Identity Security, only 1.5 out of 10 organisations are highly confident in securing NHIs, which is consistent with a broader control gap around delegated software actors.

Browser extension governance should become a standard part of AI adoption reviews. The practical next step is to decide which AI helpers are permitted, what data they can observe, and how quickly they can be removed if behavior changes. This is less about banning useful tools and more about ensuring the tools are subject to the same revocation, monitoring, and supplier scrutiny that the organisation already expects for other non-human identities.

For practitioners

• Inventory browser extensions as privileged software identities Catalog all installed extensions in managed browsers, identify any AI-related add-ons, and flag anything with read-all-sites or tab-access permissions for immediate review.
• Block unreviewed AI helpers in corporate browsers Create an allow list for approved extensions and prevent installation of new AI sidebar or summarization tools until supplier risk and permission scope are assessed.
• Review data egress from browser extensions Monitor outbound traffic from extension-related processes and alert on periodic posting patterns, especially where content includes prompts, URLs, or session identifiers.
• Treat AI conversations as exposed data by default Assume prompts, responses, and troubleshooting details shared in browser-based AI tools may be copied by permitted extensions and revise user guidance accordingly.
• Link browser governance to NHI controls Map high-risk extensions to the same review cycle used for service accounts and tokens, because both create delegated access that can move sensitive data outside policy.

Key takeaways

• AI browser extensions can act like high-privilege non-human identities when they can read page content and tab data.
• Marketplace trust signals do not compensate for overly broad browser permissions or weak supplier review.
• The right control response is allow-listing, outbound monitoring, and treating AI chat content as potentially exposed by default.

Key terms

• Browser Extension Identity: A browser extension identity is the effective authority granted to an add-on once a user installs it and approves permissions. In practice, that authority can include reading page content, observing tabs, and interacting with web apps, which makes the extension a governed non-human actor.
• Shadow AI: Shadow AI is an AI tool or agent used inside an organisation without formal approval, visibility, or governance. It often enters through convenience tools like browser sidebars, extensions, and plugins, creating hidden paths for prompt leakage, data exposure, and policy bypass.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, or workflow context a software identity can reach before it is stopped. For browser extensions and AI helpers, the blast radius is often defined by page access, not by a traditional login session.
• Delegated Browser Access: Delegated browser access is the permission a user grants to software running inside the browser to act on their behalf or read their session context. It is a practical NHI concern because the delegated actor can observe sensitive content without needing separate credentials.

What's in the full article

Astrix Security's full article covers the operational detail this post intentionally leaves for the source:

• Browser-level indicators used to flag the suspicious AI sidebar extensions before broader user impact.
• Specific behaviors observed in the extensions, including page scraping, tab monitoring, and periodic exfiltration.
• The customer response pattern Astrix saw as organizations removed the tools before publication.
• Remediation steps for identifying and cleaning up similar extensions in managed environments.

👉 The full Astrix Security post covers the extension behavior, exfiltration cadence, and remediation actions.

Deepen your knowledge

AI browser extension governance and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring shadow AI helpers under review, this is a relevant starting point.