# Are Claude Skills Safe? A Security Review Checklist

> Skills are an instruction supply chain: what can go wrong with third-party SKILL.md files, and the review checklist before installing or distributing one.

A skill is instructions Claude follows and code it may run, executing with your session's permissions — which makes third-party skills a supply chain, and installing one an act of trust. The realistic risks: malicious or manipulated instructions, over-broad tool grants, bundled scripts, and quiet exfiltration. All four are reviewable in minutes with the checklist here.

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](/guides/configuration/claude-code-settings-permissions) 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](/guides/skills/skill-md-reference).)
5. **Know your source and pin it.** Public, readable sources (the [library](/skills), 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](/skills/workflow/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](/guides/skills/packaging-and-sharing-skills) 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](/skills/workflow/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.

---

_Source: https://agentscamp.com/guides/ai-safety/are-claude-skills-safe — Guide on AgentsCamp._