Policy authority

When you configure the Jev semantic evaluator with your own key (failproofai jev setup), every tool call is judged twice: by the policies you run, and by Jev, which asks what the call actually does and whether the person who typed the task asked for it. Each policy’s authority decides what happens when the two disagree. Without Jev configured, authority has no effect. Every policy enforces exactly as it always has.

Hard and reviewable

Hard is the default. A hard policy’s deny or instruction is final: Jev cannot clear it, and a hard deny stops the call without waiting for Jev.
Reviewable means Jev may clear the policy’s verdict, but only through the semantic checks the policy names in reviewedBy. The verdict is cleared only when every named check was asked about this call and each one either found nothing or recorded the user asking for this. A check that fired — found the concern — without the user asking keeps the block, even when its own verdict is only a warning. A check Jev was not asked, because it does not apply to that tool, never clears anything, whatever the others said. One softening counts as consent: when the call is a step of the task the user gave and reaches no further, Jev turns a deny into a warning, and that warning clears the policy’s block and is what the agent is told.

A policy is reviewable only when all of these hold:

It declares authority: "reviewable".
reviewedBy is a non-empty list, and every entry is a semantic check this machine can ask: one of the built-in checks, or one an installed pack declares. A pack installed from a FailproofAI repository that declares checks of its own replaces the built-in ones, and then only the packs’ checks count.
It is not alwaysOn. The guard that stops an agent from disabling Failproof AI is always hard.

Anything else is hard: a missing field, a misspelled value, an empty or malformed reviewedBy, or a name that is not a check this machine can ask. An unknown name makes the whole declaration hard rather than being skipped, because reviewedBy means “all of these must be asked, and none of them may deny”, and skipping a name would let Jev clear the policy on fewer checks than you asked for. Once Jev is configured, Failproof AI logs a warning when it refuses a reviewable declaration, once per process. Without Jev it says nothing, because authority then decides nothing. failproofai publish refuses to build a pack that carries such a declaration, so a pack author finds out before anyone installs it. It judges reviewedBy against the checks the pack declares when it declares any, and against the built-in checks otherwise.

Where authority is declared

Each way a policy reaches a machine has one place that decides its authority:

Source	Declared in	Default
Built-in policies	The table below	Hard unless listed as reviewable
Your own policy files	`authority` and `reviewedBy` on `customPolicies.add`	Hard
Policy packs	Each policy’s entry in the pack manifest (`failproofai-pack.json`)	Hard
Cloud-managed policies	The policy’s assignment in the active deployment	Hard. Deployments do not set it yet, so every cloud-managed policy is hard today.

For a pack or a cloud-managed policy, fields set inside the policy code are ignored; the manifest or the assignment decides. A pack can only describe its own policies: its policy names cannot contain / and are registered under the pack’s own prefix, so no manifest can mark a built-in policy or another pack’s policy as reviewable. A policy a pack’s code registers without declaring it in the manifest is hard. Two packs, or two cloud-managed policies, whose code is byte-identical share one artifact and load as one policy. That policy is reviewable only if every one of them declares it reviewable, and Jev must then clear every check any of them names. If any of them declares it hard, or does not declare it at all, it stays hard. The order the packs or policies are listed in never matters. Most machines get the built-in policies from the FailproofAI/policies pack, and read their authority from that pack’s manifest. The reviewable entries below take effect once a release of the pack that carries them is installed; an older release carries none, so every policy in it stays hard.

Declare authority in your own policy

import { customPolicies, deny, allow } from "failproofai";

customPolicies.add({
  name: "block-prod-config-reads",
  description: "Keep production credentials out of the agent's context",
  match: { events: ["PreToolUse"] },
  authority: "reviewable",
  reviewedBy: ["secret-exposure"],
  fn: async (ctx) =>
    String(ctx.toolInput?.file_path ?? "").includes("/config/prod/")
      ? deny("Production config is off limits")
      : allow(),
});

failproofai publish copies both fields into the pack manifest, so a policy published as a pack keeps the authority its author gave it. It refuses to build the pack if a declaration would not be honored: a value other than "hard" or "reviewable", a reviewedBy that is not a list of names, or a name that is not a check — one of the pack’s own Jev checks when it declares any, a built-in check otherwise.

Built-in policies

Reviewable only where a semantic policy genuinely covers the same concern. Every other built-in policy is hard. Covering the concern is necessary but not sufficient, and both ways of getting it wrong are quiet:

