AI Browser Extensions Security: Risks and Controls

AI browser extensions sit inside the one place where employees paste their most sensitive work, and many of them can read every page, every prompt and every AI answer in that browser. Sidebars that summarise pages, "chat with any model" assistants, writing helpers, meeting note takers and AI-themed productivity tools are installed in minutes from public stores, usually without IT involvement. Research published in 2025 and 2026 showed extensions with hundreds of thousands to millions of users quietly capturing conversations with ChatGPT, Claude, Gemini and other assistants. This guide covers what makes AI extensions a distinct risk, how to vet them, how to enforce an allowlist with Chrome and Edge policies, and what to monitor. It is written for endpoint, browser and security engineering teams, and for AI governance leads who need the browser layer under control. General extension hygiene and enterprise browser selection are covered in the Browser Extension Security Guide and the Enterprise Browser and Browser Security Guide; this page focuses on the AI-specific layer.

Key takeaways

AI extensions see the crown jewels by design. To summarise a page or a chat they need page content access, and that same access exposes prompts, AI responses, internal web apps and session cookies.
"Prompt poaching" is a documented pattern. Fake AI sidebars and even legitimate, Featured extensions have been caught capturing AI conversations and sending them to their own servers.
Store badges and install counts are not vetting. Several extensions involved in AI chat harvesting carried the Chrome Web Store Featured badge.
Block by default, then allow by ID. The ExtensionSettings policy in Chrome and Edge gives you default blocking, per-extension allow or force install, permission blocking and per-site restrictions.
Updates change the risk. A silent update can add data collection to an extension you approved last year, so pin approvals to behaviour, review updates and watch store status.

Why AI extensions are a different risk

Every browser extension with broad host access is a potential data exfiltration path. AI extensions concentrate that risk for four reasons.

The data is richer: employees paste source code, contracts, customer records, incident notes and strategy documents into AI chats. An extension that reads the chat page reads all of it, plus the model's answers.
The permissions look justified: a page summariser genuinely needs to read page content, so a request for access to all sites does not look suspicious to a user or a reviewer.
The category attracts impostors: users search the store for "ChatGPT" or "Claude" and install whatever looks closest. OX Security found two extensions impersonating a legitimate multi-model sidebar with about 900,000 users between them (reported by The Hacker News, January 2026).
Many send data to a third-party backend: a "chat with any model" extension often proxies your prompts through the developer's own servers and API keys, so your data reaches a party with no contract with your organisation, even when the extension is not malicious.

Extensions also act inside the user's authenticated session. They can read cookies (with the cookies permission), observe pages of internal SaaS apps and, in the worst cases, act as the user. That is why extension control belongs alongside identity controls, not only endpoint controls.

How AI extensions leak data: documented patterns

Pattern	How it works	Documented example
Impostor AI sidebar	Clones the name and look of a popular AI extension, provides a working chat, and copies conversations and open tab URLs to its own server	Two extensions with about 900,000 users sent ChatGPT and DeepSeek chats and tab URLs to remote servers every 30 minutes (OX Security, via The Hacker News, January 2026)
Network hooking on AI sites	Injects a script into AI chat pages that overrides `fetch()` and `XMLHttpRequest`, so every prompt and response passes through the extension	Urban VPN Proxy and three related extensions, over 8 million installs on Chrome and Edge, harvested chats from AI platforms with collection on by default (Koi Security, via The Register, December 2025)
Behaviour added by update	A trusted, non-AI extension adds AI conversation collection in a later version, often with a consent prompt that existing users never see	Urban VPN added an AI data consent prompt in version 5.5.0 through a silent update; users who installed before July 2025 likely never saw it (The Register)
Legitimate analytics collection	A real company's extension starts collecting AI conversations under its privacy policy, sometimes guided by a remotely loaded configuration file	Secure Annex reported Similarweb and Stayfocusd collecting AI conversations; Similarweb disclosed it in policy updates around January 2026 (The Hacker News)
Hijacked developer account	An attacker gains publishing rights and pushes a malicious version of a trusted extension to every user through auto-update	The Cyberhaven Chrome Extension Breach 2024: an OAuth consent phish gave publishing rights, and the malicious version stole cookies and sessions; some variants in the wider campaign targeted AI service API keys
Prompt and page manipulation	An extension that can modify pages can alter what the user sees from an AI assistant, or insert content into prompts	A capability rather than a named incident: any extension with script injection on AI domains has it

