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 agent is in Plan or Auto
- Whether the agent is mid-task or starting
What to blacklist by default
Even in non-production environments, block the most destructive primitives:
Glob wildcards (
*, ?) are supported and patterns match anywhere in the command (substring match by default).
When the check cannot run
A command is blocked when its blacklist cannot load. An invalid stored regular expression also blocks commands and asks the operator to repair the configuration. A successful check is required before the command can run.Restrict interactive tools where needed
Agents can answer supported terminal prompts, but full-screen interfaces and arbitrary interactive programs have limits. Restrict programs that your environment cannot safely support. The blacklist checks the command that opens a terminal, not input sent into an open session. Blacklist patterns are not a substitute for host permissions.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 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 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.