# Introduction

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

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.

```text
  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](https://www.openpolicyagent.org/docs/latest/policy-language/).
A rule is just a condition over the structured tool call: when it matches, the
call is denied with a message:

```rego
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](/docs/concepts/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

- **[Quickstart](/docs/quickstart):** zero to a blocked tool call in about two minutes.
- **[Installation](/docs/installation):** get agentjail running locally.
- **[The policy model](/docs/concepts/policy-model):** how rules are written and evaluated.