Skip to main content
The browsers are not equally served. Read this table before you plan a rollout.Chrome and Edge take one extension id and one update URL, and they must be used together: see Fleet deployment.
Where this lives in the product, and how the rollout screen is organised.The card is Context Firewall (Browser Extension), in the Context Firewall section of the Connectors page, beside the Discovery Sensor.Its rollout studio asks which browser before it asks which console, because the browser decides the mechanism and the console only decides where you paste the result. That ordering is what stops the screen offering an Intune-shaped flow for Safari, which has no such flow. It also means the work is done once per browser you run: there is no cross-browser extension-deployment primitive in any MDM, and there is not going to be one.
  • Chrome & Edge are a single target. Edge reads the same Chromium policy as Chrome at its own path, and every artifact the studio generates carries both, so there is nothing separate to deploy for Edge.
  • Safari is its own target: a signed package plus a declaration, never ExtensionInstallForcelist.
  • Firefox is shown but cannot be selected, and its steps render read-only with no copy or download control, because there is no artifact to roll out. See the Firefox card above for exactly what is missing.
The Context Firewall runs inside the browser, before a message is sent to a browser-hosted AI assistant (ChatGPT, Gemini, Copilot, Claude, Perplexity). It masks personal data and blocks secrets in what your staff type, with no message content ever leaving the tab. This page covers getting it onto machines — one at a time, or across a fleet through the same managed-policy channel you already use for other extensions.

​
Supported browsers

The extension is a Manifest V3 build, and its interception relies on reaching the page’s MAIN world. Chrome and Edge run world: "MAIN" content scripts natively; Firefox has since 128, so it gets its own Gecko build. Safari does not support that manifest key at all — so the Safari build reaches MAIN the classic way instead, by having its isolated content script inject a <script src> element pointing at a web-accessible resource. That path works on every engine, and the Safari build asserts it survived conversion on every release.

Google Chrome

Supported. Chrome 128+ on Windows, macOS, Linux and ChromeOS.

Microsoft Edge

Supported. Edge 128+ (Chromium). Same package as Chrome.

Safari

macOS 13+, on both Apple silicon and Intel, as a Safari web extension delivered inside a signed, notarized macOS app. Safari drops the world: "MAIN" manifest key, so the build uses the injected-<script> fallback to reach the page world; and every release asserts that fallback survives the conversion. The package is signed, notarized and stapled. Enabling a Safari extension is a manual step in Safari’s own settings on each Mac, which is why the rollout below is a package plus a declaration, and why you should run Verify it is actually working on the first Mac you deploy to. Fleet rollout is the .pkg + managed-extension declaration below, not ExtensionInstallForcelist. Not available on iOS or iPadOS: Safari there takes extensions only through the App Store. Where the extension is not deployed, the Deployed Sensor’s egress proxy still governs the same hosts on the machine: see Install the Deployed Sensor.

Firefox

There is no way to install it today. The Gecko build exists (extension-firefox/, carrying the browser_specific_settings.gecko id Firefox requires) and is web-ext linted, but nothing signs an .xpi, nothing is published to addons.mozilla.org, and VisIQ’s distribution endpoint serves no Firefox artifact, so there is no install path to give you. Firefox 128+ would be the floor when there is one (that is where Gecko gained world: "MAIN" content scripts). To govern Firefox users today, use the Deployed Sensor’s egress proxy instead: see Install the Deployed Sensor.

​
Manual install (a single machine)

Use this for a proof of concept on one endpoint, to try the firewall before a rollout, or to verify policy behaviour. No MDM is needed.
You can evaluate it without an account. The firewall masks and blocks on its own the moment it is installed — detection runs entirely in the browser, and an unenrolled install makes no network requests at all. Enrolment is only needed if you also want its decisions to appear in your VisIQ dashboard. For a quick look at what it does, install it, skip enrolment, and go straight to Verify it is actually working.One thing to know if you enrol later: decisions made while unenrolled are kept on the device, not discarded, and are sent to your organization when you enrol. Those records never contain the message itself — they carry the rule that fired, the kinds of value detected, counts and timing. If you want an enrolled test to start from a clean slate, remove and reinstall the extension before enrolling.
An enrolment code belongs to the organization that is active when you generate it. Every browser enrolled with it reports to that organization. If you belong to more than one organization, check the account switcher shows the right one before you generate the code.
The way to put the extension on a single Chrome or Edge machine and have it stay there and update itself. It is the same policy the fleet rollout uses, applied to one machine by hand, so what you evaluate is what you will deploy.Chrome and Edge install an extension that is not on a store only when the browser is managed. On a machine that is not domain-joined, Entra-joined or enrolled in an MDM, the policy is read and the install is refused. If that is your situation, use the load unpacked tab.
1

