A Claude Code skill is a folder containing a SKILL.md file plus any supporting scripts, templates, and reference files that teach the agent how to perform a specialized task in a repeatable way. From a security standpoint the important detail is buried in that definition: a Claude Code skill can ship executable code, and Claude runs those scripts on your machine via bash when the skill triggers. That makes a skill a dependency in every meaningful sense, and installing one from an untrusted source is closer to curl | bash than to editing a config file. This guide explains how skills work under the hood and how to treat them with the same discipline you would apply to any third-party package.
What is a Claude Code skill, mechanically?
Mechanically, a skill is a directory with a SKILL.md file at its root, written in plain Markdown with a YAML frontmatter header. The frontmatter carries a name and a description; the body carries instructions. Alongside SKILL.md the folder can hold anything the task needs: additional Markdown references, templates, data files, and executable scripts in Python, shell, or another language.
Anthropic designed skills to be portable across surfaces — the same skill format works in Claude Code, on Claude.ai, in the Claude Agent SDK, and on the Claude Developer Platform. That portability is a strength for authors and a consideration for defenders: a skill you vet in one context behaves the same in another, which means one careful review protects every place you use it, but one careless install exposes all of them.
How does the SKILL.md progressive-disclosure model work?
The SKILL.md model works through progressive disclosure, a design that loads information into the agent's context only as it is needed rather than all at once. Think of it like a manual with a table of contents, chapters, and an appendix. At startup the agent sees only each skill's name and short description — cheap metadata. When a task matches, Claude uses bash to read the full SKILL.md into context. If those instructions reference other files, the agent reads them too, on demand.
Executable scripts are handled differently, and the difference matters for security. When SKILL.md points to a script, Claude runs it via bash and receives only the script's output; the script's source code never enters the context window. That keeps context lean, but it also means the model is executing code it did not fully "read" into its reasoning. The human who installed the skill is the last line of defense that actually inspected what that script does.
Why is a Claude Code skill a supply-chain concern?
A Claude Code skill is a supply-chain concern because it combines three properties that define dependency risk: it comes from an external author, it runs with your privileges, and it can execute automatically when a task matches its description. A skill's scripts run in the same environment as your shell, with access to your files, your environment variables, and your network. A skill that claims to "format CSV files" could also read ~/.aws/credentials and POST it somewhere, and nothing in the format stops it.
The trigger mechanism sharpens the risk. Because skills activate based on a description matching the task at hand, a malicious skill does not need you to invoke it explicitly — it needs its description to match something you will plausibly ask for. This is the AI-agent equivalent of a typosquatted package: the payload lands not because you chose it, but because it positioned itself to be chosen. The same instincts that make you cautious about a random npm package with two stars should apply to a skill you found in a public gist.
What should you review before installing a skill?
Before installing a skill, read every file in it — literally open SKILL.md and every script it references. The review checklist is short and non-negotiable. Does any script make network calls, and if so, to where? Does it read files or environment variables outside the task's obvious scope? Does it invoke eval, spawn subprocesses, or download and execute anything at runtime? Does the SKILL.md description overreach, claiming to trigger on a broad range of tasks that would let it activate unexpectedly?
Provenance matters as much as content. Prefer skills from Anthropic's official repository or from authors and organizations you already trust. Pin to a specific version or commit rather than tracking a moving branch, so a benign skill cannot be silently updated into a malicious one after you have vetted it. If you build skills internally, code-review them through the same pull-request process you use for application code, because that is exactly what they are. The habit of reviewing what you run — covered in more depth across our security academy — is the whole game here.
How do you sandbox skills that run untrusted scripts?
You sandbox a skill by constraining the environment its scripts can touch, on the assumption that review catches most but not all risk. Run agent workloads that install third-party skills inside a container or VM with no standing access to production credentials. Scope the filesystem so a skill sees only the project directory it needs, not your home folder. Strip secrets from the environment the agent runs in, injecting them only for the specific step that requires them. Restrict outbound network access to the hosts a task legitimately needs.
These are the same controls you would put around any process running third-party code, and they are effective precisely because they do not depend on trusting the skill. A well-reviewed skill in a well-scoped sandbox is defense in depth: two independent layers, either of which would have to fail before a bad script did real damage. For teams running many skills across many repositories, treating the whole collection as a managed inventory — knowing which skills are installed where, and at which version — turns an ad-hoc pile of scripts into something you can actually audit.
Where do skills fit alongside MCP and subagents?
Skills fit into a broader agent toolkit that includes MCP servers and subagents, and knowing the boundaries helps you reason about risk. An MCP server is a running process the agent talks to over a protocol; a skill is static content the agent reads and, when instructed, executes locally. A subagent is a delegated task with its own context. Each expands what an agent can do and each expands the attack surface differently: an MCP server is a network dependency you connect to, a skill is code you install and run, and a subagent inherits whatever tools you granted it. Governing all three consistently — vetting sources, scoping permissions, and keeping an inventory — is what keeps an agentic setup from becoming an unmanaged pile of privileged code.
FAQ
Is a Claude Code skill just a prompt?
No. A skill can be far more than instructions. It is a folder that may contain executable scripts, and Claude runs those scripts on your system via bash when the skill triggers. Treat it as installable code, not as text.
Can a malicious skill run without me invoking it?
Effectively yes. Skills activate when their description matches the task you are working on, so a skill with a broad or deceptive description can trigger on requests you did not consciously connect to it. That automatic activation is why vetting a skill's trigger description matters as much as vetting its scripts.
How do I vet a skill before installing it?
Read SKILL.md and every script it references. Look for unexpected network calls, access to credentials or files outside the task's scope, and any runtime download-and-execute behavior. Prefer official or trusted authors, and pin to a specific version so it cannot be silently updated after review.
Should internal skills go through code review?
Yes. A skill your team writes carries the same execution risk as one you download, so route it through the same pull-request review and versioning process you use for application code. Skills are dependencies, and dependencies get reviewed.