> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Blacklists in Practice

> The programmatic kill-switch — always on, no matter what

The [Blacklist](/0.8/configure/blacklist) is the one safety layer that **does not depend on an LLM judgment**. Every command an agent tries to run goes through it first. If the command matches a pattern, it's blocked.

## Always on

Blacklists are checked regardless of:

* The host the agent is on
* The specialty attached to the agent
* The operational rules in context
* Whether the task is `@2501:investigate` or remediate
* Whether the agent is mid-task or starting

If the agent retries a blocked command **3 times**, the task is terminated.

## What to blacklist by default

Even in non-production environments, block the most destructive primitives:

| Pattern                        | Why                                                            |
| ------------------------------ | -------------------------------------------------------------- |
| `rm -rf /`                     | Catastrophic by definition                                     |
| `rm -rf *`                     | Scope depends on CWD — agents don't always know where they are |
| `shutdown`, `halt`, `poweroff` | Removes the host from the agent's reach                        |
| `mkfs.*`, `dd if=*`            | Destroys storage                                               |
| `vgremove`, `lvremove`         | Destroys logical volumes                                       |
| `aws ec2 terminate-instances`  | Destroys cloud infrastructure                                  |
| `kubectl delete namespace`     | Wipes whole environments                                       |

Glob wildcards (`*`, `?`) are supported and patterns match anywhere in the command (substring match by default).

## Block interactive tools

Agents operate on a prompt, not an interactive shell. Anything that opens a TUI, asks for a password, or expects keystrokes during execution will hang the agent.

| Pattern                      | Why                                                      |
| ---------------------------- | -------------------------------------------------------- |
| `vim`, `nano`, `vi`, `emacs` | TUI editors — agents can't navigate them                 |
| `mysql`, `psql`, `redis-cli` | Interactive REPLs — use `-e "<query>"` or `--batch`      |
| `python` (alone)             | REPL — agents should run scripts with `python script.py` |
| `docker exec` (without `-T`) | Allocates a TTY                                          |
| `logs -f`, `tail -f`         | Streams indefinitely — use bounded reads instead         |
| `ssh` (without command)      | Sub-shell                                                |

## Block calls into known-broken paths

If an agent has repeatedly failed with a tool that has a known-bad UX (a CLI with confusing flags, an internal tool that errors silently), blacklist the bad invocation pattern and steer the agent elsewhere via a specialty or operational rule.

## What blacklists are NOT

* **Not behavioral guidance.** Use [operational rules](/0.8/configure/operational-rules) to *guide* behavior; use blacklists to **stop** specific commands.
* **Not a substitute for permissions.** If the credential can run a destructive command, the blacklist is your last line — but [scoping permissions](/0.8/risk/permissions) is the better first line.
* **Not for nuanced cases.** A pattern either matches or it doesn't. If you need "block this in prod but allow in staging," that's an operational rule, not a blacklist entry.