Write the policy

Apply the ExtensionInstallForcelist entry from Fleet deployment to the one machine: a .reg file on Windows, a .plist in /Library/Managed Preferences on macOS, or a JSON file in /etc/opt/chrome/policies/managed on Linux.
2

Restart the browser

Chrome and Edge install force-listed extensions at start, so a browser left open keeps its old state until it restarts.
3

(Optional) Enrol the browser to your organization

In VisIQ, from your organization, open Context Firewall → Endpoints → Enrol a browser to generate a single-use code. Then open the extension’s options (right-click its toolbar icon and choose Options, or go to chrome://extensions → Details → Extension options) and paste the code.Or set the enrolment policy alongside the forcelist and the browser enrols itself, with nobody touching the machine: that is the second half of Fleet deployment.The message itself never leaves the browser. A decision reports counts, detector kinds and rule ids, and carries masked values (stored encrypted, revealed one at a time) only when your workspace has turned on masked-value retention under Settings → Context Firewall.

​
Fleet deployment (managed browsers)

Force-installing through your browser-management policy is the way to keep the extension present and non-removable across the estate. It is the same ExtensionInstallForcelist mechanism you already use for other managed extensions: a force-installed extension is silently installed and cannot be disabled or removed by the user. It keeps itself up to date only if you also set the ExtensionSettings entry below, because it is not listed in a store. Pick the console that manages your browsers.
One id, one update URL, and they are used together. An id and an update URL that do not belong together is the one mistake that fails silently: the browser finds nothing to install and the policy sits inert rather than erroring.The same pair covers both Chrome and Edge. Edge reads the Chromium policy under its own namespace, so the value you paste is identical and only the policy path differs.VisIQ serves this itself rather than through a store, which puts you in control of when a fix reaches your estate: VisIQ publishes, your browsers pick it up on their next update check, and no third-party review sits in between. That update check reaches VisIQ only when the ExtensionSettings entry below is in place; see Keep it up to date.The extension installs only on a managed browser. That is a Chromium rule for anything not carried by a store, not a VisIQ one: a browser that is not domain-joined, Entra-joined, MDM-enrolled or cloud-managed reads the policy and declines the install. For machines outside your management, use the load unpacked tab above.
The force-install list installs the extension. It does not keep it updated. Chrome and Edge use the update URL in ExtensionInstallForcelist for the first install only. Every later update check goes to the update URL recorded inside the installed extension, or to the one in the ExtensionSettings policy when that policy sets override_update_url for the extension. Builds before 0.1.20 record no update URL of their own, so a browser holding one of them with only the force-install list asks the Chrome Web Store’s update service for updates (Edge does too), where this extension is not listed, and stays on the version it first installed.Set this ExtensionSettings entry alongside the force-install list, for Chrome and for Edge. It points every update check at VisIQ, whatever build is installed:
ExtensionSettings is one JSON object for every extension. If your estate already sets it (a "*" default that blocks other extensions is common), add this key to your existing object rather than replacing it, or you will drop your own entries. Adding it to a browser that already has the extension moves that browser to the current version on its next update check, in place, with no reinstall.
In the Google Admin console → Devices → Chrome → Apps & extensions → Users & browsers, select the org unit, then + → Add Chrome app or extension by ID and switch the source to From a custom URL. Adding “by id” alone assumes a store listing, and there is none: supply the id and the update URL from the table above together, then set Installation policy → Force install (optionally Force install + pin). The console turns this into the install policy for every managed browser in that OU.To apply it by Group Policy instead of the console, the equivalent Windows registry / ADMX values are the force-install entry and the ExtensionSettings entry from the warning above, the second as a single-line JSON string:
On macOS, the same keys are delivered as a configuration profile:
ExtensionSettings is one policy for every extension. If you already set it, add this entry to your existing value rather than replacing it.Keep it updating. The Apps & extensions page has no setting for where later updates come from, so add the override through Menu → Chrome browser → Custom Configurations: select the same organisational unit, paste this into Configurations, and click Save. It applies to browsers enrolled in Chrome Enterprise Core, not to ChromeOS devices; for those, open the extension’s row in Apps & extensions, go to Deployment settings, set Installation URL to the custom URL above and Update URL to Installation URL (see above). If your configuration already sets ExtensionSettings, add our key inside that object instead of adding a second one.
Already rolled out through the console without it? Add only this configuration. Each browser updates in place at its next update check once the policy reaches it; nothing is reinstalled.

​
Pre-enrol the whole fleet

A force-installed extension is present on every managed browser, but each still needs to be enrolled to your tenant to report. Rather than enrolling each by hand, push the enrolment values alongside the force-install policy using the browser’s managed configuration, so a machine is governed the moment the extension lands. Generate the fleet token in Context Firewall → Endpoints.
Self-enrolment needs 0.1.9 or later. Builds before it ignore the managed configuration entirely, so a policy written against one silently does nothing. If you built a policy before 2026-09-20 and saw no endpoints appear, it starts working once each browser restarts onto a current build.Check what your machines are actually running with Verify it is actually working before concluding a policy is at fault.
The extension reads exactly three keys:
Put something machine-specific in label, or every endpoint under one policy looks the same. A browser extension cannot read the machine name: nothing in the extension APIs exposes it. So the label you set here, plus the browser family, is the whole of what distinguishes one endpoint row from another, and one policy pushed to 500 machines produces 500 rows reading Managed Chrome - EMEA chrome endpoint. That string is what the Endpoints table shows, what every receipt carries, and what the events page filters on.Where the policy is delivered by a SCRIPT, add the machine name in the script. The PowerShell the rollout studio generates for Intune already does this, appending $env:COMPUTERNAME. On Jamf or any other console that runs a shell script, append $(scutil --get ComputerName) or $(hostname) the same way.Where it is delivered as a FILE, it cannot be done. A .reg file and a macOS configuration profile are literal bytes and expand no variables, so a fleet configured that way shares one label by construction. If you need per-machine identity there, deliver the enrolment values by script instead, or use a separate policy per group and give each its own label.
The id in this policy must be the id of the route you force-installed from. Managed configuration is delivered to a specific extension id, so a policy written against the store id while the browser installed the self-hosted build (or the reverse) is delivered to an extension that is not there. Nothing errors: the extension installs, finds no configuration, and stays unenrolled, which is indistinguishable from a rollout still in progress.
Chrome and Edge: the values live under 3rdparty.extensions.<extension id>. For the self-hosted route documented above:
Deliver it as Google Admin → the extension → Policy for extensions, as the 3rdparty key of an OS-level policy (macOS configuration profile for com.google.Chrome, or com.microsoft.Edge for Edge), or on Linux in /etc/opt/chrome/policies/managed/. On Windows by Group Policy the same values are registry entries under:
Microsoft Intune cannot deliver this through the Settings catalog, and that is the one place you would look for it. The force-install entry above IS a Settings catalog setting, so it is reasonable to expect its companion to be one too. It is not: there is no Chromium managed-configuration (3rdparty) setting in the Edge or Chrome settings catalog at all, verified against the live setting definitions on 2026-09-19. Searching for it returns policies whose names merely contain managed or third party, which is worse than an empty result because one of them looks close enough to try.Deliver the three values to Windows machines as registry writes instead, through whichever mechanism your estate already uses for registry state: Group Policy preferences, an Intune remediation (Devices → Scripts and remediations), or a platform script. Write them under the browser you force-installed into:
with controlPlane, fleetEnrollToken and label as REG_SZ values. The extension reads them through chrome.storage.managed exactly as it reads a policy delivered any other way.⚠️ Verify enrolment from the product, not from Intune. A green assignment means the policy was delivered, never that a browser enrolled: the browser must also start and read it. The honest check is that an endpoint appears under Context Firewall → Endpoints, or that GET /api/firewall/endpoints returns one.
Firefox: the same three keys, but Firefox spells the tree 3rdparty.Extensions (capital E) and keys it by the add-on’s gecko id, in policies.json:
The Firefox form is documented here because the keys are the same and the policy is worth preparing, but as the Firefox card above says, there is no signed Firefox build to install today, so this policy has nothing to configure yet.
You can generate all of these prefilled with your own tenant’s values (including the Windows .reg and the macOS profile) from Context Firewall → Deploy in the dashboard, rather than editing the examples above by hand.

​
Keep it up to date

The two platforms update differently, and one of them is not automatic. Know which you are on before you assume a fix has reached the fleet.
Forcing a Chrome update sooner. On a managed browser, visiting chrome://extensions (or edge://extensions), enabling Developer mode and choosing Update runs an update check straight away. Useful for confirming a rollout rather than waiting out the cycle.⚠️ If Update reports success and the version does not move, check ExtensionSettings first. Without it the check goes to the browser’s store, which does not list this extension, so the button succeeds and nothing changes. chrome://policy shows whether ExtensionSettings reached the browser.⚠️ Restarting the browser is NOT a reliable way to pull an update forward. Chrome queries the update manifest at startup only when a forced extension is missing. Once it is installed and the policy is satisfied, a restart makes no update query at all and the periodic cycle is the only remaining trigger. If you need a specific version on a machine now, use the Update button above rather than telling people to reboot.
Automatic update is the browser’s behaviour, not something VisIQ drives. Chrome and Edge poll the update manifest on their own cycle, and the things most likely to make you misread a rollout are written up above: without ExtensionSettings no update ever arrives, and a restart does not pull an update forward. If a fix matters on a specific machine today, check that machine’s version with Verify it is actually working rather than assuming the cycle has run.
For Safari, point your MDM at the stable URL rather than a versioned file, so a release does not need a change on your side. The URL, the version header it returns and a ready-made Installomator label are all under Keeping the Safari fleet current in the Safari tab of Fleet deployment.
A pinned version is a fleet that never gets a fix. If your MDM caches the installer or you host a copy internally, put a recurring check on that stable URL — otherwise a detection fix we publish will never reach the machines that most need it.

​
Check what is being served right now

You do not have to take our word for which version your fleet is converging on. Each route answers for itself:

​
Verify it is actually working

Do this once per browser type after the first rollout, before you tell anyone they are covered. It takes a minute and it is the difference between “the extension is installed” and “the firewall is running”.
1

Open a governed assistant

Go to any of the covered sites — chatgpt.com, claude.ai, gemini.google.com, copilot.microsoft.com or perplexity.ai.
2

Check that masking fires

Type this into the message box and send it:
The message should send with the card number replaced, and a notice should appear saying what was masked. 4111 1111 1111 1111 is the standard Visa test number, not a real card — the detector validates a Luhn checksum, so an ordinary 16-digit order number is not mistaken for one.
3

Check that blocking fires

Then send:
This should be blocked outright rather than masked. Credentials are stopped, because a partially masked key is still a leaked key if its shape gives it away. (This is Amazon’s own published example key pair, not a live credential.)
4

Check that it stays quiet otherwise

Send an ordinary question such as What is the capital of France?. Nothing should happen — no notice, no delay. The firewall acts only on sensitive content, and a rollout where users see notices on ordinary messages will not survive contact with the estate.
If nothing happens on the first two steps, the extension is installed but not intercepting. Do not assume coverage. On Safari, the usual cause is that the extension is enabled but has not been granted access to the site — open Safari → Settings → Extensions → VisIQ Context Firewall and confirm the assistant hosts are allowed, or push the AllowedDomains declaration above so the grant is not left to each user. On Chrome or Edge, confirm the browser is version 128 or later; older versions cannot run the interception and the extension will sit inert.

​
After install

Open Context Firewall → Endpoints to see which browsers have enrolled and what state each is in. A browser that force-installed but has not yet enrolled shows as Not reported recently until its first heartbeat arrives. Discovered-but-unenrolled browsers are listed separately — the two populations are deliberately not joined, because they are measured differently.