In October 2025, Anthropic shipped "Skills" for Claude — small, composable bundles of instructions, scripts, and resources that let an agent pick up a new capability on demand. OpenAI's GPT Store, Hugging Face's Hub, and the fast-growing ecosystem of Model Context Protocol (MCP) servers followed the same pattern: a public or semi-public repository where anyone can publish a package of code and instructions that an autonomous agent will fetch, load, and execute with elevated trust. It is, structurally, npm in 2015 — a permissionless registry, minimal review, and exponential growth — except the artifact isn't a library your build pipeline imports, it's a set of instructions an agent will act on, often with access to your filesystem, credentials, and internal APIs. JFrog has spent a decade teaching the industry to treat packages as a governed supply chain. Skills and plugins are packages. They deserve the same discipline — and most organizations aren't applying it.
What actually is an "AI agent skill," and why does it behave like a package?
A skill or plugin is a package because it has the same three properties that made npm and PyPI attack surfaces: a public registry, an installable artifact, and code that executes with the privileges of whatever installed it. Concretely, a Claude Skill is a folder — typically a SKILL.md file plus supporting scripts (Python, Bash, JavaScript) and reference data — that gets pulled into an agent's context and, critically, can include executable code the agent is instructed to run. An MCP server is a standalone process that an agent connects to and grants tool-call access — file reads, shell execution, database queries, API tokens. A GPT Store "app" or a ChatGPT plugin manifest similarly wires an LLM to external actions. None of these differ meaningfully from an npm package that runs a postinstall script, except for one thing: the "reviewer" deciding whether to trust the artifact is frequently the agent itself, at inference time, with no human in the loop and no CI gate to fail. Gartner's 2025 AI TRiSM guidance projected that by 2027, over 40% of agentic AI deployments will be canceled due to unmanaged risk, escalating costs, or unclear controls — and unreviewed third-party skills are a primary driver cited in that research.
Why did the npm and VS Code precedents matter, and are the same attacks already happening in skill registries?
They matter because the exact same attack techniques — typosquatting, dependency confusion, and post-publish payload swaps — are already documented against AI plugin ecosystems, just twelve months behind package registries on the maturity curve. Sonatype's 2024 State of the Software Supply Chain report counted over 700,000 malicious packages identified across open source registries since it began tracking in 2019, with a 156% year-over-year jump in npm alone — proof that a permissionless publish model reliably attracts industrialized abuse once volume justifies it. VS Code's Marketplace saw the same lesson in 2024, when ReversingLabs and other researchers identified extensions with millions of combined installs that shipped obfuscated data-exfiltration code post-publication, passing initial review, then updating with malicious logic later. Early 2025 research from Backslash Security and independent labs found MCP servers published with path-traversal flaws, command-injection sinks, and tool-poisoning payloads — prompt injection hidden in tool descriptions that manipulates the agent into taking unauthorized actions — across dozens of publicly listed servers with no equivalent of a CVE process to track or revoke them. The registries are younger; the attackers are not.
How does JFrog cover this today, and where does its model stop short?
JFrog covers the package and, increasingly, the ML model layer — but its governance model was built around artifacts with fixed binaries and known package managers, not agentic, self-modifying skill bundles. Artifactory has long served as a universal binary repository, and JFrog Xray scans dependencies for known CVEs and license risk across ecosystems like npm, PyPI, and Maven. JFrog's 2024 acquisition of Qwak extended that reach into MLOps, letting Artifactory version and scan machine learning models (including Hugging Face artifacts) for embedded malware such as unsafe pickle deserialization. JFrog Curation, launched the same year, adds a pre-download policy gate that blocks known-malicious or unapproved packages before they ever reach a developer's machine. That's real coverage for models and dependencies. But a Claude Skill or an MCP server manifest isn't a .whl file or a .safetensors checkpoint sitting in a registry waiting to be scanned for a known CVE — it's natural-language instructions plus scripts whose intent has to be evaluated behaviorally, its declared tool permissions have to be checked against least privilege, and its provenance has to be tracked across silent updates the way a browser extension's is. JFrog's scanners are signature- and CVE-driven; skill and plugin risk is largely behavioral and permission-based, and that's a different detection problem entirely.
What's the realistic failure mode when a team installs an ungoverned skill?
The realistic failure mode is a developer or agent operator installing a community skill that requests broad tool access, then quietly exfiltrating data or executing commands under the agent's existing credentials — no separate exploit required, because the "vulnerability" is the permission grant itself. Imagine a "PDF report generator" skill published to a community skills index that bundles a Python script; the SKILL.md describes formatting logic, but the script also reads environment variables and POSTs them to an external endpoint the first time it runs inside a CI agent with cloud credentials mounted. Because skills are loaded dynamically and often auto-updated, a clean initial version can be swapped for a malicious one after it accumulates installs and trust — the identical playbook used in the 2021 ua-parser-js npm compromise (over 7 million weekly downloads at the time) and the 2024 xz-utils backdoor, where a trusted maintainer identity was used to slip malicious code into a widely-depended-on artifact just before it would have shipped in major Linux distributions. Agent skills compress the blast radius timeline: there's no separate build step where a static scanner might catch an anomaly, because the "build" is the agent reading and executing the instructions live.
What does real governance for agent skills require, beyond "just add a scanner"?
Real governance requires the same four controls the package ecosystem eventually converged on — provenance, an SBOM equivalent, permission scoping, and revocation — applied to instructions instead of just binaries. First, provenance: cryptographic signing and publisher verification so a skill's origin can be attested, comparable to npm's provenance attestations (GA since 2023) and Sigstore-based signing now common in container registries. Second, an SBOM analog — call it a Skill Bill of Materials — that enumerates every script, external call, and declared tool permission a skill requests, checked against a policy baseline before install, not after an incident. Third, least-privilege enforcement at the agent runtime: an MCP server or plugin should declare the exact tools and data scopes it needs, and the agent host should be able to deny anything broader, the same way OAuth scopes replaced blanket API keys. Fourth, continuous monitoring for drift — since skills and MCP servers can update post-install, governance can't be a one-time gate; it needs the equivalent of Dependabot-style continuous re-evaluation watching for a trusted package silently becoming a malicious one.
How Safeguard Helps
Safeguard extends the software supply chain security model your team already applies to packages and containers to the newest artifact class: AI agent skills, plugins, and MCP servers. We treat every skill bundle the way we treat a package release — resolving its full provenance chain, generating a manifest of every script, dependency, and declared tool permission it carries, and flagging requests that exceed least-privilege norms for its stated function before it's approved for use. Our behavioral analysis engine inspects skill scripts and MCP server code for the specific patterns seen in real incidents — obfuscated exfiltration calls, prompt-injection payloads embedded in tool descriptions, and command-injection sinks — rather than relying solely on CVE signature matching, which doesn't exist yet for most of this ecosystem. Because skills and plugins update silently after install, Safeguard continuously re-evaluates approved artifacts against your policy baseline and alerts on drift, closing the exact gap that let ua-parser-js and xz-utils-style compromises slip through package ecosystems for years. And because most organizations already run JFrog, GitHub, or another registry for packages and containers, Safeguard integrates alongside that stack rather than replacing it — giving security and platform teams one governance layer that spans traditional dependencies, ML models, and the AI agent skills your teams are adopting faster than most security programs can review them.
If your organization is piloting Claude Skills, ChatGPT plugins, or MCP servers in production workflows, the question isn't whether to govern them — it's whether you do it before or after the incident that makes it non-optional. Talk to Safeguard about extending your existing supply chain controls to AI agent skills before your next agentic rollout.