Claude Skills API Is GA, Turning Reusable Prompts Into Supply-Chain Risk

Anthropic made its Skills API generally available on August 20, turning a folder of instructions, scripts, and templates into a versioned component that developers can attach to Claude API requests. That is useful packaging. It is also a software supply-chain decision: the bundle can influence what an agent reads, which code it runs, what data it handles, and which other capabilities it tries to use.

The safe default is to treat every skill as executable material, admit one reviewed version at a time, and reject any update that cannot reproduce its provenance, requested capabilities, test evidence, and rollback path. A polished SKILL.md, a marketplace count, or a sandbox label is not enough.

A skill is both instruction and execution material

Anthropic’s general-availability announcement defines a skill as a folder that can contain instructions, scripts, and templates. Developers upload and version custom skills, then attach them to requests that use the code-execution environment.

That mixture defeats a familiar review shortcut. Reading only conventional source files misses natural-language instructions that can redirect the model. Reading only SKILL.md misses scripts and referenced files loaded later. Reviewing the top-level folder once misses a mutable dependency or a new version uploaded after approval.

Two non-peer-reviewed papers show why the whole bundle matters. A 2025 prompt-injection preprint demonstrates attacks hidden in long skill instructions and referenced scripts, including a tested case where a prior task-specific approval carried over to a harmful related action. Its experiments cover particular agents and configurations, not every product or deployment, but they establish that an instruction file can participate in a real execution chain.

A separate large empirical preprint collected 42,447 skills from two marketplaces and analyzed 31,132 with a scanner combining static analysis and an LLM classifier. The authors report that 26.1% triggered at least one of 14 vulnerability patterns and that skills containing executable scripts were 2.12 times as likely to be flagged as instruction-only skills.

That result does not mean 26.1% of skills were malicious. The paper reports 86.7% precision and 82.5% recall for its detection method, and only 5.2% of analyzed skills had high-severity patterns the authors considered strongly suggestive of malicious intent. Automated findings combine hostile, negligent, ambiguous, and misclassified cases. They are a reason to review, not a verdict.

“Sandboxed” means different things on different Claude surfaces

The Agent Skills overview documents three distinct environments. Collapsing them into one security claim produces the wrong admission decision.

The API container’s no-network rule is a meaningful hard boundary. It blocks a script in that container from calling an external API and prevents runtime package installation. It does not make the bundle trustworthy. A hostile instruction can still corrupt an output, misuse files deliberately provided to the container, or steer the broader agent toward another granted tool. Review the complete agent request and tool set, not the skill container in isolation.

Workspace scope also matters. Anthropic’s API guide says every API key in a workspace can read, invoke, and delete every custom skill there. It recommends a separate workspace for each tenant in a multi-tenant service. A shared default workspace is therefore an authorization boundary, not merely an organizational label.

The marketplace incident was a version-control failure too

A current campaign shows why reputation at install time cannot replace immutable provenance. TechRadar reported that attackers cloned legitimate skills under look-alike names, accumulated downloads, and later introduced credential-stealing behavior.

Security company Zenity, which found and helped disrupt the campaign, provides the technical timeline. The malicious family imitated Paperclip and Browser Use projects. Its skill documents were initially clean; later revisions placed harmful instructions in a secondary setup file that the main skill loaded only for installation. Zenity says the family passed 1.7 million aggregate displayed installs before takedown, while warning that the counters were neither unique users nor a victim count.

The case is evidence of a real campaign, not evidence that Anthropic’s managed API sandbox was breached. The affected skills targeted agent and developer hosts where instructions could lead to package installation and credential access. Its durable lesson is narrower: names, popularity, and a previous clean scan do not bind the bytes that run tomorrow.

Anthropic’s API already exposes the control needed to avoid that ambiguity. Custom skill updates receive version IDs, and each version is a complete snapshot. The API guide explicitly recommends pinning a specific version in production; selecting latest lets a newly uploaded workspace version immediately change deployed behavior.

General availability makes version identity part of the trust boundary

A trustworthy deployment has to bind the reviewed source, the complete bundle, its dependencies, Anthropic’s stored version, and the authority the runtime grants it. Reviewing only the main instruction file misses secondary setup files and scripts; pinning only a repository commit misses a separately uploaded Platform snapshot. Using latest deliberately gives up that binding.

Runtime containment and artifact review solve different problems. The API container’s no-network boundary limits what executed code can reach, but it cannot prove that an instruction is benign or that the broader agent will not misuse another granted tool. Conversely, a clean source review does not make an over-permissioned workspace safe. The marketplace campaign matters because it combined mutable distribution, reputation signals, and delayed malicious changes—the exact conditions an immutable version is supposed to separate.

The same boundary appears in the Snowflake GitHub Actions investigation: text became dangerous when a privileged system treated it as code. The Slack Code analysis follows that chain beyond one agent into repository, CI, and deployment controls.

Approval expires when any material boundary moves

Any trust decision covers one bundle, one version, one runtime surface, and one capability set. A change to an instruction, referenced file, dependency, permission, data class, external tool, runtime policy, or workspace boundary creates a materially different system. Even an unchanged bundle can become riskier if its source disappears or changes ownership.

Anthropic’s containment engineering note makes the broader reason clear: an external agent resource creates both conventional code-execution risk and prompt-injection risk. Source review and version pinning address part of the first. They do not prove how the model will interpret every instruction. Sandboxing limits consequences, but model-level defenses are probabilistic and cannot replace environmental boundaries.

General availability makes skill reuse easier to operate. The production question is no longer whether a team can upload a folder. It is whether the team can prove which folder ran, what authority it received, what happened in the test, and how quickly that authority can be withdrawn when the next version is not the one it approved.

Sources

1. Anthropic announcement for the generally available Skills API
2. Claude Platform Agent Skills overview
3. Claude Platform guide to using and versioning API skills
4. Anthropic engineering note on containing agents and external resources
5. Agent Skills prompt-injection preprint
6. Agent Skills in the Wild empirical security preprint
7. TechRadar report on a typosquatted skill campaign
8. Zenity Labs technical report on the skill supply-chain campaign