TL;DR: Browser extensions are installed on 99% of enterprise users, nearly 75% request high or critical permissions, and AI extensions are 60% more likely to carry known vulnerabilities, 3x more likely to access cookies, and nearly 6x more likely to expand permissions after installation, according to LayerX Security. That makes browser-based identity exposure a governance problem, not just an endpoint hygiene issue.
At a glance
What this is: This report shows that browser extensions are nearly universal in enterprise environments and that AI extensions concentrate higher permissions, more vulnerabilities, and more post-installation permission drift.
Why it matters: IAM, NHI, and endpoint teams need visibility into browser extensions because they can access cookies, inject code, and quietly expand privilege outside traditional software inventory and review processes.
By the numbers:
- 99% of enterprise users have at least one browser extension installed.
- Nearly 75% of all browser extensions request high or critical permission levels.
- 1 in 6 enterprise users already has at least one AI extension installed.
- 64% of users have at least one AI extension that changed its permissions in the past 12 months.
Context
Browser extensions are a control blind spot because they sit inside the browser, where authentication, cookies, session tokens, and page content all converge. When extensions can read what users type, alter what they see, or handle tokens, they effectively become part of the identity trust boundary whether security teams inventory them or not.
This article focuses on the governance gap created by AI browser extensions in enterprise environments. The core issue is not browser usability, but unmanaged access to browser-held identity material and the lack of visibility into who installed these tools, what they can do, and how their permissions change over time.
Key questions
Q: How should teams govern approved browser extensions after installation?
A: They should treat approval as the start of governance, not the end. Approved extensions need continuous monitoring for ownership transfer, developer account changes, permission escalation, and delisting. That is the only way to catch the changes that typically precede a real-world compromise in browser extension attacks.
Q: Why do AI browser extensions create higher data exposure risk than standard extensions?
A: AI browser extensions often request broad access to page content, messages, or input fields so they can provide context aware features. That access can expose personal data, credentials, and confidential business information to collection, interception, or misuse. If the extension is poorly governed, the risk increases further because model behavior can be influenced by unsafe prompts, biased outputs, or malicious manipulation.
Q: What breaks when organisations cannot see which browser extensions are installed?
A: Least privilege, recertification, and exception handling all lose their basis if teams cannot tell which extensions exist, who installed them, or what they can do. In that state, browser sessions become governed by user choice rather than policy, and security teams cannot distinguish harmless utilities from extensions that can handle identity data.
Q: How do security teams know if extension governance is actually working?
A: Measure whether unapproved extensions can be installed, whether dormant packages are being reviewed after sudden updates, and whether malicious listings can be blocked before execution. If a dangerous package can still reach a live workspace, governance is failing at the point that matters most.
Technical breakdown
Why browser extensions sit inside the identity trust boundary
Browser extensions operate with access to the browser session, which means they can touch cookies, page content, forms, and in some cases scripts injected into web pages. That matters because the browser is where modern authentication state is often carried after login. Once an extension can inspect or modify that context, it is no longer a neutral productivity add-on. It is a privileged runtime component sitting between the user and the service, often outside software asset and access governance processes.
Practical implication: treat extensions that can read session data as governed access paths, not convenience tools.
Why AI extensions concentrate more risk than ordinary add-ons
AI extensions in this report show higher rates of known vulnerabilities, cookie access, scripting permissions, and tab management than the general extension population. Those capabilities matter because they extend beyond passive observation into manipulation of browser content and session state. An AI extension that can read cookies and inject code can participate in credential theft, session hijack, or content tampering even when the user believes they are only using a writing helper or summarizer.
Practical implication: inventory AI extensions separately and classify them by the browser data they can reach.
How permission drift turns installation into a moving target
Permission drift is the change in what an extension can do after the original install decision. That is a governance problem because approval at day one does not guarantee the same risk profile at day 180. If an extension updates silently and expands from low-risk functionality to cookies, scripting, or tab control, the original user consent no longer reflects the current privilege state. Traditional review cycles miss this because they tend to focus on installed software, not evolving browser entitlements.
Practical implication: monitor extension permission changes as a distinct control, not just initial approval.
Threat narrative
Attacker objective: The objective is to gain access to authenticated browser sessions and the identity data they carry, enabling session theft, data capture, or invisible browser manipulation.
- Entry occurs when users install browser extensions directly into enterprise browsers, often with minimal review and broad default trust. The extension then inherits a live browser session where authentication artifacts and content flow through the user interface.
- Credential access follows when the extension can read cookies, session tokens, or typed input, giving it exposure to the same identity material that powers the user’s authenticated session.
- Escalation occurs when scripting or tab-management permissions let the extension inject code, alter web content, or track user activity beyond the original purpose of the add-on. Impact is unauthorized exposure or manipulation of authenticated browser sessions and the data handled within them.
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.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Browser extensions are now part of the identity perimeter, whether organisations acknowledge it or not. They sit where authentication state, session cookies, and browser content intersect, so their privileges can directly affect access outcomes. That means browser extension governance belongs alongside identity inventory and endpoint control, not as an afterthought in user productivity policy. Practitioners need to treat extension visibility as a core identity control.
AI browser extensions create a browser-held trust gap that traditional software inventory does not close. The report’s core pattern is not simply more extensions, but more powerful extensions with higher permission appetite and more frequent post-installation change. That creates a governance gap because approval happened before the privilege state changed. The implication is that security programmes must manage extension entitlements as living access, not static installation events.
Permission drift is the named concept this report exposes: access approved once can expand silently after deployment. That is structurally similar to privilege creep, but inside the browser where identity material is already active and exposure is immediate. When a tool can gain cookies or scripting rights after installation, existing approval and recertification models become stale. Practitioners need controls that watch for entitlement change, not just initial trust decisions.
Extension visibility is an identity governance problem before it is a browser hygiene problem. The most relevant failure mode is not that users install tools, but that organisations cannot answer which extensions exist, who owns them, and what they can do today. Without that inventory, least privilege, recertification, and exception handling cannot operate against browser-level access. Security teams need to fold browser extensions into the same governance discipline used for other high-risk identities and secrets-bearing components.
AI extensions deserve separate governance because they combine rapid adoption with browser-native privilege. The report shows that these tools are not merely another application category. They are a fast-moving access layer with direct reach into credentials, content, and browsing behaviour. Practitioners should read that as a signal to separate general extension policy from higher-risk AI extension policy and align it with identity control ownership.
What this signals
Browser extension governance is now a practical extension of identity governance. The browser has become a session container, so any extension that can inspect cookies or inject code can alter access outcomes even when traditional IAM stays unchanged. Security teams should therefore classify extensions by the identity material they can reach, not by how useful they appear to employees.
Permission drift creates a hidden recertification problem. Once an extension can silently expand its permissions after installation, a one-time approval model no longer reflects current risk. Programme owners should expect browser extension entitlement drift to behave like privilege creep, but with less visibility and faster user adoption.
AI extensions need their own control tier because their privilege profile is different. The report shows these tools are more likely to touch cookies, scripts, and tabs, which means the operational question is not whether to allow them, but how to prove their current browser access still matches the approved use case.
For practitioners
- Inventory browser extensions across the enterprise Build a complete list of installed extensions by browser, user, and device, then identify which ones can access cookies, page content, scripts, or tabs. Without that inventory, you cannot govern browser-held identity state.
- Separate AI extensions from ordinary add-ons Create a distinct approval path for AI extensions that weighs known vulnerabilities, cookie access, scripting permissions, and tab management rather than treating them like simple utilities.
- Track permission changes after installation Monitor updates that expand extension permissions and flag any change from the original approval scope, especially when the extension gains access to browser authentication data.
- Tie extension risk to identity controls Map high-risk extension permissions to identity governance owners so recertification, exception handling, and offboarding include browser-level access paths as well as application accounts.
Key takeaways
- Browser extensions are no longer just productivity tools because they can sit directly inside the browser session where authentication state lives.
- AI extensions amplify that problem by combining broad access with more frequent permission change and higher vulnerability exposure.
- The control gap is visibility and lifecycle governance, so the first priority is to inventory extensions and track when their permissions expand.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Extensions can access cookies and session tokens, making secret exposure the core risk. |
| NHI-04 — Insecure Authentication | Browser-held authentication state can be intercepted or manipulated by extensions. | |
| NHI-05 — Overprivileged NHI | The article centers on extensions requesting and expanding access beyond least privilege. | |
| Recommendation — Inventory extensions that can read session material and revoke any that expose browser-held secrets. Restrict extensions that can inspect or alter authenticated browser sessions and session tokens. Classify high-risk extensions as overprivileged and re-evaluate their access scope after every permission change. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Extension permissions are a browser-level entitlement that must be governed and reviewed. |
| Recommendation — Apply PR.AA-05 to review extension entitlements and remove access that is broader than the approved use case. | ||
| MITRE ATT&CK | TA0006;TA0009 — Credential Access; Collection | The threat is credential and session collection through browser access paths. |
| Recommendation — Map risky extensions to TA0006 and TA0009 to prioritize controls around session token and content collection. | ||
Key terms
- Browser Extension Privilege: The access a browser add-on receives through the user’s browser context and granted permissions. In practice, this can include cookies, tabs, page content, and scripting rights, which makes an extension capable of influencing authenticated sessions and web workflows without separate identity controls.
- 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.
- Browser-Held Identity Material: Browser-held identity material is the authentication data that lives in a browser session, such as cookies, session tokens, and other state used to maintain a logged-in session. Extensions that can read or manipulate this material can affect identity trust without ever becoming a traditional IAM subject.
- Development Extension Attack Surface: Development extension attack surface is the collection of ways an IDE add on, preview service, or helper process can be abused by an attacker. The risk grows when the extension exposes local ports, processes untrusted content, or has access to files and secrets that should stay isolated from the browser.
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.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org