Are Claude Code Skills Safe? How to Vet an AI Skill Before You Install It

Installing an AI skill is not like reading a blog post. A Claude Code skill, an MCP server, or any SKILL.md repo runs inside your development environment, often with access to your files, your shell, and your API keys. When you npm install or clone a repo and point your agent at it, you are trusting that code the same way you trust any dependency - except most people vet it far less carefully.

This is a real supply-chain surface. A skill can pull in dozens of transitive npm or pip packages, any of which might carry a known vulnerability or, worse, malicious code. The good news: vetting a skill takes about five minutes if you know what to look at. Here is the checklist we use.

Why AI skills are a security surface

Three things make AI skills riskier than they look:

• They execute, not just inform. An MCP server runs as a process. A Claude Code skill can instruct the agent to run shell commands. This is the whole point - but it means untrusted code gets execution.
• They inherit your permissions. A skill runs as you. It can read your .env, your SSH keys, and your source code unless you sandbox it.
• They carry dependencies. The repo you read might be clean, but its package.json or requirements.txt can pull in packages with known CVEs. The declared dependency tree is rarely the whole story.

None of this means you should avoid skills. It means you should treat installing one like adding any dependency to a production project.

The 7-point vetting checklist

1. Check the source repository

Start with the basics on GitHub. Look at stars and forks as a weak signal of adoption, but weight recent commit activity and open-issue responsiveness more heavily. A repo with 10k stars and no commits in 18 months is a higher risk than a 200-star repo updated last week. Check who the maintainer is - an established account with a track record beats an anonymous one created last month.

2. Read the SKILL.md before you trust it

The SKILL.md file tells the agent what the skill does and when to use it. Read it the way an attacker would write it. Does it ask the agent to run shell commands? Does it touch credentials, network endpoints, or files outside the project? A well-written skill is explicit about what it does. Vagueness is a yellow flag. (New to the format? See our SKILL.md glossary entry and the guide on how to create a SKILL.md file.)

3. Scan the dependencies for known CVEs

This is the step most people skip, and it is the one that catches the most real problems. A skill's declared dependencies should be checked against a vulnerability database before you install. You can do this manually with npm audit or pip-audit after cloning, or run a repository through a scanner that does it for you.

Our free security checker does exactly this: paste any public GitHub repo URL and it checks the declared dependencies against the OSV vulnerability database, flags stale or abandoned repos, and gives you a shareable report - no cloning required. Every skill in the SkillsLLM catalog also goes through a deeper audit (npm audit plus pip-audit on the full locked dependency tree) and carries a Pass / Warning / Fail status on its page.

4. Look for network calls and data exfiltration

Search the code for outbound HTTP calls, telemetry, and analytics. A local-only tool that suddenly phones home is worth understanding. This is not always malicious - many tools have legitimate telemetry - but you should know what leaves your machine, and to where.

5. Check the license

No license means "all rights reserved" by default - you technically have no permission to use it. A permissive license (MIT, Apache-2.0) is the norm for skills. An unusual or missing license is a flag worth pausing on.

6. Prefer a small install footprint

Fewer dependencies means a smaller attack surface and fewer things that can break. A skill that does one job with three dependencies is easier to trust than one that pulls in a hundred. Micro-dependencies are also where a lot of supply-chain attacks hide.

7. Run it in a sandbox first

For anything you are unsure about, run it in an isolated environment first - a container, a throwaway VM, or a project directory with no credentials in scope. Watch what it does before you give it access to anything real.

Red flags at a glance

• Critical CVE in dependencies (high risk) - do not install until it is patched.
• Requests credentials or runs shell commands with no explanation (high risk).
• No commits in 12+ months (medium risk) - likely abandoned, dependencies go stale.
• No license file (medium risk) - usage rights are unclear.
• Anonymous maintainer on a brand-new account (medium risk).
• Hundreds of transitive dependencies (medium risk) - large attack surface.

Automate the boring parts

You do not have to do all of this by hand every time. Two shortcuts:

• Before installing anything: run the repo through the SkillsLLM security checker. It returns a status (Passed / Warning / Failed), the specific issues found, and a permalink you can share or embed as a README badge.
• When browsing the catalog: every skill page shows its catalog scan status, category, and metadata up front, so you can filter for security-vetted tools by category - for example MCP servers or AI agents.

Frequently asked questions

Are Claude Code skills safe to install? Most popular, actively maintained skills are safe, but "safe" is not a property you should assume - it is something you verify. The risk is not the skill format itself; it is the code and dependencies behind any given skill. Vet each one.

What is the biggest risk with AI skills? Vulnerable or malicious dependencies. The repo you read can look clean while pulling in a transitive package with a known CVE. Dependency scanning is the single highest-value check.

Do I need to scan a skill if it has a lot of GitHub stars? Yes. Stars measure popularity, not security. Popular repos get compromised too, and stars say nothing about the freshness of the dependency tree.

How is the SkillsLLM scan different from npm audit? The public security checker checks declared dependencies against the OSV database with no cloning - fast and shareable. The catalog audit goes deeper: it clones the repo and runs npm audit plus pip-audit against the full locked dependency tree. The two can produce different verdicts by design.

The bottom line

AI skills are dependencies that execute. Treat them like it. A five-minute checklist - source, SKILL.md, dependency scan, network behavior, license, footprint, sandbox - catches the overwhelming majority of problems before they reach your machine. And when you want the dependency-scan step done for you, run the repo through our checker first.