Intercept rules

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 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

{
  "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.