Bolt Desktop Administrative template for the Bolt desktop app (Sparcle). Bolt Desktop 0.1 or later Bolt Desktop Admin-controlled AI data-loss-prevention, input-guard and page-capture policy for the Bolt desktop app. Every setting in this category writes HKLM\SOFTWARE\Policies\Sparcle\Bolt and is treated by Bolt as a locked policy: it wins over the machine's own defaults and the app shows it as "Managed by your organization". A setting left Not Configured falls through to the device default (HKLM\SOFTWARE\Sparcle\Bolt, which a provisioning script may set) and then to Bolt's built-in floor. Only four settings in this category are also served by your Bolt deployment: the enforcement level, the two AI-destination lists and the corporate-domain exemptions. For the other twelve there is no deployment-served value at all - what is written on the device is what governs, alongside Bolt's built-in default. HOW the sources combine is per setting, not per tier, and is stated in each setting's own help. These settings apply to computers, not users. Bolt never reads per-user policy, because any signed-in user can write their own registry hive without administrator rights. Enforcement level Sets what Bolt does when it detects sensitive data heading for an AI destination. Off Detect nothing. Warn Warn the user, allow the action. Redact Mask the sensitive spans, allow the rest. Block Refuse the action. The MOST RESTRICTIVE level across all policy sources wins, even over this one. Setting Warn here will not relax a Block configured centrally in your Bolt deployment; it only raises a laxer setting. This is one of the four settings your Bolt deployment also serves. If disabled or not configured, the level comes from the device default, the level your deployment serves, and Bolt's built-in floor - and since the most restrictive of those wins too, leaving this unset never weakens protection. Off Warn Redact Block Enable AI data-loss prevention Turns Bolt's AI data-loss prevention on or off for this machine. Enabled turns it on and locks it on. Disabled turns it off and locks it off. Not Configured leaves the decision to the device default and then to Bolt's built-in floor, under the ordinary rule that off beats on. Your Bolt deployment does not serve this setting, so it is governed on the device or not at all. Because a locked switch wins outright, Disabled turns protection off for this machine and nothing else can turn it back on - which is almost never what you want, so prefer Not Configured unless you are deliberately carving out an exception. Enable the on-type input guard Turns on the guard that inspects text as the user types it into a covered site, rather than only on paste or submit. Enabled turns it on and locks it on. Disabled turns it off and locks it off. Not Configured leaves it to the device default and then to Bolt's built-in floor, under the ordinary rule that off beats on. Your Bolt deployment does not serve this setting. Which sites are covered is controlled by "Sites covered by the on-type input guard" and "Sites exempt from the on-type input guard". Enable page capture Turns on Bolt's page capture for this machine. Enabled turns it on and locks it on. Disabled turns it off and locks it off. Not Configured leaves it to the device default and then to Bolt's built-in floor, under the ordinary rule that off beats on. Your Bolt deployment does not serve this setting. Use "Sites exempt from page capture" to carve out individual hosts rather than disabling the feature outright. Require a PIN to unlock the vault Requires a PIN to unlock Bolt's vault, instead of allowing it to stay unlocked. Enabled turns it on and locks it on. Disabled turns it off and locks it off. Not Configured leaves the decision to the user's own vault setting. Your Bolt deployment does not serve this setting, so it is governed on the device or not at all. Works together with "Vault auto-lock timeout": a PIN only re-gates the vault at the moments the timeout locks it, so a Not Configured or 0-minute (Never) timeout alongside this makes the requirement largely theoretical. Require a master password for the Bolt vault Requires every user to protect Bolt's own vault with a master password. When on, Bolt refuses every vault reveal, in its own vault and in connected password managers, until the master password has been entered once in the session. A PIN, a password manager sign-in, or Touch ID, the Mac password or Windows Hello can re-unlock or reset the PIN only within that session, never in place of the master password. Only the recovery phrase the user saves at setup can reset the master password. This is an access gate in the running app. Vault records already stored on the device are not yet re-encrypted under the master password: they stay protected by the device key, as without this setting. Enabled turns it on and locks it on: a user without a master password is asked to set one before the vault opens, and cannot turn it off. Disabled or Not Configured leaves it to the user. Your Bolt deployment does not serve this setting, so it is governed on the device or not at all. There is no administrator reset. A user who loses both the master password and the recovery phrase cannot unlock the vault in Bolt. Allow Bolt to install its local certificate authority Controls whether Bolt may add its own local certificate authority to the signed-in user's Trusted Root Certification Authorities store, so that external browsers and the Bolt browser extension reach the loopback server over HTTPS without a certificate warning. DEFAULT OFF, AND "NOT CONFIGURED" ALSO MEANS OFF. This is the only setting in this template that works that way. Any device that receives Bolt policy at all is treated as managed, and on a managed device Bolt does not install a root certificate unless this setting is explicitly Enabled. When it is off, Bolt hides the offer entirely: the first-run card is not shown, the menu bar item is not shown, and the start-up install does not run, so nothing prompts the user and nothing writes to the certificate store. Adding a root certificate is MITRE ATT&CK T1553.004 and most EDR products alert on it. Leaving this off means Bolt never generates that event on your fleet. WHAT IT COSTS WHEN OFF. Nothing stops working. With the certificate off, Bolt automatically serves its loopback server over plain HTTP instead, because serving HTTPS that the device has been told not to trust would leave browsers on a warning page and the browser extension unable to connect at all. The app window, an external browser tab and the extension all keep working. The real cost is HTTP/2. The app window and a browser tab drop to HTTP/1.1, which caps how many requests a browser runs concurrently against one origin, so both get slower under load. They do not break. The browser extension loses nothing, because its bridge was always HTTP/1.1. Loopback HTTP is still a secure context under the web platform spec, so service workers, crypto.subtle and streaming continue to work, and the traffic never leaves the machine. ONE UPGRADE-TIME EFFECT WORTH SCHEDULING AROUND: an https address and an http address are different origins to a browser, so per-origin storage does not carry across the switch. Users are signed out once and sign in again, on the first launch after this policy applies, and once more if you later Enable it. Enabling this later gives the fleet HTTP/2 back on the next launch with nothing to clear on any device: Bolt derives the transport from this policy rather than recording it. Enabled: Bolt may install its local certificate authority. The user is still asked - Windows shows its own Security Warning dialog naming the certificate, and the user may decline. Disabled: Bolt may not install it, and does not offer to. Not Configured: same as Disabled on any managed device. Your Bolt deployment does not serve this setting; it is governed on the device or not at all. AI destinations to protect Hostnames Bolt treats as AI destinations, in addition to the ones it already knows about. Enter one hostname per line, without a scheme or path - for example: chatgpt.com claude.ai copilot.microsoft.com These lists are combined by UNION across every policy source: entries you add here always take effect, and another authority can add more but can never remove yours. Adding a host only ever widens protection. If not configured, Bolt uses its built-in list plus whatever your deployment sets. Desktop applications to treat as AI destinations Identifiers of other desktop applications Bolt should treat as AI destinations, so pasting into them is governed by the same policy as an AI website. Enter one identifier per line. On Windows this is the executable name as Bolt reports it in its activity log; the key is shared with macOS, where it is a bundle identifier such as com.openai.chat. Combined by UNION across policy sources - every entry adds coverage and none can be removed by another authority. Sites covered by the on-type input guard Extra hostnames the on-type input guard watches, beyond the AI destinations already covered. Enter one hostname per line, without a scheme or path. Use this for internal sites where typed content should be inspected - a ticketing system or webmail, for example. Combined by UNION with anything set as a device default. Your Bolt deployment does not serve this list. Requires "Enable the on-type input guard" to be on. Corporate domains exempt from policy Domains that count as your own infrastructure, so sending data to them is not treated as an AI destination. Enter one domain per line, without a scheme or path - for example: example-corp.com internal.example-corp.com These lists are combined by INTERSECTION across policy sources: every entry is a HOLE in the policy, so a stricter authority can remove your exemptions but can never add its own. Only a domain that EVERY source exempts is actually exempt. An explicitly empty box is a real setting and not the same as Not Configured: it closes every hole. Not Configured leaves the exemption unset, so your deployment's list applies as-is. Confirm which one you wrote with: reg query "HKLM\SOFTWARE\Policies\Sparcle\Bolt" /v allowedCorpDomains Sites exempt from the on-type input guard Hostnames the on-type input guard must ignore, even when they would otherwise be covered. Enter one hostname per line, without a scheme or path. Combined by INTERSECTION across policy sources: every entry is a hole in the policy, and only a host every source exempts is actually exempt. An explicitly empty box closes every hole; Not Configured leaves the exemption unset. Sites exempt from page capture Hostnames page capture must never record. Enter one hostname per line, without a scheme or path. Use this for sites that must not appear in captured history at all, such as a payroll or health portal. Combined by INTERSECTION across policy sources: every entry is a hole in the policy, and only a host every source exempts is actually exempt. An explicitly empty box closes every hole; Not Configured leaves the exemption unset. Network filter mode Choose what the macOS network filter does today. Observe records flows from ungoverned apps to AI endpoints and allows them through, never drops. Enforce records the intent to block; nothing is dropped in this build. Blocking arrives in a later version. The mode can be moved in EITHER direction so a fleet can roll it out and roll it back if a group hits a problem. A locked value set here wins over a device default and over Bolt's own default. Your Bolt deployment does not serve this setting; if not configured, Bolt uses the device default then its built-in floor. Any value other than Observe or Enforce is read as Observe. Observe only (records; never drops) Enforce policy (intent recorded; nothing dropped in this build) Terminal governance mode Controls whether Bolt's process-exec monitor (Windows phase 1: shell/terminal commands) only observes and records sensitive content in command lines, or actively enforces policy on it. Observe Watch and record; block nothing (no enforcement path exists yet). Enforce Reserved for a later phase. Observe only Enforce policy Bolt deployment URL The URL of your organization's Bolt deployment, which the desktop app contacts for org-wide policy and account state. Enter a full URL including the scheme - for example https://bolt.example-corp.com Locking this prevents a user from pointing the app at a different deployment. If not configured, the app uses the device default and then its built-in default. Launch mode How the Bolt window presents itself when launched. Native app A normal application window. Popup A transient popup. Sidebar Docked to the side of the screen. If not configured, the app uses the device default and then its built-in default. Native app window Popup Sidebar On-type input guard scope How widely the on-type input guard applies. AI sites only Only the AI destinations Bolt protects, plus any sites added by "Sites covered by the on-type input guard". All sites Every site the user types into. All sites is materially more intrusive and noticeably heavier; prefer AI sites only unless you have a specific reason. Requires "Enable the on-type input guard" to be on. If not configured, the app uses the device default and then its built-in default. AI sites only All sites Vault auto-lock timeout How long the vault may sit idle before Bolt locks it and requires unlocking again. 1 minute 5 minutes 15 minutes 30 minutes Never Do not auto-lock on idle. Locking this prevents the user from choosing a longer timeout (or Never) than you allow. If not configured, the user's own setting in the app governs. Your Bolt deployment does not serve this setting. Every provider's reveal action requires the vault to be unlocked, so this timeout is the whole enforcement surface for an unattended, signed-in machine. Pair with "Require a PIN to unlock the vault" for defense in depth. 1 minute 5 minutes 15 minutes 30 minutes Never Vault master password session length How long a master password unlock lasts before Bolt asks for the master password again. Within the session a PIN re-unlocks after an idle lock; after it, only the master password does. 4 hours 12 hours 24 hours Until Bolt restarts Has no effect unless the user has a master password (see "Require a master password for the Bolt vault"). If not configured, the user's own setting in the app governs. 4 hours 12 hours 24 hours Until Bolt restarts Pending vault actions lifetime How long Bolt keeps a login, password change, passkey or authenticator code that the browser extension handed it and the user has not saved or dismissed yet. While it waits, the secret is sealed under the user's vault key on this device only, never synced, and deleted when the user saves or dismisses it or when this time passes. 1 hour 4 hours 24 hours Memory only (never written to disk; lost when Bolt quits or the vault locks) If not configured, Bolt keeps pending actions for 1 hour. 1 hour 4 hours 24 hours Memory only Allow Bolt to update itself Controls whether Bolt checks for, downloads and installs its own updates. Disabled does not merely hide the update button. Bolt does not load its updater at all, so the app never contacts the Sparcle release manifest, never downloads a build and never installs one. There is no request to block at your egress and no scheduled check running in the background. Enabled, or Not Configured, leaves updating exactly as it ships. A VALUE BOLT CANNOT READ MEANS OFF. If this key is written with the wrong registry type - a REG_SZ "false" instead of a REG_DWORD, say - Bolt treats it as Disabled and logs why, rather than resolving it to "updates allowed". An administrator who wrote this key asked to govern updates, so a mistake must not silently hand the capability back. Not Configured is the only setting that leaves updates alone. This policy is the sole authority. Bolt's in-app update preference, and an air-gapped build's own compiled-in switch, can only make the app update less; neither can re-enable updating on a machine where this is Disabled. Your Bolt deployment does not serve this setting. It is governed on the device or not at all, deliberately: a setting fetched from a server cannot be allowed to turn a managed fleet's updates back on. Consider the trade-off before disabling fleet-wide. A fleet that does not update also does not receive security fixes. The usual reason to set this is that you distribute Bolt yourself through your own software-deployment tooling. Pin Bolt to a specific version Holds this machine at one version of Bolt, for example while you validate a release. Enter an exact version number, such as 0.1.159. THIS IS AN EXACT VERSION, NOT A MAXIMUM. Bolt will move to the version you name and to no other - not to a later one, and not to an earlier one. A machine already running the pinned version stays where it is; a machine behind it is brought up to it at its next check. Bolt still accepts a re-published build of the pinned version itself (same version number, corrected package), because that does not move the machine off the pin. A version number Bolt cannot parse - "latest", "v0.1.159", "0.1" - is treated as "updates off", not as "no pin". A pin that cannot be read must not resolve to an unrestricted update. If "Allow Bolt to update itself" is Disabled, that wins and this setting has no effect. Your Bolt deployment does not serve this setting. Not Configured means no pin. Enforcement level: One hostname per line, no scheme or path: One application identifier per line: One hostname per line, no scheme or path: One domain per line. An empty box closes every exemption: One hostname per line. An empty box closes every exemption: One hostname per line. An empty box closes every exemption: Filter mode: Governance mode: Deployment URL: Launch mode: Guard scope: Auto-lock after: Ask again after: Keep pending actions for: Pin to version: