Browser extensions are privileged identities, not harmless add-ons

At a glance

What this is: This analysis argues that browser extensions should be treated as high-risk non-human identities because they can persist, change behavior after installation, and access sensitive enterprise workflows.

Why it matters: IAM and NHI practitioners need to govern extension permissions, lifecycle, and drift because a trusted browser add-on can become a durable exfiltration path.

By the numbers:

• Zoom Stealer is reported at 2.2M users across 18 extensions on Chrome, Edge, and Firefox.

👉 Read Astrix Security's analysis of DarkSpectre, ShadyPanda, and Zoom Stealer

Context

Browser extensions are not just UI helpers. In enterprise environments they can function like privileged integrations with access to browsing activity, SaaS content, and session context, which makes them part of the NHI governance problem rather than a peripheral endpoint concern. The browser extension risk is that trust is usually granted once, while behavior can change later without a fresh approval step.

Astrix Security’s reporting lands in the same broader pattern seen across NHI programs: long-lived, lightly governed access paths accumulate risk after deployment. That is typical of unmanaged non-human identities, and it is why extension inventory, permission review, and drift detection need to sit inside the IAM operating model rather than beside it.

Key questions

Q: How should security teams govern browser extensions that access SaaS data?

A: Treat browser extensions as access-bearing non-human identities. Assign ownership, limit permissions, review update channels, and remove anything without a clear business purpose. The control goal is not only preventing malware, but also preventing a trusted add-on from becoming a persistent data path into SaaS, meetings, and browser-based workflows.

Q: Why do browser extensions create a governance gap for IAM teams?

A: IAM usually governs accounts and federated applications, not what runs inside an authenticated browser session. That means an extension can operate under a legitimate user context while observing or modifying sensitive activity. The gap is visibility, lifecycle ownership, and drift management, not just authentication.

Q: What is the difference between a browser extension risk and a normal SaaS app risk?

A: A SaaS app risk is usually visible as an external integration with a defined authorization flow. A browser extension risk is embedded inside the user’s session and can interact with multiple services at once. That makes it harder to isolate, because the extension inherits trust from the browser rather than from a direct API grant.

Q: When should organisations remove a browser extension instead of reviewing it?

A: Remove it when the extension has broad site access, unclear ownership, suspicious update behavior, or no demonstrable business need. If the tool can observe sensitive workflows and there is no strong control evidence, the safer decision is to treat it as unapproved non-human access and eliminate it.

Technical breakdown

How browser extensions become privileged non-human identities

A browser extension can request broad permissions at install time, then use those permissions to read page content, alter interface behavior, track navigation, and reach SaaS data that the human user can already see. The security issue is not just initial permission scope. Extensions can also receive updates, remote configuration, or staged payloads that change behavior after trust is established. That makes the extension a living identity with evolving access, not a static piece of software. In practice, the browser becomes an execution environment where identity, content access, and persistence converge.

Practical implication: Treat extension permissions and update channels as identity controls, not just browser settings.

Why extension-based compromise bypasses normal IAM visibility

IAM platforms primarily govern human accounts, service accounts, and federated app access, but they do not usually model what a browser extension can do inside an authenticated session. That leaves a gap between user authentication and actual data use. SaaS tools may see activity as coming from a legitimate session, while endpoint tooling may only see generic browser processes. The extension can therefore operate inside the trust boundary already established by the user, which makes detection dependent on permission telemetry, network inspection, and extension inventory rather than sign-in events alone.

Practical implication: Add browser extension telemetry to identity and endpoint monitoring so session abuse is visible.

Identity drift in extensions and the governance problem of updates

Extension risk often appears after deployment because the code, publisher relationship, or remote configuration changes later. That is identity drift: the access path remains in place while the behavior becomes materially different from what was reviewed. For NHI programs, this is similar to a service account that retains standing access after its original purpose changed. If security teams only review extensions at install time, they miss the most dangerous phase, when a trusted integration flips behavior quietly and begins collecting sensitive enterprise data.

Practical implication: Reassess extensions on a recurring schedule and flag publisher, permission, and network drift.

Threat narrative

Attacker objective: The attacker wants durable, low-friction access to enterprise SaaS activity and meeting intelligence without relying on a visible account takeover.

1. Entry occurs when a user installs a legitimate-looking browser extension that gains broad browser and SaaS visibility.
2. Escalation happens when the extension receives an update, remote configuration, or staged loader that activates malicious behavior after trust has been established.
3. Impact follows when the extension harvests meeting links, embedded passwords, browsing intelligence, or other sensitive enterprise data for fraud, surveillance, or monetization.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 operationally equivalent to non-human identities once they can act on behalf of the user. They have permissions, persistence, and the ability to influence downstream systems through the authenticated browser session. That means extension governance belongs in NHI policy, not only in endpoint hardening. Practitioners should model them as access-bearing entities and manage them accordingly.

