Agent Skill Supply Chain: What 26% Vulnerable AI Agent Skills Reveal About Deployment Risk
A study of 31,132 agent skills found 26.1% carried at least one security vulnerability. What the distribution says about where agent deployment risk actually sits.
By Institute for Joint Cognition & AI · 6 min · 7 August 2026

Agent skills — packaged instructions and scripts that tell an agent how to use a tool, an API, or a system resource — became a distribution format faster than they became a governed one. They are installed from marketplaces, they execute with the agent’s privileges, and until recently nobody had measured what was in them at scale.
Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale (Liu et al., January 2026) collected 42,447 skills from two major marketplaces and analyzed 31,132 of them. 26.1% contained at least one security vulnerability. The vulnerabilities spanned 14 distinct patterns across four categories: prompt injection, data exfiltration, privilege escalation, and supply chain risk.
The aggregate number is the headline. The distribution is the useful part.
Where the vulnerabilities cluster
Two categories dominate:
- Data exfiltration — 13.3%
- Privilege escalation — 11.8%
- High-severity patterns strongly suggesting malicious intent — 5.2%
That ordering deserves attention because it inverts the common threat model. Most agent security discussion centers on prompt injection — an attacker manipulating an agent through untrusted input at runtime. But the two largest categories here are not about manipulating the agent at all. They are about what the skill was written to do in the first place: move data somewhere it should not go, or acquire capability it was not granted.
Prompt injection is a runtime problem you defend with input handling and isolation. Exfiltration and privilege escalation in an installed skill are supply chain problems you defend by controlling what gets installed. Those are different controls, owned by different teams, and an organization that has invested only in the first has not addressed the larger share of what this study found.
The 5.2% high-severity figure is the one to sit with. Across 31,132 skills, that is over 1,600 packages whose patterns suggested intent rather than carelessness.
The strongest available signal: executable content
The most actionable finding is a single ratio. Skills that bundle executable scripts were 2.12x more likely to contain vulnerabilities than instruction-only skills.
This is the rare security finding that translates directly into policy, because it is observable before installation and requires no analysis of intent. A skill is either instruction-only or it ships code. That is a property you can check mechanically, at scale, in an admission gate.
It also explains something about why the problem exists. An instruction-only skill influences an agent’s behavior through text the model reads — bounded by whatever the agent is already permitted to do. A skill bundling scripts introduces a second execution path that runs outside the model’s reasoning entirely, with the agent’s process privileges, unmediated by any of the guardrails applied to model output. The 2.12x ratio is what that structural difference looks like empirically.
The detection framework the authors built, SkillScan, reported 86.7% precision and 82.5% recall across the 8,126 vulnerable skills used to develop the taxonomy. Those numbers are respectable for static analysis at this scale and also clarify the limit: roughly one in six vulnerable skills goes unflagged, and roughly one in seven flags is wrong. Automated screening is a filter, not a gate.
Why this ecosystem produced these numbers
Agent skill distribution recapitulates the early history of every package ecosystem — npm, PyPI, browser extensions, VS Code marketplace — with two properties that make it sharper.
The trust boundary is invisible at the point of use. Installing a Python package is understood as running someone else’s code. Installing a “skill” reads as configuration. The mental model users bring is closer to a settings file than a dependency, and the naming actively encourages that.
The execution context is unusually privileged. Skills are installed into agents that hold credentials, file system access, network access, and increasingly the ability to act on external systems. A malicious npm package in a build pipeline is bad; a malicious skill in an agent with production API tokens and shell access is a different order of exposure. The privilege escalation category matters more here than the same category would in a conventional package registry.
Review capacity has not scaled with publication. Marketplaces with tens of thousands of entries and low publication friction cannot manually review submissions, and the study’s numbers are what that looks like.
What this means for deployment
The findings support a small set of concrete controls.
Treat skill installation as dependency installation, with the same governance. That means a reviewed allowlist, pinned versions, a record of what is installed where, and a person who owns the decision. If your organization would not let an engineer add an arbitrary package to a production service without review, the same standard should apply here — the exposure is higher, not lower.
Separate instruction-only skills from script-bearing skills in policy. Given the 2.12x ratio, these deserve different review depth. Instruction-only skills can plausibly be reviewed by reading them. Script-bearing skills need the review you would give any third-party code running with your agent’s privileges.
Scope credentials to the task, not to the agent. Privilege escalation at 11.8% is only exploitable to the extent the agent holds privileges worth escalating to. Short-lived, narrowly scoped credentials issued per task limit what a compromised skill can reach — the same argument that applies to authorization propagation across multi-agent workflows.
Monitor egress. Data exfiltration at 13.3% is the largest single category, and it is detectable at the network layer regardless of which skill is responsible. An agent that suddenly contacts a new destination is a signal available to you even when static analysis missed the skill that caused it.
Re-scan after installation. Skills update. A skill reviewed at version 1.0 and auto-updated to 1.4 has not been reviewed. Pinning is what makes an initial review meaningful over time.
The measurement gap that remains
One limitation is worth stating plainly: the study measures skills as published, not skills as executed. A vulnerability pattern in a package is a capability, not an incident. It does not establish how often these skills are installed, by whom, or whether the vulnerable paths are ever reached in practice — a skill with a data exfiltration pattern that nobody installs is a different problem from one embedded in a widely used workflow.
What the numbers do establish is a base rate. When roughly a quarter of a distribution channel carries at least one vulnerability pattern and one in twenty shows signs of intent, unreviewed installation from that channel is not a defensible default. The interesting open question is the one this data cannot answer: what the download-weighted vulnerability rate looks like, and whether popularity correlates with scrutiny or merely with reach.