The common thread: the extension does not need to break the AI service. It reads the page the user is already looking at. Data loss prevention on the network or in the AI tenant does not see it, because the copy happens inside the browser.

Permissions that matter for AI extensions

Chrome's permission list and install warnings are the first vetting signal. Some sensitive capabilities show no install warning at all, so reviewers must read the manifest rather than rely on what users saw.

Permission or manifest entry	Install warning shown by Chrome	Why it matters for AI use
Host permissions for all sites (`<all_urls>`, `:///*`) or AI chat domains	A site access warning (wording depends on the hosts requested)	Reads and changes every AI chat and internal web app; the core requirement for prompt poaching
`scripting`	None listed	Injects scripts into pages, including the network hooks used to capture chats
`cookies`	None listed	Reads session cookies for AI services and SaaS apps, enabling session hijacking
`webRequest`	None listed	Observes requests, including calls to AI APIs
`tabs`	"Read your browsing history"	URLs and titles of every open tab, as exfiltrated by the impostor sidebars
`clipboardRead`	"Read data you copy and paste"	Captures content copied into or out of AI chats
`debugger`	"Read and change all your data on all websites"	Full control of pages; rarely justified for an AI helper
`nativeMessaging`	"Communicate with cooperating native applications"	Bridges the browser to a local process, outside browser controls
`management`	"Manage your apps, extensions, and themes"	Can disable other extensions, including security ones
`activeTab`	None listed	Temporary access to the current tab after a user gesture; the lower-risk pattern to prefer

Manifest V3 helps, but only partly. It removes the ability for extensions to run remotely hosted code, so executable JavaScript must ship in the reviewed package, and it moves blocking request interception to declarativeNetRequest. It does not stop an extension from reading pages it has host access to, or from sending that data to its own server, or from changing behaviour through remotely loaded configuration. Treat MV3 as a floor, not a verdict.

Vetting an AI extension before approval

Use a short, repeatable review. Most organisations approve far fewer AI extensions than users request, and an alternative (the sanctioned AI assistant in the browser or a web app) usually exists.

Business need and alternative: confirm what the user wants to do and whether a sanctioned tool already does it. Many AI sidebar requests are met by the enterprise AI assistant's own web app.
Identity of the publisher: verify the developer is the AI provider or a known company, check the extension ID against the provider's own website, and treat lookalike names as impostors until proven otherwise.
Data flow: establish where prompts and page content go. If the extension proxies requests through its own backend, it is a third-party data processor and needs supplier review, a contract and a data protection assessment.
Permissions against function: compare the manifest with what the extension does. A writing helper that requests cookies, debugger or management fails. Prefer activeTab over all-sites host access.
Privacy policy and store disclosures: look for collection of "browsing data", "AI interactions" or sale to "partners". The Urban VPN case showed store listing and privacy policy can disagree.
Code and behaviour review: for high-use or high-access extensions, unpack the package, look for page script injection on AI domains, overrides of fetch or XMLHttpRequest, remote configuration fetches and analytics endpoints, and run it in a sandbox while watching traffic.
Publisher security: ask how publishing rights are protected. The Cyberhaven case shows that a trustworthy vendor with a phishable publishing account is a supply chain risk.
Approval record: store the extension ID, approved version, permissions, data flow, owner and review date, so a later update can be compared with what was approved.

Enforcing control with ExtensionSettings

Chrome and Microsoft Edge both support the ExtensionSettings policy, a JSON object keyed by extension ID with a * entry for the default. Google states that ExtensionSettings overrides the older extension policies if both are set, so pick one approach and use it consistently.

