> ## 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. # Blacklist > Prevent agents from executing specific commands The Blacklist feature blocks agents from executing certain commands during task execution. This is useful for preventing problematic operations like calling unstable endpoints, using uninstalled tools, or running destructive commands. When an agent tries to execute a blacklisted command, 2501 checks it against your defined patterns and rejects it if there's a match, prompting the agent to find another approach. ## HTTP API requests The same check applies to a request an [HTTP API plugin](/0.18/configure/plugins#add-an-http-api) sends: a pattern matches against its method, URL and body exactly as it would a shell command. The check screens the request as it is sent - the method, the full URL and the body, such as `DELETE https://api.example.com/v1/zones/a` - so a pattern such as `DELETE` or `/zones/`, which blocks the same request made with `curl`, blocks it too. Before matching, the blacklist reads the request the way the [OWASP Core Rule Set](https://coreruleset.org/) does: it decodes the path, each query value, a form body and each string in a JSON body as a web server would, URL-decodes them once more, removes NUL characters, and normalizes the path by merging `//` and resolving `./` and `../`. The API still receives the request as it was sent. Text encoded once more than that is not matched, and a rule matches letters in the case it is written. A request the blacklist cannot check is let through only when it uses a safe method (`GET`, `HEAD`, `OPTIONS`); anything else is refused until the check can run. A path that leaves the API's address, such as `v1/../admin` or one with an encoded `/` inside a segment, is always refused, whatever the blacklist lists; put such a value in the query or the body instead. The blacklist does not screen the tools of an MCP server. ## Managing Blacklists Go to **Command Center** → **Blacklist** and click **Create Entry** to add a new entry. Blacklist ### Pattern The string or glob pattern that defines which commands to block. Patterns match commands that **contain** the text anywhere, not just exact matches. Glob wildcards are also supported: * `*` matches any sequence of characters * `?` matches a single character Example: `rm -rf *` blocks any `rm -rf` command regardless of the target path. `vim` blocks any command containing the word `vim`. The Command Center shows a **live preview** of matching and non-matching commands as you type, so you can verify a pattern before saving it. A collapsible **syntax reference** is available inline in the create and edit dialogs. ### Description Explains why the command is blocked. Example: `Vim is interactive and can't be operated by LLMs` ### Scope By default, a blacklist is scoped to your current organization and applies only to that org's agents. Pick **Scoped to Tenant** in the **Scope** selector to make the blacklist available to all organizations in the tenant. Selecting the tenant scope requires tenant-level access; without it the selector stays on **Scoped to Organization**. ## Common Use Cases **Destructive Operations** Block high-risk commands for additional safety: * `rm -rf /` * `awscli terminate-instances` * `sudo shutdown` **Interactive Tools** Agents can't interact with prompts or shells: * `redis-cli` * `vim`, `nano`, `vi` * `mysql`, `psql` * `python` **Missing or Unstable Tools** Block commands for tools that aren't installed, have known issues, or are deprecated. ## Best Practices Document why each command is blocked. Review your blacklist regularly as your infrastructure changes. For enforcing preferred alternatives instead of just blocking, see [Operational Rules](/0.18/configure/operational-rules). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.