- Failproof AI policy packs — ready-made packs for predefined use cases: plug one in and it works. The coding agent policy pack is available now, and packs for more use cases are coming soon.
- Community policy packs — policies developers have written for their own use cases and published for anyone to take.
Failproof AI policy packs
Coding agent policy pack
policies add switches them on:
Switch on any that are off by name —
failproofai policies add block-rm-rf — or take the whole pack with --all. See every policy in it, grouped by category:
Community policy packs
Developers publish packs for the use cases they have met, and the policy hub lists them. A community pack is published by its author, not audited by Failproof AI, so read what it carries before installing it:SHA256SUMS, so what you read is what would install.
Then install it:
Naming no tag installs the newest release and pins it, then tells you which tag it chose. What gets recorded always names exactly one release, so a reinstall cannot drift.
Take part of a pack
By default you get the pack’s own defaults — the policies its author marked safe to switch on unattended — not everything it contains.--category and --policy combine as a union (--only is accepted as a synonym for --policy), and each may be repeated: --policy a --policy b takes both. When the pack is already installed, the flags add to what you had, and re-adding it with no flag and no terminal — to upgrade, say — keeps your selection as it is. At a terminal with no flag, add opens the picker instead, pre-ticked with the author’s defaults, and what you tick replaces your selection.
Manage what is on
--scope says.
A name with no slash is a policy; anything with one is a pack source. A bare name resolves to the installed pack that declares it. When two installed packs declare the same name, name the one you mean:
What integrity does and does not buy
SHA256SUMS ships in the same release as the artifact, so it is not a signature and proves nothing about who published it. What it does prove is that the bytes are the ones that release published — and because the digest is recorded when you add the pack and re-verified before every import, a pack cannot change under your machine afterwards. A repository that retags or replaces an asset stops loading instead of quietly running something else.
At install time the pack is also imported once and checked against its own manifest. A pack whose artifact does not parse, or that registers something other than what it declares, is refused before anything is activated — rather than installing cleanly and failing on your next tool call. So is a pack whose id claims the FailproofAI/ namespace but whose release is not in a FailproofAI repository.
When a pack will not load
A pack this machine was told to enforce and cannot run denies the events its missing policies covered, rather than allowing them silently — aspack/failproofai-pack-unavailable, which outranks the policies that did load so the deny is attributed to the missing pack rather than to whichever guard happened to fire first. The exception is UserPromptSubmit, which instructs instead: denying there would lock you out of the agent you need in order to fix it. See Failure behavior.
A pack can name the oldest failproofai it works with (minCliVersion, set by its publisher). An older CLI refuses to add it and prints the upgrade command, npm i -g "failproofai@>=<minCliVersion>" && failproofai update (a range, so npm picks a release that meets it — a bare failproofai installs latest, which can be older than a prerelease minimum); one already installed that the running CLI is too old for does not load, with the result above. A minCliVersion the CLI cannot read is ignored with a warning rather than refusing the pack.
Offline and mirrors
To share your own policies this way, see Publish a policy pack.