---
title: "Intercept rules"
description: "A hard gate in front of specific command patterns. A match rejects the call outright."
---

Permissions decide per tool category. Intercept rules are a harder gate that watches specific commands.

## What to intercept

- Destructive commands (delete, `git push`, publish operations)
- Permission changes (`chmod`, `chown`, `icacls`)
- Using `exec` for jobs that belong to a dedicated tool (`cat` to read, `echo >` to write, `grep` to search)
- Tool names that were never registered

Those last two ship as built-in defaults and are active out of the box. You can add or remove rules of your own.

## What happens on a match

**By default an intercept match rejects that call outright — it does not raise a confirmation prompt.** The violation comes back to the agent as a tool result prefixed with `[INTERCEPTED]`, so the agent can see why it failed and try something else.

Since v0.1.0, a rule can add `"action": "confirm"` to route a match through **permission approval**: a prompt appears, a human allows or denies it, and the call runs only if approved. The default action is `block` (reject outright); only an explicit `confirm` raises the prompt.

[tool permissions](/en/docs/configuration/permissions) also raises prompts. The two layers are cumulative — an operation only proceeds when both allow it.

## Configuring rules

Rules live in `.bi/intercept_rules.json`, and you can also read and write them through `GET/POST /api/rules`. Each rule carries:

- `name` — the rule name. The built-in defaults are `read`, `write`, `list`, `search` and `date`
- `pattern` — a regular expression matched against the command
- `message` — the explanation handed back to the agent on a match
- `action` — what happens on a match: `block` (default) rejects outright, `confirm` raises a prompt

```json
{
  "enabled": true,
  "exec_rules": [
    {
      "name": "no-push",
      "pattern": "(?i)\\bgit\\s+push\\b",
      "message": "Confirm which branch you are pushing before pushing to the remote.",
      "action": "confirm"
    }
  ]
}
```

A `block` match is recorded in the violation list; a `confirm` match goes through approval instead and is not a violation. The list is readable via `GET /api/rules`.

## A common misunderstanding

Intercept rules **cannot** restrict "access outside the workspace". Rules only match command text; there is no path-pattern match type.

Workspace confinement is a separate mechanism: every file tool resolves its paths against the workspace root and rejects anything that escapes, with no way to relax it by configuration. The two defences are independent.