Most coding agents ask for your approval before running a tool call. That is a reasonable default, but it breaks down at scale: once an agent is making dozens of calls per task, the prompts pile up, and approving them becomes mechanical. Fatigue sets in, and the safety guarantee collapses.
The tempting solution is to disable prompts entirely and trust the agent to stay within reasonable bounds. The problem is that “trust the agent” is not a policy. It is an assumption.
agentjail lets you skip the prompts without dropping the guardrail.
How it works
agentjail sits at the PreToolUse boundary. Before each tool call runs,
agentjail-hook evaluates the call against your policy and either allows or
denies it — regardless of whether the agent’s own permission prompts are
enabled or disabled.
A call that matches a deny rule is blocked before it reaches the shell, the
filesystem, or the network. The agent gets a structured block message and stops.
Nothing executes.
The result is that you can let an agent run at full speed without watching every call, and still have a deterministic, auditable boundary around what it is allowed to do.
For a deeper look at how evaluation works, see How it works.
What to set up before you skip prompts
agentjail must be in place before you reduce human oversight. Make sure:
- agentjail is installed and
agentjail statusshows the daemon running. agentjail policy listshows the rulesets you expect to be active.- You have tested your policy using
agentjail-hookdirectly against the kinds of calls your agent will make (see the generic hook guide for the test pattern). Skipping prompts means you are relying on the policy to catch what you would have caught manually.
Agent-specific instructions for disabling the agent’s own permission prompts
vary by tool and are outside the scope of this guide. Check your agent’s
documentation for its --dangerously-skip-permissions or equivalent flag.
agentjail’s hook remains active regardless of that setting.
The key property: offline, deterministic enforcement
When a human approves every tool call, safety depends on the human being present, attentive, and consistent. That is hard to scale.
agentjail’s policy evaluation is offline (no network round-trip, no model in the loop) and deterministic (the same input always produces the same verdict). The boundary holds whether the agent runs interactively, as a background job, or unattended. It does not get tired and it does not get distracted.
That is the tradeoff: you write a policy once, and it enforces consistently from that point forward.
Writing a policy you trust at full speed
A policy that is right for a cautious, prompt-heavy workflow may not be strict enough for fully automated operation. When you remove prompts, consider whether your rules cover:
- Sensitive filesystem paths (credentials, SSH keys, environment files).
- Destructive shell commands (
rm -rf,truncate,dd). - Network exfiltration (unexpected outbound hosts).
- Git operations (force pushes, pushes to protected remotes).
The default file_policy ruleset covers sensitive paths. For the rest, see
Policy recipes for patterns you can adapt.
See also
- How it works: the tool-call boundary and how offline evaluation works.
- Run in CI: the companion guide for unattended agent runs in CI pipelines.
- Writing your first rule: add rules tailored to your specific workflow before skipping prompts.