allowed-tools and Least Privilege

Pre-approve the narrow thing the skill needs

Skills can declare an allowed-tools field that lists the tools (and, for shell commands, command patterns) the skill may use without a separate permission prompt while it is active. This is convenient, because a skill that runs its own helper script should not ask you to approve it every time, and it is a security decision: whatever you list is pre-approved. Keep it as narrow as possible: name the specific script (for example only node running that skill's own file) rather than allowing all of Bash; prefer read-only tools for review and analysis skills; never pre-approve destructive commands. The exact pattern syntax and enforcement can differ between versions, so read the documentation and test that the skill cannot do more than intended. Remember that pre-approval widens what a prompt-injection attack could do, so be conservative.

Narrow versus broad allowed-tools

Frontmatter excerpts. The pattern style follows examples used in Claude Code skills; verify the syntax for your version. Not run here.

# NARROW: only this skill's own helper script, nothing else
allowed-tools: Bash(python scripts/prs_since_tag.py:*)

# BROAD: any shell command, pre-approved for the whole skill (avoid)
allowed-tools: Bash

Test what the skill can actually do

Try asking the skill to do something outside its purpose and confirm it is blocked or prompts first.

Quick check: Why keep allowed-tools narrow?

• Broad lists are required
• Narrow lists make skills run faster
• The field is decorative
• Everything listed is pre-approved, so a broad list widens what an attack or mistake can do