Browser extensions are privileged identities, not harmless add-ons

At a glance

What this is: This analysis argues that browser extensions function as privileged identities with broad browser-level access, making them capable of persistent surveillance, manipulation, and data theft.

Why it matters: IAM, SaaS security, and endpoint teams need a shared control model because extension permissions, publisher drift, and lifecycle changes create a non-human access path outside traditional user and app governance.

Context

Browser extensions are small software components, but in enterprise browsers they can sit inside the trust boundary for users, SaaS applications, and conferencing workflows. The governance problem is that their permissions often outlast the moment they were approved, so a harmless installation can become a durable access path.

The identity issue is not whether the extension is software, but whether it behaves like a non-human identity with delegated access. Once an extension can read page content, observe sessions, persist state, and change behaviour through updates or remote configuration, the control question shifts from software hygiene to lifecycle governance.

Astrix Security’s article uses this model to argue that browser-extension risk belongs in identity and access programmes, not only in endpoint or marketplace review. The core failure is fragmented ownership, where no single team governs the extension as an identity-bearing actor.

Key questions

Q: What breaks when browser extensions are treated as low-risk add-ons?

A: Security teams lose visibility into a delegated access layer that can read browsing activity, intercept requests, and persist across sessions. That turns a simple install decision into an identity governance problem. Extensions need ownership, permission review, and lifecycle control because they can behave like durable non-human integrations rather than temporary tools.

Q: Why do malicious browser extensions create so much risk in modern enterprises?

A: Malicious extensions are risky because they sit inside the browser, where employees do most of their work and where identity, sessions, and data are already in use. Attackers can start with a benign extension, later push a malicious update, or take over an existing extension. That turns a trusted add-on into a delivery path for compromise.

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: What is the difference between a browser extension risk and a normal SaaS integration risk?

A: A SaaS integration is usually reviewed as a formal connected application with defined scopes and lifecycle controls. A browser extension can be installed informally by a user, then collect secrets from local browser state or page content without the same approval path. That makes its risk harder to see and faster to spread.

Technical breakdown

Why browser extensions behave like privileged non-human identities

A browser extension is not just code running in the browser. When installed, it receives permissions that can include reading page content, modifying DOM behaviour, storing state, and making network calls, which together create a browser-local access principal. That principal can persist beyond the original install moment because updates, remote configuration, and staged loaders can change behaviour after trust is established. The security risk is not only what the extension did at submission time, but what it can do after adoption when users and controls have already relaxed. In practice, this means extension governance must be treated as identity governance for a non-human actor, not as a one-time software review.

Practical implication: govern extensions as access-bearing identities with lifecycle state, not as static browser plugins.

How staged extension abuse bypasses standard SaaS and endpoint controls

The article describes a common pattern: legitimate functionality attracts installs, permissions accumulate, and then malicious behaviour is activated later through updates or server-controlled configuration. That pattern defeats controls that only inspect initial marketplace submission, because the harmful behaviour appears after the trust decision. It also slips through tools that separate IAM, SaaS security, and endpoint visibility, since each layer sees only a fragment of the action. Browser storage, especially synced state, can preserve identifiers and tracking data across sessions and devices, which extends the abuse window. This is why browser-extension abuse looks less like a simple malware event and more like a controlled privilege transition.

Practical implication: monitor extensions for permission drift, publisher drift, and delayed activation rather than relying on install-time review alone.

Why conferencing and SaaS data are especially exposed

Extensions with broad site access can observe meeting links, embedded passwords, and other contextual data inside collaboration tools and SaaS applications. That exposure matters because the browser is where sensitive workflows converge, including authentication, scheduling, and meeting participation. Once an extension can inspect or alter what a user sees, it can collect intelligence without needing to break the underlying application. This creates an RCE-like effect at the browser layer, where the extension does not own the app but can still shape user interaction and extract operational value from it. For identity teams, the important point is that browser privilege can exceed app privilege in practice.

Practical implication: treat conferencing and SaaS browser access as a sensitive execution zone that needs explicit extension controls.

Threat narrative

Attacker objective: The objective is to turn trusted browser access into persistent enterprise intelligence collection and monetisation without triggering obvious user suspicion.

