Are Claude Skills Safe? A Security Review Checklist

Skills are the most benign-looking thing you can install — a Markdown file — and that's exactly why they deserve a real threat model. A SKILL.md is instructions an agent will follow and code it may execute, running with your session's permissions, triggered automatically when a task matches. That's an instruction supply chain, and it deserves the same posture as a package registry. Here's what can actually go wrong, and the five-minute review that covers it.

The threat model

1. Malicious or manipulated instructions. The skill body steers a model that holds your tools. A hostile body can instruct Claude to read files it shouldn't, include their contents in something that leaves the machine (a commit, a PR description, a web request), soften what a review skill reports, or take "adjacent" actions you didn't ask for. This is the skills-flavored version of prompt injection — except you installed the injection and it loads whenever its description matches.

2. Over-broad tool grants. allowed-tools can't exceed your permission settings, but it pre-approves — the skill's tools run without the prompt that would have made you look. A skill whose job needs Read and Grep but ships with bare Bash pre-approved has claimed the exact head-room an attacker (or a buggy body) would want.

3. Bundled scripts. Anything next to the SKILL.md is real code the body can run. A ten-line "helper" script is the least-read, most-capable part of a skill — the natural home for the actual payload in a hostile one.

4. Update drift. A skill that was clean when reviewed can change: a plugin update, a re-synced repo, an upstream marketplace edit. Instructions are behavior; changed instructions are changed behavior, silently.

Worth stating plainly: none of this bypasses Claude Code's permission model — your settings remain the boundary, which is why hardening them matters more once skills are in play, not less.

The pre-install checklist

Five checks, in the order that catches the most:

1. Read the body as if it were a shell script. What does it instruct, and where does it stop? Look hardest at anything touching credentials, git remotes, network access, deletion, or "send/post/publish" verbs. A well-built skill states its boundary ("writing the file is the whole job"); a missing boundary on a side-effecting procedure is itself a flag.
2. Audit allowed-tools against the procedure. Every grant should map to a numbered step. Prefer scoped forms (Bash(git diff:*)) over blanket ones; treat bare Bash on a skill that doesn't obviously need arbitrary commands as a rewrite-before-install.
3. Open every bundled file. Scripts, "templates", reference docs — the payload surface is the whole folder, not just SKILL.md.
4. Check the invocation mode fits the risk. Destructive or costly procedures (deploys, mass edits, anything irreversible) should carry disable-model-invocation: true so only a deliberate /name runs them — auto-invocation plus a broad description is how a casual sentence fires a dangerous runbook. (Field semantics in the reference.)
5. Know your source and pin it. Public, readable sources (the library, anthropics/skills) beat opaque ZIPs; plugin installs should pin versions so review-time behavior is run-time behavior.

For a repo you've just cloned, run claude-settings-auditor before trusting its checked-in .claude/ at all — skills are one layer of a config that can also carry hooks, permissions, and MCP servers.

For teams: govern like code, because it is

• Skills enter via PR. A SKILL.md diff is a behavior diff for every engineer's agent; review it with the same seriousness as CI config.
• One distribution path. Project .claude/skills/ for repo-scoped procedures, a versioned plugin for cross-repo sets, enterprise managed settings for org-wide — and discourage ad-hoc personal installs of unreviewed third-party skills on work machines.
• Re-review on update. Treat plugin version bumps like dependency bumps: diff the skills, not just the changelog.
• Least-privilege by default. House style for your own skills: scoped allowed-tools, explicit boundaries, disable-model-invocation on anything destructive. The skill-auditor skill checks an existing folder against exactly these rules.

The honest summary

Skills are as safe as your review habit. The format has real guardrails — permissions still apply, grants are turn-scoped, nothing installs itself — but the same property that makes skills powerful (instructions that load and act automatically) is the property that rewards a hostile author. Read what you install. It's Markdown; it takes five minutes; it's the whole defense.