The short version.

A tier 1 App is text and links. A tier 2 App works inside Bolt on what you paste or type, or (admins only) changes masking. A tier 3 App runs a program, reads another program on your computer, or calls a service as you, with your rights. Bolt does not give an App more power than you have, and it does not yet take any away from a tier 3 App. Add tier 3 Apps only from people you trust.

What Bolt enforces today.

Rule	How
A `bridge` User App runs one program, never a shell	Shell operators are refused when the file loads. Each value is passed as one argument.
A `bridge` App waits for Enter	It cannot run as you type, and the file cannot change that.
A User App file cannot hold a secret	`env` values must read an environment variable.
An `http_local` App cannot leave your computer	The host must be `127.0.0.1`, `::1` or `localhost`.
A model cannot start a User App	User Apps are not AI tools, and their rows are not sent to a model on their own.
A changed or unsigned Boltpack is refused	Bolt checks the signature and every file's hash, then checks again in the desktop app before writing anything.
A pack from an unknown signer needs a second yes	Bolt asks in its own window. No answer installs nothing.
An imported agent is always yours alone	It cannot make itself visible to your whole organization. Exported agents carry no API keys or sign-ins.
A tool skill calls only approved hosts	Your administrator lists the hosts. With none listed, every call is refused.
Masking rules change only through an admin	Detectors and compliance packs come from admin settings or a bundle signed by a key built into Bolt.

What Bolt does not do yet.

Not yet	Today
Confining a script to what it declares	The review card shows a script's declared hosts, files and programs, but the script can do anything you can. Treat it like a script you run yourself.
Plain-word install review	The card lists each file's kind and declared reach in technical terms.
What changed in an update	A newer pack with the same App replaces the file without a list of changes.
One switch per App, last-used date	There is one switch for all User Apps.
Company signing keys and revocation	Only Sparcle's key is built in, and a pack cannot yet be withdrawn from devices that installed it.

Coming in the next release.

Change	What it does
Company control of User Apps	A device-policy key, `userAppsEnabled`, lets your company turn User Apps off. The person on the device cannot switch them back on. Left unset, nothing changes.
The shell-commands device switch covers User Apps	With `shellExecEnabled` set to false, User Apps and Boltpack scripts can no longer start programs either.
Removing an App removes what its pack added	Removing a pack's last App also removes the scripts that pack installed. A pack installed before this release may leave a script behind; Bolt names it in its log.
A mixed pack says what it skipped	Dropping a Boltpack on the launcher lists anything it did not install, and why.
Who signed it, in plain words	The install card reads Signed by Sparcle or Signed by its author.

What a company controls today.

Control	Where
Adding your own skills, agents and MCP servers	Organization policy, per kind.
Hosts a tool skill may call	Server setting; empty refuses all.
Which connectors and compliance packs are on	Settings → Admin.
Shell commands, the remote tunnel and local MCP programs on managed devices	Device policy from your device management. From the next release it also covers User Apps and Boltpack scripts.

Found a problem?

Report a security issue in Bolt or in a Bolt App privately to [email protected], not in a public issue. Scope and response times are in our vulnerability disclosure policy.

Security model.