When a Helpful Skill Becomes a Supply-Chain Decision
This series examines the public ecosystem of third-party agent skills: small packages that extend coding and analysis agents with reusable instructions and helper tools. This opening focuses on the trust boundary created when those packages are installed locally and read by an instruction-following model. The practical goal is to give the reader a mental model for deciding what a skill is allowed to do, what its publisher and registry actually guarantee, and why the available evidence matters without turning one study into a universal risk percentage.
The extension that arrives with authority
An agent skill often looks less consequential than a conventional software package. It may promise to summarize videos, calculate numbers, format a presentation, or automate a workflow. But its apparent modesty says little about its authority. In the ecosystem studied by Liu and colleagues, a skill is a file-based package: a persistent instruction document, commonly named SKILL.md, can sit beside Python, Shell, or JavaScript helpers. The package is discovered through a community registry and then made available to an AI agent running on the user’s machine.
That last step changes the question. A browser extension, plug-in, or package is already a supply-chain component because someone else’s code enters a system that the user trusts. An agent skill adds another route into that system. Its helper code may run locally with the user’s privileges, while its prose is supplied to the agent as instructions about how to act. The publisher is therefore not just distributing functionality. The publisher is distributing a potential participant in the agent’s decision process and in the host environment’s execution path.
The distinction matters because privilege is not something the skill necessarily has to win through a separate exploit. In the paper’s threat model, an unsuspecting user installs a skill that appears useful; the skill then begins from an environment in which the agent already has the access granted by its host. A malicious package can move directly toward files, credentials, network connections, or tool calls. The supply-chain failure is the moment at which a distribution decision is mistaken for a safety decision.
This is a familiar software-supply-chain problem with an unusual entry point. A package registry normally helps a user find code, and a package manager may check an identity, version, or integrity value. None of those signals, by themselves, answer whether the code matches the package’s stated purpose. In an agent-skill marketplace, the registry listing also becomes a search result for a capability the agent can perform. The lower the friction between discovery and activation, the more important it is to make the publisher, permissions, and behavior legible before the skill reaches the local runtime. The USENIX study describes the two public registries it examined as community-maintained aggregators rather than centralized, vendor-governed inventories. That does not make every listed skill suspect. It means the surrounding system cannot quietly be assumed to have performed the safety work.
The basic system looks like this:
The two branches are connected, not interchangeable. A helper script can collect or transmit data directly. Instructions can instead steer the agent to take an action, suppress a warning, or avoid asking the user for permission. The same skill can contain both forms of influence, so a review that checks only executable files or only model behavior is looking at half of the package.
The paper’s opening example makes the mismatch concrete without requiring a sophisticated exploit: a skill presented as a calculator can carry a helper that opens an interactive shell. The public description remains a useful calculation story; the runtime behavior belongs to a different category. The important lesson is not the particular payload but the failed correspondence between what the user approved and what the package can cause. A reviewer needs to ask two separate questions: “Can this code do something dangerous?” and “Does the agent’s interpretation of this document cause actions that the user did not authorize?”
Those questions also identify different owners. The framework controls how instructions are loaded and which tools are available. The host controls credentials and operating-system permissions. The registry controls discovery and publisher signals. The user controls installation, but their decision is only informed if the earlier layers disclose the relevant behavior. Security therefore cannot be delegated entirely to the last person who clicks install.
When instructions become part of execution
Traditional software security usually draws a line between code and documentation. Code executes; documentation describes what code does. Agent skills weaken that separation because the documentation is addressed to an agent that follows instructions. A sentence in a skill file may not be executable by the operating system, yet it can affect which tool the agent invokes, what information it reveals, and whether it pauses for user confirmation.
This is why the risk is not adequately described as “malware hidden in a script.” OWASP’s guidance on malicious skills identifies a code layer and a natural-language instruction layer. The first includes familiar concerns such as credential theft, remote execution, and backdoors. The second includes hidden directives, social engineering, and attempts to override the agent’s normal constraints. To a human reviewer, the prose may look like setup guidance or workflow advice. To the agent, it may be an additional policy competing with the user’s request and the host framework’s safeguards.
The resulting trust boundary has several parties. A publisher controls the artifact and the claims made about it. A registry controls how that artifact is indexed, identified, and presented to people searching for a capability. An installer or platform decides what is admitted into the local environment. The agent interprets the persistent instructions. The host runtime supplies permissions and exposes files, credentials, network access, and tools. If any one of these relationships is treated as implicit, the package can acquire more authority than its public description suggests.
That is also why familiar surface cues are weak. A benign name does not establish benign behavior. A short description does not tell the reader how a helper behaves or how the agent will interpret an instruction. Conversely, a suspicious-looking operation is not automatically malicious: a security diagnostic or credential manager may legitimately access sensitive resources. The meaningful question is whether the observed behavior fits the function presented to the user, and whether the package’s effects were authorized in context.
The subject here is consequently larger than a file and smaller than “AI safety” in general. It is the relationship between an agent skill’s public contract and the authority it receives after installation. Once that relationship is visible, the central questions become concrete: How many skills in a real public snapshot cross the line into intentional abuse? Which behaviors travel together? Do attackers seek the user’s data, the agent’s decisions, or both? And what kind of review can see the difference?
A measured problem, not a universal percentage
The strongest available empirical answer comes from a USENIX Security 2026 study that collected 98,380 skills from two community registries in January 2026. The sample covered public, indexed material from 11,246 repositories. It did not include private or unindexed repositories, direct enterprise sharing, MCP servers, or official platform-curated collections. Those exclusions do not make the snapshot unimportant; they define what it can support. It is a large view of a public ecosystem at a particular moment, not a census of every way an agent skill can reach a user.
The study’s central discipline is equally important. It did not call every suspicious pattern malicious. Static analysis first narrowed the collection to candidates. Runtime verification then looked for observable effects, and researchers manually reviewed the behavior against the skill’s stated functionality. The final set contained 157 behaviorally confirmed malicious skills and 632 labeled vulnerabilities. After responsible disclosure, registries removed or de-indexed all 157 reported cases. Those results make the threat concrete while preserving a boundary around the claim: a confirmed case is stronger evidence than a pattern match, but a confirmed set found by a time-limited process is not proof that no other cases exist.
The stages answer different questions. Static analysis asks whether a skill resembles a known risky pattern; it is efficient, but it cannot tell whether a network call is an authorized feature, a test fixture, or covert transmission. Runtime verification asks what actually happens under selected invocations and monitored conditions. Manual review then asks whether that behavior is intentional abuse and inconsistent with the public function. Treating these stages as interchangeable would either produce a noisy list that users cannot act on or miss behavior that is invisible in a quick reading of the files.
The paper also points to why the boundary deserves attention. Malicious skills averaged 4.03 vulnerabilities and typically crossed several attack phases, while most labeled vulnerability instances were located in the natural-language skill document rather than in executable scripts. That does not mean every instruction file is dangerous. It means the ordinary division of labor between code scanning and document reading is no longer enough for this type of package. It also means a future defense has to compare the skill’s declared contract with its observed effects, not simply assign trust based on a name, a registry badge, or the absence of an obvious script.
The result is a useful but deliberately incomplete picture. It establishes that malicious skills were present at scale in the sampled public ecosystem and that maintainers could act on the findings. It does not establish how common the problem is in private deployments, how many dormant triggers escaped a short test, or whether a particular control would stop every attack. Keeping those distinctions visible is part of understanding the supply chain, because false certainty would recreate the same trust failure the study is trying to expose.
The rest of this series follows that tension. It will first trace what happens when a skill moves from a registry listing into an agent and local runtime. It will then examine how the study separates suspicion from confirmation, how one installed skill can form a multi-phase attack chain, and why the evidence points to two different strategic patterns: data theft and agent hijacking. Finally, it will look at concealment, platform-native trust failures, and the layered controls needed to restore a meaningful distinction between what a skill says it will do and what it is permitted to make happen.
That distinction is the starting point. A skill is not unsafe merely because it is third-party, and it is not safe merely because a user can find it in a registry. The decisive question is whether the ecosystem can make the path from publisher claim to agent behavior observable, constrained, and accountable. The next step is to follow that path one transition at a time.