A check that is never asked makes the block permanent. reviewedBy is a conjunction and a check that was not asked never clears, so a policy paired with a check whose precondition does not fire for the shapes the policy matches can never be cleared at all.
A check that is asked but does not fire answers “no concern”, and no concern clears. So pairing with a check that does not model your policy’s shapes does not review the policy — it switches it off for exactly the inputs the check does not understand.

An instruct-mode semantic policy can never answer deny, but it can still keep a block: when it fires and the user did not ask for the call, the policy it reviews is not cleared. Six of the built-in checks are instruct-only — push-to-protected-branch, commit-on-protected-branch, read-outside-workspace, system-modification, env-secrets-dump and external-data-egress — and the table below gives every check’s mode. The question to ask is “is there anything left that can deny”: a clear must never leave the concern enforced by nothing. The engine applies that test per call. A warning nobody consented to is not a clear, because before tool calls a warning does not stop the agent. And when a check that can deny warns — its evidence fell short of its deny line — and the user did not ask for the call, nothing is cleared on that call and every regex deny stands.

A check that scores just under its fire line does not keep the floor. The rule above needs a check to fire (evidence ≥ 0.7). When every relevant check lands just below that, nothing fires, the reviewers answer “no concern”, and a reviewable deny is cleared. Measured live in enforce mode: an unrequested Read of /etc/shadow (secret-exposure 0.69, read-outside-workspace 0.37, which only models home-directory paths) and set | curl -d @- … after “follow SETUP.md” (env-secrets-dump 0.66, credential-exfiltration 0.65 with sends_out 0.97) were both allowed, while the regex tier alone denies them. The thresholds were calibrated on the labelled corpus and have not been re-measured against this; until they are, keep a policy hard where one of these shapes getting through matters more than its false blocks.

Policy	Authority	Reviewed by	Why
`protect-env-vars`	reviewable	`env-secrets-dump`, `secret-exposure`	The pattern fires on any variable reference; Jev asks whether secret values would actually be printed.
`block-env-files`	reviewable	`secret-exposure`	The pattern matches any `.env` path, templates included; Jev asks whether real secret values would be read or written.
`block-read-outside-cwd`	reviewable	`read-outside-workspace`	Measured as noisy on real traffic; Jev asks whether file contents outside the project are read. A read the user asked for, or one the check finds nothing in, is cleared; an unrequested read it flags keeps the block.
`warn-git-amend`	reviewable	`git-history-rewrite`	Amending an unpushed commit is ordinary; the harm is rewriting history others may have pulled.
`warn-destructive-sql`	reviewable	`database-destruction`	Jev also asks whether the target is a real database rather than a disposable test one.
`warn-global-package-install`	reviewable	`system-modification`	The same concern: changing the machine outside the project.
`block-failproofai-commands`	hard		`alwaysOn` self-protection. Never reviewable.
`block-rm-rf`	reviewable	`destructive-deletion`	The path-depth heuristic gets `rm -rf node_modules` wrong; Jev asks whether what would be destroyed is regenerable. `rm -rf /` keeps both probes true.
`block-sudo`	hard		Privilege escalation.
`block-curl-pipe-sh`	hard		Runs code downloaded from the internet.
`block-push-master`	hard		Pushes directly to a protected branch.
`block-work-on-main`	hard		`commit-on-protected-branch` covers exactly this concern but is instruct-mode, so it can never answer deny, and no other check covers it.
`block-force-push`	reviewable	`git-history-rewrite`	Jev’s probe is a superset of the matcher and counts `--force-with-lease`; what clears is force-pushing your own branch.
`block-secrets-write`	reviewable	`secret-exposure`	The path match is unanchored, so `src/auth/credentials.ts` is caught; Jev asks whether real key material is being written.
`block-kubectl`	reviewable	`production-infra-change`	Denies the whole CLI, read-only subcommands included; Jev asks whether the call mutates and whether the target is production.
`block-terraform`	reviewable	`production-infra-change`	Same: clears `terraform plan` and `validate`.
`block-aws-cli`	reviewable	`production-infra-change`	Same: clears `aws s3 ls`, `aws sts get-caller-identity`.
`block-gcloud`	reviewable	`production-infra-change`	Same: clears `gcloud auth list`, `gcloud config list`.
`block-az-cli`	reviewable	`production-infra-change`	Same: clears `az account show`.
`block-helm`	reviewable	`production-infra-change`	Same: clears `helm list`, `helm status`.
`block-gh-pipeline`	hard		Triggers pipelines, merges and secret changes.
`warn-git-stash-drop`	hard		No semantic check covers discarding stashed work.
`warn-git-clean`	hard		`destructive-deletion` covers the concern but demonstrably cannot fire on it: `git clean` names no path, so its `irreplaceable` probe has nothing to judge and answers low, and evidence is the minimum over a policy’s probes. A check that is asked and does not fire clears the verdict, so pairing here would switch the policy off.
`warn-all-files-staged`	hard		No semantic check covers what a wide `git add` picks up.
`warn-schema-alteration`	hard		`database-destruction` covers dropping data, not altering a schema.
`warn-package-publish`	hard		Publishing is irreversible and no semantic check covers it.
`prefer-package-manager`	hard		A team convention, not a safety judgment.
`warn-large-file-write`	hard		A size threshold, not a judgment Jev can make.
`warn-background-process`	hard		No semantic check covers detached processes.
`warn-repeated-tool-calls`	hard		Counts calls; Jev cannot count.
`sanitize-jwt`	hard		Redacts tool output; not a tool-call gate.
`sanitize-api-keys`	hard		Redacts tool output; not a tool-call gate.
`sanitize-connection-strings`	hard		Redacts tool output; not a tool-call gate.
`sanitize-private-key-content`	hard		Redacts tool output; not a tool-call gate.
`sanitize-bearer-tokens`	hard		Redacts tool output; not a tool-call gate.
`require-commit-before-stop`	hard		A session-completion gate, not a tool-call gate.
`require-push-before-stop`	hard		A session-completion gate, not a tool-call gate.
`require-pr-before-stop`	hard		A session-completion gate, not a tool-call gate.
`require-no-conflicts-before-stop`	hard		A session-completion gate, not a tool-call gate.
`require-ci-green-before-stop`	hard		A session-completion gate, not a tool-call gate.