Update-time behavior is the real control problem, not install-time approval. Most review processes focus on what an extension looked like when it entered the environment, but the risk materializes when the code, configuration, or publisher relationship changes later. That creates a governance blind spot similar to credential drift in service accounts. Security teams need recurring review, not one-time trust.

Identity blast radius is the right concept for browser extension risk. A single extension can read across tabs, observe SaaS workflows, and capture meeting intelligence at scale, which means one trusted add-on can expose multiple business processes at once. That is why the control objective is blast-radius reduction, not just malware detection. Practitioners should bound extension permissions as tightly as any other privileged access path.

Extension sprawl is a shadow NHI problem in plain sight. Many organisations already have unmanaged browser extensions with no clear owner, no lifecycle policy, and no continuous monitoring. The result is hidden access expansion through tools that are installed by users but rarely governed like identities. Security teams should close the owner, approval, and review gaps before the environment accumulates another unmanaged control plane.

Browser extension governance now belongs in the same conversation as OAuth app and agent governance. All three create non-human access paths that can operate with user trust, change behavior after approval, and outlive the original review. The practical implication is simple: if a control path can access enterprise data without human re-authentication, it needs identity lifecycle oversight.

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, and that visibility gap mirrors the browser extension problem: approved access can still hide unmanaged behavior.
• For a broader governance baseline, read Ultimate Guide to NHIs , Key Challenges and Risks for the controls that should surround any non-human access path.

What this signals

Browser extensions now fit the same governance pattern as OAuth apps and AI agents: they are non-human access paths that can change behavior after approval. The programme response should therefore shift from browser hygiene to identity lifecycle control, with tighter inventory, owner assignment, and drift review across the entire extension estate.

Identity blast radius: the practical measure of how much enterprise data a single extension can touch once it is trusted. If your security stack cannot bound that blast radius, the organisation is effectively granting persistent session-level access without the same scrutiny applied to other privileged identities.

The control agenda should now include browser extension approvals inside the broader NHI programme, not as a separate endpoint exception process. That lets teams connect discovery, permissions, and review cadence to an identity model that already exists for service accounts, OAuth grants, and autonomous agents.

For practitioners

• Inventory every extension in scope Collect extension IDs, publishers, permissions, and install sources across managed and unmanaged browsers. You cannot set policy until you know which extension identities exist, who owns them, and where they are active.
• Move to an allow-list model Approve only business-justified extensions and block the rest by default. This reduces the long tail of shadow add-ons that gain access through convenience rather than governance.
• Review permission drift after updates Reassess extensions whenever a publisher changes, permissions expand, or remote configuration appears. The highest-risk change is often not installation, but a silent update that alters behavior after trust has been granted.
• Monitor browser network and data paths Watch for unexpected outbound domains, repeated SaaS scraping patterns, and access to conferencing platforms that do not match the extension’s stated purpose. Pair this with endpoint telemetry so suspicious browser activity is not treated as ordinary user traffic.
• Assign a business owner for each approved extension Require a named owner responsible for approval, renewal, and removal. A browser extension without ownership is effectively standing non-human access with no accountability for its continued presence.

Key takeaways

• Browser extensions can function as privileged non-human identities once they gain the ability to act inside an authenticated session.
• The main governance failure is not initial installation, but silent behavior changes through updates, remote configuration, and permission drift.
• Security teams should inventory, own, and periodically re-approve extensions as part of the NHI lifecycle, not as a one-time browser review.

Key terms

• Browser Extension Identity: A browser extension identity is the access footprint an add-on creates once it can read pages, modify content, or act within a user session. In practice, it behaves like a non-human identity because it persists, carries permissions, and can outlive the approval moment that created it.
• Identity Drift: Identity drift is the gap between the access path originally approved and the behavior that exists later. For browser extensions, drift can appear through updates, remote configuration, publisher changes, or permission expansion, turning a trusted integration into a materially different risk.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, or workflows a single access path can affect before controls stop it. For browser extensions, the blast radius can be broad because one trusted add-on may observe multiple SaaS apps, meetings, and browser-based tasks at once.

What's in the full article

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

• Extension-by-extension campaign context across Chrome, Edge, and Firefox, including the sequencing of trust-building and activation
• Specific examples of how delayed activation, remote config, and staged loaders were used to change extension behavior after installation
• The browser-facing indicators that help separate ordinary extension activity from suspicious data collection behavior
• The enterprise SaaS and conferencing workflows most exposed to meeting-link and password harvesting

👉 Astrix Security's full post covers the campaign chain, browser behavior changes, and enterprise exposure details.

Deepen your knowledge

Browser extension governance and non-human access lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment is already dealing with extension sprawl, it is worth exploring.