Rules / Hidden content and security

sec-skill-allowed-tools

allowed-tools grants unscoped Bash, all tools, any interpreter or unscoped WebFetch.

warning by default Hidden content and security Config or baseline only

Source: Claude Code docs: Skills (code.claude.com), read 14 October 2026.

On GitHub: the rule doc and the tests.

All rules73

What it catches#

allowed-tools grants unscoped Bash, all tools, any interpreter or unscoped WebFetch.

A skill or Claude Code command whose allowed-tools grants Bash or PowerShell with no command pattern (or Bash(*)), every tool (*), WebFetch with no domain, an interpreter with any arguments (Bash(python *), Bash(node *), Bash(sudo *)), or curl or wget to any host. Those tools then run without a permission prompt during the turn that invokes the skill or command (the grant clears with your next message). Needs --include skills. With extends: strict in .asitisrc.json it also notes subagents that have no tools list, since they inherit every tool; that note is not shown by default.

Why it matters#

allowed-tools lets the listed tools run without a prompt during the turn that invokes the skill or command (the grant clears with the next message). A subagent with no tools list inherits every tool; extends: strict reports that too.

Bad example#

---
name: changelog
description: Draft the changelog for the next release. Use when asked for release notes.
allowed-tools: Bash WebFetch
---

Any shell command and any URL, no prompt, for the whole turn that invokes the skill. A prompt injection in a PR description the skill reads becomes code execution.

Good example#

---
name: changelog
description: Draft the changelog for the next release. Use when asked for release notes.
allowed-tools: Bash(git log *) Bash(git tag *) Read
---

How to fix#

List the commands the skill actually runs, with their prefixes: Bash(git log *), Bash(pnpm test). Leave out tools the skill does not need; Claude asks for the rest as usual.

Suppress or configure#

sec-skill-allowed-tools is a security rule, so it cannot be suppressed with a comment in the file: a suppression comment is itself a hidden comment, and an attacker who can add a payload can add one next to it. A comment that tries gets a suppression-not-allowed warning.

Turn it off, or change its severity, in .asitisrc.json, which shows up in review:

{ "rules": { "sec-skill-allowed-tools": "off" } }

Or accept the findings you have today in a baseline, so only new ones fail the build:

asitis lint --format json --write-baseline > .asitis-baseline.json
asitis lint --baseline .asitis-baseline.json

Source#

Claude Code docs: Skills, read on 14 October 2026.

Run the rule

This page is generated from the plugin's rule registry. Edit it on GitHub. False positive? Open an issue with the line it fired on.