Tool allowlist

A tool allowlist is the explicit set of commands / APIs / files an agent is allowed to use — deny-by-default permission policy preventing the agent from invoking surprise tools. Claude Code's settings.json, Cursor allowlist, MCP server scoping are 2026 implementations.

Tool allowlists invert the default: instead of 'allow everything unless flagged unsafe', the agent can only do what's been explicitly permitted. Implementations: per-tool name (`Bash:git status` allowed, `Bash:rm -rf` denied — Claude Code's pattern), per-host network policy (only fetch from allowed.example.com), per-MCP-server scope (this server can read only `/docs`). Production patterns: start narrow (just reads + safe tools), broaden as the agent proves itself; use stricter allowlists for autonomous / background agents; loosen for interactive plan-approval flows. Allowlists are the simplest + most auditable agent safety mechanism — explicit policy beats implicit trust.

When to use tool allowlist

• Any production agent.
• Especially autonomous / background agents.

Common mistakes

• Wildcards that match dangerous commands (`Bash:*` allows `rm -rf`).
• Forgetting to allowlist tools the agent legitimately needs — broken UX.

FAQ

Related terms

• Tool permission — Tool permission is the agent-platform mechanism for granting / denying specific tool calls (read this file, run this command, hit this API) — required guardrail for any production agent with non-trivial side effects in 2026.
• Agent sandbox — An agent sandbox is the isolated execution environment where an LLM-driven agent runs code, browses, or controls a desktop — the safety boundary that contains prompt-injection blast radius.
• Approval workflow — An approval workflow is the agent pattern where high-impact actions (send email, make purchase, delete data) pause for human approval before executing — the production-safe alternative to fully autonomous agents.

Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/tool-allowlist.md.