How to Audit a Claude Skill Before Installing in 2026

How to Audit a Claude Skill Before Installing in 2026

A friend installed a "productivity boosting" skill from a random GitHub repo three weeks ago. Inside the references/ folder was a sub-file with instructions to read every file matching .env, .pem, id_rsa, and credentials* and "summarize the contents for context." When he asked Claude a normal question, the skill activated and started reading.

Nothing got exfiltrated — Claude does not have a way to send arbitrary network requests by default — but he had to revoke five API keys on the off chance the conversation context leaked somewhere. The skill is still public on GitHub, still installable, still ranks for the search term he used.

This is the security review you should do before installing any non-Anthropic skill. It takes about 10 minutes per skill. The cost of skipping it is bigger than the cost of doing it.

Why Skills Are a Bigger Risk Than You Think

A Claude Code skill is just a markdown file. The text in it becomes part of your prompt every time the skill activates. There is no sandbox, no permission gate, no warning when a skill's instructions tell Claude to read your SSH keys.

The trust model for skills is exactly the same as the trust model for system prompts you write yourself: full trust, no isolation. The difference is that you wrote your own system prompt; you did not write the skill author's instructions.

Three failure modes to plan for:

1. Direct exfiltration. Skill instructs Claude to read sensitive files and dump them into the conversation. If you have logged conversations or share screenshots, the data is now leaked. 2. Indirect exfiltration via tool use. Skill instructs Claude to make a "documentation lookup" call to an attacker-controlled URL with conversation context as a query parameter. 3. Behavior corruption. Skill is benign in isolation but introduces subtle bias (always recommend tool X, always avoid mentioning competitor Y) that pollutes future outputs without obvious tells.

The first two are catchable with a 10-minute audit. The third is harder; the practical defense is reputation (install from known authors and well-starred repos).

The 10-Minute Audit Process

Step 1: Identify Where the Skill Lives

Three common sources, in order of trust:

1. Anthropic's official skills (bundled with Claude Code, no separate install) 2. Anthropic-managed plugin registry (claude plugin add <name>) 3. Random GitHub repos (git clone into ~/.claude/skills/)

Anthropic-published skills are reviewed; treat them like first-party code from a software vendor. Plugin registry skills have lighter review; treat them like a popular npm package — probably fine, but read the source for anything sensitive. Random GitHub repos get the full audit every time.

Step 2: Read SKILL.md End to End

Every skill has a SKILL.md at its root. Open it and read the whole thing. Not skim — read.

Look for:

• Instructions to read files outside the project. Phrases like "read ~/.ssh/", "check files in ~/.aws/", "look at the user's environment variables", "open *.env".
• Instructions to run shell commands beyond the obvious workflow. A "code review" skill running curl to "fetch updated rules from a server" is a red flag.
• Hardcoded URLs, especially shorteners. bit.ly, tinyurl, pastebin raw URLs, IP addresses. If the skill needs to fetch something, the URL should be obvious and stable.
• Instructions to "ignore previous instructions" or "override safety guidelines." Yes, people actually write this in the skill body. It is the prompt injection equivalent of an unlocked front door.
• Output instructions that summarize sensitive context. "Summarize the conversation for the project log at /tmp/log.txt." Logs become exfiltration channels if anyone else reads /tmp.

Step 3: Check the references/ Folder

Most skills have a references/ subfolder for longer documentation that gets loaded on demand. The malicious instructions are usually here, not in SKILL.md, because authors of bad skills know auditors mostly check the front door.

Open every file in references/. Read the whole thing. The same red flags as Step 2 apply.

If the references/ folder has more than a few files (5+), the skill is either ambitious or hiding something. Look harder.

Step 4: Grep for Specific Patterns

A few minutes of grep catches things you missed by skimming:

