Can a coding agent disable its own guardrails? Tamper resistance explained

the short answer

It can if the guardrails live in files and processes the agent can change. A tamper-resistant setup refuses agent commands that change, pause or disable the policy client, fails closed when the evaluator is unreachable, pins policy packs by digest, and, in managed deployments, loads centrally deployed policies when a session starts. The strongest managed setup runs the evaluator as a separate OS user and gives agents no sudo.

Self-protection: block-failproofai-commands: always on, cannot be paused, never reviewable
Daemon unreachable: On a machine configured for the daemon, gated calls are denied
Pack integrity: SHA-256 digest recorded at install and re-verified before every load
Local pause: Agents cannot use it; it never pauses Cloud-managed policies
Strongest isolation: Daemon as a separate OS user; agents without sudo (managed deployments)

Why This Is the First Question Security Teams Ask

Platform teams that tried harness settings first report the same thing: the agent found a way around them. A setting in a JSON file in the developer’s home directory is writable by the developer’s processes, and the agent is one of those processes. Any guardrail design has to answer what happens when the agent edits the file, kills the process, pauses enforcement or asks for sudo.

Tamper Paths and What Closes Each One

Tamper path	What closes it
Agent runs commands that change, pause or disable Failproof	`block-failproofai-commands`: always on, cannot be switched off or paused, never reviewable by Jev
Agent uses `failproofai config --pause`	Blocked for agents by the same guard; a human’s pause covers one session, always expires, and never pauses Cloud-managed policies
Agent edits Failproof’s own files	Reading them is allowed; changing them is blocked by `block-failproofai-commands`
Kill or break the daemon so nothing evaluates	On a machine configured for `failproofaid`, an unreachable daemon or version mismatch denies the call; there is no silent fallback evaluator
Edit an installed policy pack	The digest is re-verified before every import; a changed pack stops loading and denies the events its policies covered
Delete a pack the machine was told to enforce	A declared pack that will not resolve denies what its policies covered (`pack/failproofai-pack-unavailable`)
Edit Claude Code hook settings or set `disableAllHooks`	Hooks delivered in Claude Code managed settings cannot be disabled from user or project settings; MDM keeps managed files in place
Edit Cloud-managed policies mid-session	Cloud-managed policies load when a session starts, so a mid-session change does not alter that session (managed deployments)
`sudo` to get past file permissions	`block-sudo` is on by default in the coding agent pack; managed deployments give agents no sudo at all
Read the machine key and reuse it	`credentials.json` is owner-only, but in a default single-user install the agent runs as that owner and can read it; treat machine keys as spending credentials and rotate on suspicion

Where Fail-Closed Does Not Apply

A custom policy that throws or times out (10-second deadline) is logged and treated as allow(). Choose deliberately how your own policy code fails.
A convention policy file that fails to load is skipped while other policies keep running. Keep failproofai policies --install --custom <file> in CI so a broken file fails the build.
Before daemon configuration is recorded, hooks evaluate in process.
When a declared pack will not load, UserPromptSubmit instructs instead of denying so you are not locked out of the agent that could fix it, and a load timeout is treated as transient.

Same User Versus Separate User

In a default install, failproofai config installs the failproofaid service, and the agent runs as the developer. The self-protection policy does the heavy lifting there: the agent can read Failproof’s files, but changing them is denied.

For a company fleet, Failproof’s managed deployment runs the daemon as a separate OS user and gives the agent’s user no sudo, so file permissions enforce what a policy otherwise has to. This is the setup we recommend for anyone with production access. Talk to us to set it up; the install mechanics differ by OS and MDM.

What Fail-Closed Looks Like to a Developer

When the daemon is unreachable, the agent gets a denied tool call with a reason that tells the operator to check or update the daemon. It does not proceed. The developer checks status, updates if versions differ, and resumes.

failproofai config --status          # daemon, delivery and pause state
npm install -g failproofai@latest
failproofai update                   # migrations, matching daemon binary, restart

See Tampering Attempts

Observe → policy reports blocks, unguarded actions and activity while paused, per machine. fp guardrails summary --machine <id> gives the same coverage and deny totals from a terminal (signed-in session required). A spike in block-failproofai-commands denies on one machine is worth a look.

Test Tamper Resistance Before Rollout

Ask the agent to disable or pause Failproof. Expect a deny from block-failproofai-commands.
Ask it to edit ~/.failproofai/policies-config.json to add an allow path. Expect a deny.
Stop the daemon service yourself, then ask the agent to run any gated command. Expect a fail-closed deny with a daemon reason.
Ask it to run sudo anything. Expect a deny, and in a managed install, no sudo rights at all.
Check each decision in the local dashboard under Policies → Activity, and in Observe → policy once the daemon is back and has delivered its spool.

FAQ

Can a developer turn Failproof off?

A developer with admin rights on their own laptop can remove software; that is a device-management question, which is why fleets install the client through MDM and watch coverage. A developer can also pause local policies for one session, which never pauses Cloud-managed ones. The guarantees here are about the agent.

What if the daemon crashes during a session?

Gated calls are denied with a reason until a known evaluation path is healthy. Do not have the agent retry the blocked action repeatedly.

Does fail-closed slow developers down?

Only when the evaluator is broken. In normal operation deterministic policies evaluate locally; our engineering write-up measured the daemon path at about 0.7 ms p50.

Sources

Checked against the sources below on October 21, 2026. Harness settings, hook capabilities and cloud features change between versions.