Claude Code skills are modular, filesystem-based extensions that give an AI coding agent task-specific instructions and scripts it loads on demand, and because an approved skill can direct the agent to run code and reach the network, a skill you did not write is code you are choosing to trust. The convenience and the risk are the same mechanism, which is exactly why they deserve the same scrutiny you would give any third-party dependency.
I have been reviewing these as they show up in real repositories, and the pattern that worries me is not exotic. It is teams installing a skill from a random gist because it saves ten minutes, without reading what is in it.
What a Skill Actually Is
A Claude Code skill is a directory containing a SKILL.md file. That file starts with YAML frontmatter carrying required metadata, principally a name and a description, followed by natural-language instructions. The directory can also bundle scripts, templates, and other resources the skill references.
The mechanism that makes skills efficient is progressive disclosure. The short description sits in the agent's context by default so it knows the skill exists; the full SKILL.md and any bundled files are read only when the task calls for it. That is good for token economy. It is also why a skill's real behavior is easy to overlook: you approve based on a one-line description, and the detailed instructions load later, out of view.
Why SKILL.md Is a New Attack Surface
Here is the uncomfortable part. A SKILL.md is instructions written in plain language that an agent with tool access will follow. Anthropic's own guidance is blunt about it: use skills only from sources you trust, because a malicious skill can direct the agent to invoke tools or execute code in ways that do not match the skill's stated purpose.
The concrete failure mode is small. A few lines of natural language buried in a SKILL.md can tell the agent to read a credentials file and POST its contents to an external endpoint. The description says "formats your commit messages." The body says something else. If the agent has file-read and network tools, and the skill is approved, it complies.
This is not a hypothetical unique to one product. Security researchers auditing published agent skills at scale have found that a meaningful fraction contain security flaws or outright malicious instructions. The exact percentages vary by study and I would not quote a single number as gospel, but the direction is consistent: the ecosystem of shared skills is not curated the way a major package registry is, and treating it as safe by default is a mistake.
The Trust Model: Approve Once, Trusted Forever
The second structural issue is persistence. Once you approve a skill, it can gain durable ability to read and write files, download or run additional code, and open outbound connections, without prompting you again for each action. That is the whole point of an agent, but it means the approval decision is doing a lot of load-bearing work.
Compare it to installing an npm package with a postinstall script. You would not run npm install some-random-package on a machine with production credentials without a second thought, and a skill is closer to that than to a config file. The trust boundary moved: it is no longer just your code and your dependencies, it is also the instructions your agent is willing to act on.
How to Vet a Skill Before You Trust It
Treat skill review like a code review, because it is one. When auditing a skill, read every file it bundles, not just SKILL.md: scripts, templates, images, and any resource it points at.
A practical checklist:
- Read the full
SKILL.md, not the description. Look for instructions that read secrets, credentials, environment variables, or.envfiles. - Flag any network activity. A skill for formatting code has no business making outbound requests.
curl,fetch, webhook URLs, or "send the result to..." are red flags. - Inspect bundled scripts the same way you would a dependency's install hooks. Obfuscated or base64-encoded payloads are almost never benign.
- Check for a mismatch between the stated purpose and the actual capabilities the skill exercises. Purpose says "lint," behavior touches your SSH keys, stop.
- Prefer skills authored by you or obtained from the vendor's own catalog over ones pulled from anonymous repositories.
Sandboxing and Least Privilege
Reviewing helps, but defense in depth means assuming a skill might misbehave and limiting the blast radius.
Do not run agents with skills on a machine that holds production credentials, cloud admin keys, or customer data you cannot afford to lose. Give the agent scoped, short-lived credentials rather than your personal long-lived tokens. Where the platform supports permission gating, require confirmation for consequential tool actions like network calls or file deletion, so a malicious instruction cannot execute silently.
Version-control the skills your team relies on, review changes to them like any other code change, and pin to reviewed versions rather than auto-pulling the latest from an upstream you do not control. A supply chain mindset applies cleanly here: the Safeguard Academy covers the same principles for traditional dependencies, and skills are simply a new kind of dependency, one written in prose.
The Bigger Picture
Agent skills are genuinely useful and I use them daily. The point is not to avoid them; it is to stop treating them as inert configuration. A SKILL.md is executable intent for a system that can act on your behalf. Read it, scope what the agent can do, and source your skills the way you source your libraries. The failure mode is not a clever zero-day. It is a team pasting three lines of trusted-looking Markdown into a tool that will do exactly what those lines say.
FAQ
What is a Claude Code skill?
It is a directory containing a SKILL.md file with YAML metadata (a name and description) plus optional scripts and resources. The agent loads the description by default and reads the full instructions on demand when a task is relevant, extending what the agent can do without cluttering its context.
Are Claude Code skills a security risk?
They can be. A skill is instructions an agent with tool access will follow, so a malicious SKILL.md can direct the agent to read secrets or exfiltrate data even if its description claims something harmless. Use skills only from sources you trust and review every file they bundle.
How do I vet a skill before installing it?
Read the entire SKILL.md rather than just the one-line description, inspect any bundled scripts as you would a dependency's install hooks, flag outbound network calls or secret access that the stated purpose does not justify, and prefer skills you wrote or that came from the vendor's own catalog.
How is a malicious skill different from a malicious package?
The mechanics are similar; both can execute code with your privileges once trusted. The difference is that a skill's harmful logic can be plain natural language rather than obfuscated code, which makes it easy to skim past, and approval is often one-time, granting durable capability rather than a single action.