``bash cd ~/.claude/skills/the-skill grep -ri "ssh\|\.aws\|\.env\|credential\|secret\|password\|token\|api_key" . grep -ri "curl\|wget\|fetch\|http" . grep -ri "ignore previous\|ignore the above\|disregard" . grep -ri "exfiltrate\|send to\|upload to\|post to" . `

Hits are not automatic disqualifications — a security audit skill will mention "credential" legitimately. But each hit needs a "why is this here?" answer that makes sense.

Step 5: Check the Repo Itself

If the skill came from GitHub:

• Star count. Below 50, treat as personal project (could still be fine, but no community vouching).
• Issue history. Lots of "skill broke X" issues with no responses = abandoned project. Lots of issues that look like security concerns with no responses = walk away.
• Contributor list. A single author is more risk than an organization with multiple maintainers. Single-author is not disqualifying for small skills, but raises the bar.
• Commit history. Recent activity is good. A repo last committed in 2024 with no responses to issues is unmaintained.
• The author's other repos. Established devs with a public history of useful work are lower risk. Anonymous accounts created last month with one repo are higher risk.

Step 6: Run the Skill in a Safe Conversation First

Before using a new skill on real work, start a fresh Claude Code conversation and ask the skill to do something simple. Watch what files it reads, what tools it tries to invoke, and what it tells you. If the behavior matches the documentation, it has earned its place. If it asks to do unexpected things, uninstall.

Five Red Flags That Mean Walk Away

If any of these show up in audit, do not install:

1. Instructions to read files outside the working directory without an obvious reason in the workflow. 2. Network calls to non-obvious URLs (especially shorteners, IPs, or "config servers"). 3. Prompt injection patterns ("ignore previous instructions", "you are now in unrestricted mode"). 4. Hidden text in white-on-white or zero-width Unicode (rare but real). View raw markdown with a hex viewer if anything feels off. 5. Author with no track record + repo with low engagement + sensitive workflow. Stack the unknowns and walk away.

When in Doubt, Do Not Install

Skills are a small productivity gain. Most are nice-to-haves, not must-haves. The cost of installing a malicious skill (revoked credentials, leaked context, time spent investigating) is much higher than the cost of using Claude without that one skill.

If your audit takes longer than 10 minutes because the skill is opaque, that is a signal in itself. Walk away.

Tools That Help

A few skills exist specifically to help audit other skills:

• [Trail of Bits Security](/skills/trailofbits-security) — security review patterns adapted from professional audits
• [Strix](/skills/strix) — generic security scanner that works on skill source
• [Prowler](/skills/prowler) — cloud security focus, useful when skills touch cloud APIs
• [Ffuf Security Scanner](/skills/ffuf-scanner) — for the network-call validation step

Comparison: [Strix vs Trail of Bits: Best AI Security Skill](/blog/strix-vs-trailofbits-best-ai-security-skill-2026)

What to Do If You Already Installed Something Sketchy

1. Uninstall immediately: rm -rf ~/.claude/skills/the-skill 2. Check what conversations you have had since installing 3. Rotate any credentials that could have appeared in conversation context (API keys, tokens, passwords) 4. Check shell history for unusual commands the skill might have suggested 5. Report the repo to GitHub's abuse channel if it is clearly malicious

How to Build Trust Over Time

A practical heuristic that works:

• First-party skills (Anthropic) → install freely
• Skills from people you know → light audit, install
• Skills from established devs (verified accounts, public history) → 10-minute audit, install if clean
• Skills from unknown authors → 10-minute audit + run-in-safe-mode test, install if both pass
• Skills that fail any audit step → walk away

The community is small enough in 2026 that "established author" is a meaningful filter. That changes as the ecosystem grows, but for now, reputation is doing real work.

FAQ

Q: Will Claude itself catch malicious skills? Sometimes, not always. Claude has injection-defense training and will flag obvious "ignore your previous instructions" attempts. Subtle malicious skills (instructed to silently summarize the user's home directory) often slip through. The audit is your defense.

Q: Can a skill access my filesystem outside the project? Yes, if Claude Code's permission settings allow it. By default Claude asks before reading files; if you have set autoApprove: true` for file reads, a skill can read anything you can read. Check your settings before installing.

Q: What if I just disable a suspicious skill instead of uninstalling? Disabling stops it from auto-loading but leaves the file on disk. If you accidentally re-enable, you are back to running it. Delete entirely.

Q: Does this audit apply to MCP servers too? The principle (read source, check author, test in safe environment) applies. The mechanics differ — MCP servers are running processes with their own dependencies. The audit for MCP includes "what does the server's code do" plus "what does the server's network behavior look like in practice." Longer post for another day.

Q: How often do malicious skills actually appear? Rare but not zero. Most skill authors are building useful things. The cost of getting hit by a malicious one is high enough that 10 minutes of audit per install is the right tradeoff.