Trust Center

Deploy it to the fleet, lock the settings, and know what you cannot lock.

Bolt ships enterprise deployment kits for both halves of the product: the desktop app and the browser extension. Settings can be pushed from the management platform you already run and pinned so users cannot change them, and on Chromium the extension genuinely cannot be removed or disabled. This page says which parts are enforceable, and which are not.

Request the deployment kits Trust Center →

The browser extension

Force-installed, and no store listing required.

Your organization hosts the package. Administrators usually ask about the store first, so here is the answer per browser.

Browser
How it is deployed
What to know
Chrome, Edge, Brave
Force-installed by policy from a signed package your organization hosts on its own internal HTTPS server. Set installation_mode to force_installed and the user cannot remove or disable it, and the browser puts it back if the profile is reset.
No public Web Store listing is involved.
Firefox
Force-installed through the policies.json mechanism from your own internal URL, with admin settings delivered through the same key names as Chrome.
Mozilla must sign the package, which is free and produces no public listing. Firefox release builds refuse unsigned add-ons and enterprise policy cannot override that.
Safari
Ships inside the signed and notarised Bolt desktop app as a Safari Web Extension, built from the same package as the Chrome one. Installing the app installs it.
No App Store submission. Admin policy reaches it through a native bridge, because Safari's managed-storage channel is unreliable and would otherwise drop the extension back to defaults without saying so.

The desktop app

Policy from the platform you already run.

Platform
How policy is delivered
On preventing removal
macOS
A configuration profile payload targeting the app's bundle id, deployable through Jamf Pro or Intune, with a ready template in the kit.
Deploy the profile as non-removable on a supervised device and the locked settings stand. Restricting removal of the app itself needs Automated Device Enrolment.
Windows
Group Policy templates (ADMX and ADML) so the settings appear in the Group Policy Editor and can be ingested by Intune.
A required Intune app reinstalls after removal, the entry can be hidden from Programs and Features, and AppLocker or WDAC stops a substituted binary running.

How settings are pinned

Two tiers, and the difference is the whole rollout decision.

Tier
What it is
When to use it
Forced
Read from the management-owned location: the MDM's managed preferences on macOS, the Group Policy tree on Windows. The setting is locked in the app: it renders as managed by your organization and the control is disabled.
Use this for anything your policy requires.
Device default
Read from the administrator-writable location. It gives the user a starting value they can still change.
Use this for sensible defaults you do not need to enforce.

The user's own settings are never read as policy

On macOS a user can write their own preference file, and on Windows a user can write their own registry hive, both without any privilege at all. Because a forced setting wins outright, reading either would let any user hand themselves policy, including switching the data-protection guard off. Neither is read, and a test pins it.

A lock means the platform said so

The app asks the operating system whether a setting is forced rather than inferring it from the value being present. A central server never claims to have locked something on a laptop it has not touched, because that would show a lock badge for an enforcement that does not exist.

What cannot be prevented

No application can stop its own removal, including ours.

How close you get is a property of your management platform, not of the software, and we would rather you plan around the real answer.

An unmanaged administrator on their own machine can defeat any on-device control

This is true of every product in this category. It is why the browser extension and the network layer exist alongside the app rather than instead of it, and why the coverage signal in the admin console matters: the useful question is not whether the control can be defeated, it is whether you find out.

Fleet coverage reporting is deliberately conservative

The admin console reports how many people have actually produced governance events. It does not claim a per-device attestation it cannot make, and it undercounts rather than overcounts: a device that is enrolled but idle does not appear. A number that flatters the rollout would be worse than a number that is short.

Send us your management platform and we will send the kit.

Jamf, Intune, Group Policy, Workspace, or something else. The kits include ready templates, the deployment steps, and how to verify the policy actually landed on a device.

Request the kits Supply chain evidence →