Table of contents
The skill layer is a dependency problem without a lockfile: what the OWASP Agentic Skills Top 10 gets right
OWASP published version 1.0 of the Agentic Skills Top 10 on August 17, defining ten risk classes for the layer where agents find, load, and run reusable instructions and code. This standard arrived while the problem was still forming, mapping directly to AISVS, the Agentic Security Initiative Top 10, the MCP Top 10, ISO/IEC 42001, and the NIST AI RMF. It ships with working code for signing, sandboxing, and pinning.
The evidence base is concrete. A USENIX Security 2026 study analyzed 98,380 skills across public marketplaces and confirmed 157 malicious skills carrying 632 vulnerabilities. In January, a single campaign pushed 1,184 malicious skills from 12 publisher accounts reporting to the same command-and-control address. Bitdefender counted over 135,000 internet-facing agent instances in February. Cisco found that 83 percent of organizations planned to deploy agentic capabilities, while only 29 percent felt ready to do so securely.
Review the ten risks, and the core issue is obvious: nine are supply chain problems the software industry has already solved at the package layer. Malicious publishers, typosquatting, dependency confusion, over-privilege, unsigned updates, drift, lack of inventory, and no revocation are issues we have seen before in npm and PyPI. We know what the answer looks like.
The part that transfers, and the part that does not
Most of the OWASP mitigation catalog aligns with standard AppSec programs. You sign the artifact, bind the signature to a revocable publisher identity, pin to content hashes instead of version ranges, scan the transitive tree, and keep an inventory mirrored into an internal allowlist with a clear revocation path. This is the package-ecosystem playbook applied to a new artifact type.
The new problem is narrower. A skill can direct an agent to read external documentation at runtime, consume that prose as instruction, and execute it with full permissions, a supply chain variant of indirect prompt injection. There is no lockfile for prose. The skill that passes review may not be the skill that runs because the author can alter the referenced document afterward or serve clean text to scanners while feeding different text to live agents. OWASP categorizes this as AST05, and it has the least existing tooling behind it. It is the agentic cousin of the risks cataloged in the 2025 OWASP Top 10 for LLM applications.
| Risk class | The control that already exists | What does not transfer |
|---|---|---|
| Malicious publishers, typosquatting | Signing, publisher identity, reputation | Prose payloads carry no code signature |
| Supply chain and dependency confusion | Hash pinning, transitive scanning, mirrors | Config files became execution paths |
| Over-privilege | Least privilege, scoped credentials | Permission checks fire at tool call, not intent |
| Update drift | Lockfiles, signed updates, freeze modes | Hot reload applies changes with no restart |
| External instructions | Nothing equivalent | No hash field, no lockfile, mutable by the author |
Why the answer is not another scanner
The OWASP document highlights severe shortcomings in the security industry’s scanning capabilities. Trail of Bits bypassed every scanner they tested. Padding a payload with a hundred thousand newlines caused one scanner to truncate the file and miss the content entirely. Logic hidden in compiled .pyc files and .docx archives went unscanned. An LLM-based judge rated a malicious registry redirect as benign when framed as corporate network configuration, and flagged a legitimate library shim as suspicious due to its comments. Three of the four malicious test skills took under an hour to build.
Their conclusion is that automated scanning cannot substitute for supply chain judgment. NVIDIA’s purpose-built skill scanner found vulnerabilities in roughly a quarter of the skills it examined, proving generic tools miss the majority of threats. On one marketplace, attackers distributed a malicious scanner as a skill to use as a false trust signal.
A checker that ships as a skill, runs under the agent’s permissions, and relies on the same class of model it protects shares the blind spots of its host. The auditor cannot be the author. This applies equally to models judging their own output and scanners living inside the runtime they police.
The repository is the control point
Registries are the wrong place to enforce security. Multiple marketplaces exist without shared vetting or threat intelligence, meaning a skill blocked on one can simply be published on another. The barrier to entry is minimal, and cross-registry arbitrage is an established pattern: attackers publish where scanning is light and leverage the resulting install count as a trust signal elsewhere.
Repositories are the correct control point. Skills arrive as files. Their metadata is YAML frontmatter, dependencies are declared in package.json and requirements.txt, and configurations live in files agents read at project open. These are files under version control within a system that already enforces review, approval, pinning, and audit trails. The enterprise does not need a new control plane; it needs its existing one to see these skills.
Five things worth doing this quarter
Establish strict inventory. Track name, version, content hash, installer identity, and last scan status. Reconcile identity and OAuth telemetry to capture skills installed inside managed SaaS copilots that evade endpoint scans.
Pin content hashes. Pin hashes rather than version ranges, and apply this across the entire transitive tree.
Secure agent identity and memory files. Treat these paths as protected persistence mechanisms, as writes to them survive uninstallation.
Snapshot external references. Allowlist hosts and record the resolved digest on every load, or snapshot external references into the reviewed artifact to prevent executing altered content.
Re-verify continuously. Scans are snapshots of mutable states. Install-time gates miss memory poisoning, drift, and altered references.
Our position at Mend.io
Mend has spent years building the necessary primitives for this problem, as part of our broader approach to AI application security. We provide dependency resolution across the transitive tree in more than 200 languages, malicious package detection, version pinning, and automated update governance in enterprise repositories through Renovate. We maintain an inventory of AI components through our AI-BOM and conduct continuous red teaming against models and agents, addressing the broader set of LLM security risks alongside the skill layer. The skill layer is simply a new artifact type sitting on infrastructure we already operate.
We do not claim full coverage of the ten risk classes today. Any vendor making that claim within a week of a v1.0 release is revealing their standards rather than their product capabilities. The necessary control point requires provenance that survives transport, pinning that secures referenced content, and inventory that security teams can query. That control point sits in the repository, which is exactly where Mend operates.
The industry must avoid relying on a new wave of skill scanners. They are cheap to evade and easy to weaponize. The agentic ecosystem requires what the package ecosystem eventually built: signed provenance, immutable pinning, real inventory, and independent verification.
Source base
OWASP Agentic Skills Top 10 v1.0 whitepaper and project repository
Increase visibility and control over the AI components in your applications
About the author