Field	Scope	Use for AI extensions
`installation_mode`	`*` or per ID	`blocked` as the default; `allowed`, `force_installed` or `normal_installed` per approved ID; `removed` to block and uninstall a bad extension. Force and normal install need `update_url` and cannot be used on `*`
`blocked_permissions`	`*` or per ID	Block permissions such as `debugger`, `cookies` or `nativeMessaging`; installed extensions that need a blocked permission stop loading, optional ones are declined at runtime
`runtime_blocked_hosts`	`*` or per ID	Stop extensions interacting with sensitive sites, including script injection and cookie access, for example the enterprise AI tenant, identity provider and finance apps (up to 100 patterns, no paths)
`runtime_allowed_hosts`	`*` or per ID	Exceptions, for example letting an approved security extension operate on blocked hosts
`minimum_version_required`	Per ID	Disable vulnerable or compromised older versions, including force-installed ones
`install_sources`, `allowed_types`	`*` only	Limit where extensions can be installed from and which types (for example exclude `user_script`)
`blocked_install_message`	`*` or per ID	Up to 1,000 characters pointing users to the request process and sanctioned AI tools
`update_url`, `override_update_url`	Per ID	Chrome Web Store: `https://clients2.google.com/service/update2/crx`; Edge Add-ons: `https://edge.microsoft.com/extensionwebstorebase/v1/crx`; override to serve updates from your own location after review

On Windows, Edge reads the policy from HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionSettings; Chrome uses its own policy path, and both can be set through Group Policy, Intune or the Google Admin console. Edge adds sidebar_auto_open_blocked (Edge 119 and later) and toolbar_state, which matter as AI sidebars multiply.

A practical baseline

Default: * set to installation_mode: blocked, with blocked_permissions covering debugger and nativeMessaging, and runtime_blocked_hosts covering the identity provider, the sanctioned AI tenant and other crown-jewel apps.
Approved AI extensions: per-ID entries with allowed or force_installed, a minimum_version_required, and their own runtime_blocked_hosts where they do not need sensitive sites.
Request path: in Chrome Enterprise Core, the extension request workflow (Chrome 92 and later) lets users request from the store while the store mode is "Block all apps, admin manages allowlist, users may request extensions". It relies on the CloudExtensionRequestEnabled and CloudReportingEnabled policies.
Other browsers: a policy that covers only Chrome pushes users to Edge, Firefox or an AI-native browser. Apply equivalent policy everywhere, or restrict which browsers can reach corporate apps. See the Enterprise Browser and Browser Security Guide.

Rolling out an AI extension allowlist

Inventory first: turn on Chrome browser reporting (or Edge management reporting) and pull the Apps & extensions usage report. Google's report shows install type, store status (including "taken down by Google"), permission count, manifest version and, for public extensions, a third-party risk assessment. Tag every extension with AI in its name, description or host permissions on AI domains.
Triage: remove anything already reported as malicious or taken down with installation_mode: removed straight away. Review the top AI extensions by install count with the vetting steps above.
Publish the allowed list and the sanctioned AI tools: users accept a block far better when the message names the approved alternative.
Pilot ring: apply the block-by-default policy to IT and security staff, then to one business unit, for two to four weeks. Collect requests and broken workflows.
Enforce in waves: extend to the rest of the organisation by business unit, starting with teams that handle the most sensitive data (legal, finance, engineering, HR).
Roll back safely: keep the previous policy JSON under version control. If a wave breaks critical work, revert that organisational unit's policy rather than adding broad exceptions, then fix the allowlist.
Operate: review new requests weekly, re-review approved AI extensions at least annually and whenever permissions change.

Decision guidance

Block all AI extensions or allow a few: block all where a sanctioned enterprise AI assistant is available and data is highly sensitive; allow a short list where specific productivity gains are proven and the vendor signs a data processing agreement.
Force install or allow: force install the sanctioned AI extension when you want consistent configuration and to make the approved route the easy one; allow (user choice) for niche tools used by a few teams.
Extension or web app: prefer the AI provider's web app or a managed enterprise browser feature when it meets the need. A web app does not get standing access to every other tab.
Small organisations: a block-by-default policy with five to ten allowed extensions, managed in the Google Admin console or Intune, is achievable in a day and removes most of the risk. Skip code review; rely on publisher identity, permissions and data flow.
Large organisations: add a formal request workflow, automated manifest analysis, code review for high-access extensions, per-department allowlists and integration with third-party risk management.
Unmanaged and personal devices: extension policy only applies to managed browsers or profiles. Restrict access to AI tenants and sensitive SaaS from unmanaged browsers through conditional access, or use an enterprise browser or browser isolation for those users. See the Remote Browser Isolation Guide.

Where identity fits