1. Entry occurs when a user installs a browser extension that presents legitimate functionality and earns broad browser permissions through normal adoption.
2. Escalation follows when updates, remote configuration, or staged loaders activate hidden behaviour after the extension has been trusted and widely deployed.
3. Impact is achieved by monitoring and manipulating browsing activity, scraping corporate meeting intelligence, and exfiltrating data such as meeting links and embedded passwords.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

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 privileged identities, not peripheral software. Their permissions, runtime reach, and post-install behaviour put them inside the access layer, not beside it. Once extensions can observe content, persist state, and change function through updates, they belong in the same governance conversation as OAuth apps and service accounts. The practitioner conclusion is simple: extension inventories must be governed as identity assets.

Permission drift is the real control failure here. The article shows that the danger often appears after approval, when an extension’s behaviour changes without a fresh governance decision. That is a lifecycle failure, not a procurement failure, and it means periodic review of the install record is not enough. The practitioner implication is that trust decisions must be revisited whenever extension scope, publisher, or delivery path changes.

Shadow browser access creates cross-team blind spots. IAM sees the user, SaaS security sees the application, and endpoint tooling often sees only limited browser behaviour, so the extension sits in the gap between programmes. That gap is why extension abuse can persist in plain sight. The practitioner conclusion is that governance ownership has to be explicit across identity, endpoint, and SaaS teams.

Extended browser privilege is now a category-level identity problem. Treating extensions as harmless add-ons underestimates their ability to move from convenience to surveillance with a silent update. The article’s broader signal is that enterprises need a new control plane for non-human access paths inside the browser. The practitioner conclusion is to classify extensions as governed identities with enforced lifecycle controls.

Permission drift and browser-scope abuse are the defining governance blind spots. The article ties together trust-building, delayed activation, and data extraction into one operational pattern. That pattern is not solved by user awareness alone because the abuse happens after the access decision and within a trusted execution surface. The practitioner conclusion is to anchor policy on behaviour, scope, and ownership rather than on install-time intent.

What this signals

Browser extensions need lifecycle governance, not just endpoint monitoring. The decision point is no longer whether an add-on is installed, but whether its permissions, publisher, and delivery path still match the approved use case. Once those attributes drift, the extension has effectively changed identity and should be reviewed as such.

Browser privilege has become an access layer of its own. In SaaS-heavy environments, the browser is where meetings, credentials, and workflow context converge, so extension abuse can produce business impact without breaking the underlying application. That means policy should focus on scope control, ownership, and revocation, not only on malware detection.

Shadow extension risk is a governance problem, not a user-behaviour problem. Users can install helpful tools in good faith, but enterprise risk appears when no team owns the ongoing access decision. The practical signal for programmes is to bring browser extensions into the same governed inventory as other non-human access paths.

For practitioners

• Inventory browser extensions across managed estates Build a complete list of installed extensions by user population, browser, and business unit so governance begins with an accurate asset view.
• Move to allow-list approval for extensions Default-deny unapproved extensions and require explicit review for any add-on that requests broad site access or persistent storage.
• Block high-risk permission combinations Flag or deny extensions that request read and modify access across all sites, especially when paired with remote configuration or auto-update channels.
• Assign business ownership to each approved extension Tie every approved extension to a named owner who can justify the access scope, review changes, and retire it when the business use case ends.
• Monitor post-install drift and outbound behaviour Watch for permission expansion, publisher changes, unusual network destinations, and synced-state reuse that indicate a trusted extension has changed risk profile.

Key takeaways

• Browser extensions can function as privileged non-human identities because they sit inside the browser trust boundary and can outlive the original approval decision.
• The article links this risk to long-running campaigns that can change behaviour after installation and use the browser to collect meeting and SaaS intelligence at scale.
• The limiting control is lifecycle governance over permission drift, ownership, and approved scope, not a one-time check at the moment of install.

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.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.
• Shadow Extension: A shadow extension is an unmanaged browser add-on that exists outside approved inventory or lifecycle oversight. It creates hidden access paths into SaaS, conferencing, and browser-state data, which means security teams cannot govern what they have not discovered.
• Browser-Level Privilege: Browser-level privilege is the practical ability of an extension to observe, shape, or extract data from a user’s web session. It is not the same as administrative rights on the endpoint, but it can be equally sensitive because it sits where identity, content, and workflow intersect.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.