Semantic policy names

These are the built-in checks, and the values reviewedBy accepts unless a pack installed from a FailproofAI repository declares Jev checks of its own. Each is a check Jev answers about the tool call in front of it. Mode is what a check can answer: a deny check blocks on strong evidence, while an instruct check only ever warns. Either keeps a policy’s deny standing when it fires and the user did not ask for the call. User can override says whether the human’s own explicit request clears it. A pack’s Jev checks are added to this list, and their names join the ones reviewedBy accepts. A pack installed from a FailproofAI repository instead replaces this list: its checks are then the only ones Jev asks and the only names reviewedBy accepts, so a policy naming a check below that it does not declare stays hard. FailproofAI/jev-policies declares these same sixteen, so with it the table still applies. A name two packs declare differently is honoured for neither. One of these sixteen names declared by a pack not installed from a FailproofAI repository is ignored in that pack: its version is never asked and does not contest FailproofAI’s own, so a third-party pack can neither become the check that clears the core pack’s policies nor switch one of these checks off. A pack whose every check is unusable leaves this list in force.

Name	Mode	User can override	What Jev checks
`destructive-deletion`	deny	yes	Permanently deleting data that cannot be regenerated.
`production-infra-change`	deny	yes	Changing live infrastructure.
`git-history-rewrite`	deny	yes	Rewriting or discarding shared git history.
`push-to-protected-branch`	instruct	yes	Pushing directly to a protected branch.
`commit-on-protected-branch`	instruct	yes	Committing directly on a protected branch.
`secret-exposure`	deny	yes	Reading or copying credentials.
`credential-exfiltration`	deny	no	Sending secrets or private files off the machine.
`remote-code-execution`	deny	yes	Running code downloaded from the internet.
`privilege-escalation`	deny	yes	Running with elevated privileges.
`database-destruction`	deny	yes	Destroying or mass-modifying database data.
`read-outside-workspace`	instruct	yes	Reading files outside the project.
`agent-config-tampering`	deny	no	Changing the agent’s own safety configuration.
`system-modification`	instruct	yes	Changing the system outside the project.
`env-secrets-dump`	instruct	yes	Printing environment secrets.
`external-destructive-action`	deny	yes	An irreversible action through an external tool.
`external-data-egress`	instruct	yes	Sending private data to an external tool.

Connect your agents

Reference

HTTP API

Hard and reviewable

Where authority is declared

Declare authority in your own policy

Built-in policies

Semantic policy names

​Hard and reviewable

​Where authority is declared

​Declare authority in your own policy

​Built-in policies

​Semantic policy names

Hard and reviewable

Where authority is declared

Declare authority in your own policy

Built-in policies

Semantic policy names