Extensions that read cookies or act in authenticated pages are, in effect, unmanaged non-human actors operating with the user's identity. Two identity points matter most. First, publishing rights for your own extensions are privileged access: protect the developer accounts, restrict OAuth consent for store publishing scopes and keep publishing to a small group. See the Consent Phishing and Illicit OAuth Grants Guide. Second, when a malicious AI extension is found, treat any session the browser held as exposed: revoke sessions for the affected users in the identity provider and AI tenants, and rotate AI service API keys that were used or visible in that browser. See the API Key Management Guide.

Detection and measurement

What to monitor

Extension inventory changes: new installs, new versions and permission changes from browser management reporting, especially for extensions with host access to AI domains.
Store status: notifications that an installed extension was taken down by Google or unpublished in the last 28 days, as surfaced in the Chrome usage report.
Network destinations: browser traffic to analytics or collection endpoints associated with extensions, and periodic beacons (the impostor sidebars sent data every 30 minutes) from managed endpoints.
Policy bypass: developer mode installs, sideloaded extensions and unmanaged browser use on managed devices.
Session anomalies: AI tenant or SaaS sessions reused from unexpected IP addresses or devices, a sign of cookie theft (ATT&CK T1539).

Metrics

Percentage of managed browsers under block-by-default extension policy (target 100% of managed endpoints).
Number of distinct AI extensions installed across the estate, and the share that are approved.
Median time from extension request to decision.
Time from a public malicious-extension report to removal from all endpoints (target: same day).
Percentage of approved AI extensions re-reviewed in the last 12 months or since their last permission change.
Count of extensions with all-sites host access, trended down over time.

Common failure patterns

Trusting the Featured badge: Urban VPN Proxy and one of the impostor AI sidebars carried it while collecting AI conversations. Badges reflect store review at a point in time, not your data policy.
Approving once, never again: an extension approved in 2024 added AI chat collection by update in 2025. Without version pinning or permission-change alerts, nobody notices.
Chrome-only policy: users move to another browser and install the same extension there. Extension control must cover every browser that can reach corporate data.
Allowlisting by name: impostors copy names. Allow by extension ID, verified against the publisher's own site.
Ignoring your own extensions: an organisation that publishes an extension can become the supply chain incident, as in the Cyberhaven Chrome Extension Breach 2024, where an OAuth grant bypassed MFA and the malicious version was live for about 30 hours.
No response playbook: removing the extension without revoking sessions and rotating exposed API keys leaves stolen access usable.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK	T1176.001 Browser Extensions	Malicious or hijacked extensions as a foothold in the browser
MITRE ATT&CK	T1539 Steal Web Session Cookie; T1185 Browser Session Hijacking	Cookie theft and acting in authenticated AI and SaaS sessions
MITRE ATT&CK	T1217 Browser Information Discovery; T1567 Exfiltration Over Web Service	Collecting tab URLs and sending chat data to web endpoints
NIST SP 800-53 Rev. 5	CM-7(5) Authorized Software, Allow-by-exception; CM-11 User-installed Software; CM-8 System Component Inventory	Allowlisting, controlling user installs and keeping the extension inventory
NIST SP 800-53 Rev. 5	SA-9 External System Services	Extensions that send prompts to a third-party backend
NIST CSF 2.0	ID.AM-02; PR.PS-01; PR.PS-02; DE.CM-09	Software inventory, configuration management, removing risky software, monitoring runtime environments
OWASP Top 10 for LLM Applications 2025	LLM02:2025 Sensitive Information Disclosure	Prompts and responses exposed through the client side

Practitioner checklist

Pull the extension inventory from browser management reporting and tag every AI-related extension.
Remove extensions reported as malicious or taken down, using installation_mode: removed.
Set ExtensionSettings with * blocked by default in every managed browser, not only Chrome.
Block high-risk permissions such as debugger and nativeMessaging, and use runtime_blocked_hosts for the identity provider and AI tenants.
Approve AI extensions by verified ID after checking publisher, data flow, permissions and privacy policy.
Set minimum_version_required and alert on permission changes in approved extensions.
Offer a request workflow and name the sanctioned AI tools in the block message.
Restrict AI tenant and SaaS access from unmanaged browsers through conditional access.
Write a response runbook: remove, revoke sessions, rotate exposed AI API keys, notify data protection.
Protect publishing accounts and OAuth consent for any extension your organisation publishes.

AI Browser Extensions Security Guide: Risks, Vetting and Controls