← All docs

Introduction

What agentjail is, the problem it solves, and how policy enforcement sits between your coding agent and the tools it calls.

A coding agent's tool call passes through agentjail, which evaluates it against local policy and either lets it run or blocks it.
Every tool call is checked against local policy before it runs: allowed calls pass through, dangerous ones are blocked at the boundary.

agentjail is a policy guardrail for coding agents. It sits at the boundary between your agent and the tools it can call (the shell, the filesystem, the network) and blocks dangerous tool calls before they execute.

Why it exists

Coding agents are useful precisely because they take actions on your behalf. That same capability is the risk: a well-meaning but vague instruction can lead an agent to delete the wrong directory, leak a secret, or push to the wrong remote.

Most safety today is either a coarse sandbox (all-or-nothing, awkward to live in) or a permission prompt on every action (fine until there are dozens per task and fatigue sets in). agentjail takes a third path: it doesn’t try to make the agent smarter, and it doesn’t ask you to approve everything. It enforces policy at the boundary, regardless of the agent’s intent.

How it works

Every time your agent is about to use a tool, agentjail intercepts the call, evaluates it against your policy, and returns a verdict. Allowed calls run as normal; denied calls never reach the shell. The agent gets a structured block response and explains itself instead of proceeding.

  your agent ──tool call──▶  agentjail  ──allow──▶  shell / files / network
 (Claude Code)              (policy gate,  └─deny──▶  blocked
                             offline)                (e.g. rm -rf ~/.ssh)

Three properties make this practical:

  • It runs at the tool boundary: on the PreToolUse hook, before the command is ever handed to the shell.
  • It’s offline: rules are evaluated locally, with no network round-trip and no model in the decision loop. Fast and deterministic.
  • It’s auditable: every rule is plain text you can read, diff, and version alongside your project.

What it can guard

A policy can inspect any tool call your agent makes, so you can write rules over:

  • Shell commands: block destructive or sensitive operations.
  • Filesystem paths: keep the agent out of ~/.ssh, .env, credentials, or anything outside the working tree.
  • Network access: stop exfiltration to unexpected hosts.
  • Git actions: prevent pushes to protected remotes or force-pushes.

What a rule looks like

Policies are written in Rego. A rule is just a condition over the structured tool call: when it matches, the call is denied with a message:

deny[msg] {
  input.tool_name == "Bash"
  contains(input.tool_input.command, "/.ssh/")
  msg := "Blocked: command targets sensitive path ~/.ssh/"
}

One rule. Offline. No round-trips. The policy model page covers how rules are matched and evaluated.

Where it fits

agentjail is most useful anywhere an agent can touch something you care about:

  • Local development: a safety net while you let an agent work in your repo.
  • “Skip the prompts” workflows: when you run an agent with permission prompts disabled, agentjail is the boundary that still holds.

agentjail currently supports Claude Code on macOS. Codex, Cursor, CI, and other integrations are not yet available.

Next steps