Building a Trustworthy Skill Ecosystem

The subject is the public ecosystem of third-party agent skills, and the final question is what it would mean to trust one without confusing discoverability, authorship, or removal with safety. The evidence points to a layered answer. A skill can carry executable code, natural-language instructions, and platform-specific authority at once; therefore a trustworthy ecosystem must make each boundary visible, test behavior against the public contract, limit what the runtime can reach, and preserve a way to respond when the evidence changes. This conclusion joins the measured threat landscape to decisions that publishers, registries, framework vendors, users, and standards bodies can actually own.

Trust is a chain of claims

The central finding is not simply that malicious skills exist. It is that the ordinary meaning of “extension” is insufficient for this subject. A third-party skill is distributed through a registry like a software component, read by an agent like an instruction source, and executed in a local environment like a privileged tool. Those are three relationships in one package. A safety claim is credible only when it explains all three.

That is why the two major attack strategies matter. Data Thieves use the local execution and collection path to obtain sensitive information and send it through external infrastructure. Agent Hijackers use the instruction path to change what the agent does, what it reveals, or whether it asks the user for consent. The strategies share a distribution boundary but leave different evidence. The first is more visible in code, file, credential, network, and cross-skill patterns. The second is more visible in the relationship between a skill’s prose and the agent’s decisions.

Neither strategy is the whole ecosystem. The study also reports a small group of platform-native cases involving model routing, permission bypass, MCP configuration, hooks, and dormant triggers. These cases matter because they move the boundary outward. A package can be reviewed as a file and still exploit a trust mechanism supplied by the host framework. The relevant object of assurance is consequently not just the repository contents; it is the package in the environment where the agent interprets and runs it.

The hidden-contract idea provides the unifying test. Ask whether the capability a user is shown matches the capability the agent receives and the behavior the runtime observes. A mismatch can be a missing permission disclosure, an undocumented network destination, a coercive instruction, a conditional action, a changed identity artifact, or a helper that performs a function unrelated to the advertised task. These mismatches differ in severity, but they all weaken the user’s ability to make an informed installation decision.

The empirical results show why this is a supply-chain issue rather than a speculative design concern. In the USENIX study’s January 2026 public snapshot, 98,380 skills were collected from two community registries. Static analysis reduced that population to 4,287 candidates; runtime indicators narrowed it to 762; behavioral review confirmed 157 malicious skills containing 632 labeled vulnerability instances. The confirmed set was high precision, but it was also a lower bound because the test window and population were limited. The numbers establish observed abuse and a repeatable measurement path, not a universal prevalence rate.

The distribution of the labeled instances sharpens the conclusion. Most were in natural-language skill documents rather than executable scripts. That does not make prose inherently malicious. It means that a review process designed around executable code alone is structurally blind to the layer the agent actually reads as guidance. The same system that makes skills easy to compose also makes their documentation part of the control plane.