# allowed-tools and Least Privilege — Claude Code Skills & SKILL.md

Source: https://www.geekswithgeeks.com/en/claude-code-skills/f-tools

> Limit what a skill may do without asking.

## 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.

```yaml
# 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.

**Quiz:** Why keep allowed-tools narrow?

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

*Answer:* Everything listed is pre-approved, so a broad list widens what an attack or mistake can do. Least privilege applies to skills like any automation.