At peak infection, five of the seven most-downloaded skills on the ClawHub registry were confirmed malware. Not flagged for review. Confirmed. That number is why OWASP put the Agentic Skills Top 10 (AST10) out for public review, and it is why your current install flow, which is probably "the agent suggested it, so I added it," needs to change this week.
A Skill Is Not a Prompt. It Is a Workflow With Your Credentials.
Most developers I talk to still file skills under "prompt snippets." Wrong category. A skill encodes task understanding, multi-step planning, and tool orchestration. It can carry file system, network, and shell access, its own guardrails, and persistent memory across sessions. When you install one, you are handing a stranger's workflow logic the keys your agent already holds.
OWASP's mental model is the cleanest one-liner in the project: "MCP = how the model talks to tools; AST10 = what those tools actually do." MCP tools define which actions exist. Skills define how to chain those actions to accomplish a goal, and the security failure lives in the chaining.
Packaging tells you the risk. OpenClaw uses SKILL.md with YAML frontmatter. Claude Code uses skill.json. Cursor and Codex use manifest.json. VS Code uses package.json, which means on VS Code a skill is literally an npm-style package, with everything that implies about install-time execution.
First, Which Top 10 Is This?
There is real confusion here, and the search results are not helping. AST10 is not the OWASP Agentic AI Top 10, and it is not the LLM Top 10. It extends LLM03 (supply chain) into the skills layer, it specializes the tool layer sitting beneath the Agentic Top 10, and it complements the MCP Top 10: the MCP list covers protocol security, AST10 covers what skill content instructs agents to do. It maps to ASVS v5 verification requirements and SAMM v3 maturity practices, and the repo aligns it with MAESTRO, the Cloud Security Alliance's 7-layer agentic threat model. It also cross-references the MCP list directly: AST01 maps to MCP03 Tool Poisoning, AST02 to MCP04 Supply Chain Attacks, AST03 to MCP02 Scope Creep, AST10 to MCP09 Shadow Servers.
If a colleague sends you a link about "the agentic top ten," check which document they mean before arguing about rankings.
The Ten Risks in Plain Language
Direct attacks
AST01, Malicious Skills. The skill itself is the payload. Antiy CERT attributes 1,184 malicious skills to the ClawHavoc campaign alone (February 2026). OWASP's paired mitigation is Merkle root signing, so integrity can be checked against a tamper-evident root. My take: signing only protects you if someone enforces it. Until your registry requires signatures and your client verifies them, treat every unsigned skill as hostile by default.
AST02, Supply Chain. The skill looks clean. Its dependencies, distribution path, or publisher account are not. Snyk's ToxicSkills research scanned 3,984 skills and found 1,467 (36.82%) with security flaws, 534 (13.4%) with critical issues, and more than 76 confirmed malicious payloads, plus over 280 "leaky skills" in related supply chain findings. Mitigation: registry transparency. Useful, but transparency logs mostly tell you what happened after it happened. Pin and hash your artifacts.
AST05, Prompt Injection. Skill instructions sit in the model's context, and any skill that reads email, tickets, web pages, or memory files is feeding attacker-controlled text straight into the planner. Mitigation: prompt sanitization. Honest assessment: this is the weakest mitigation on the list, because nobody has a sanitizer that reliably works. You cannot filter your way out, so control capability instead. A skill that ingests untrusted content should not also hold network egress.
Amplifiers
AST03, Over-Privileged. Skills routinely request more file, network, and shell access than the task needs. Mitigation: schema validation, meaning machine-checkable permission manifests a linter can reject. This is where the Lethal Trifecta (attributed to Simon Willison and Palo Alto Networks, 2026) earns its name: access to private data (SSH keys, API credentials, wallet files, browser data), exposure to untrusted content (skill instructions, memory files, email), and the ability to communicate externally (network egress, webhooks, curl). A skill holding all three is an exfiltration channel waiting for instructions.
AST04, Insecure Metadata. The manifest is content too. Descriptions, permission fields, and memory files can misstate what a skill does or smuggle instructions past a code review. Mitigation: static analysis applied to metadata, not only to scripts. Read the YAML frontmatter with the same suspicion you would give a shell script.
AST06, Weak Isolation. Skills run with the agent's ambient authority. Check Point Research disclosed two Claude Code vulnerabilities, CVE-2025-59536 (CVSS 8.7) and CVE-2026-21852 (CVSS 5.3), where cloning and opening an untrusted repository triggered remote code execution and API key theft before any consent dialog appeared. Read that again: before consent. Mitigation: containerization. If a skill runs anywhere near production credentials, it runs in a sandbox.
Slow failures
AST07, Update Drift. You reviewed version 1.4.2. The updater pulled 1.4.5 last night, and 1.4.5 does something new. Mitigation: immutable pinning. This is the cheapest control in the entire list and the one almost nobody does.
AST08, Poor Scanning. A single scanner is a single point of failure. Snyk pulled 76-plus confirmed malicious payloads out of an ecosystem that already had scanning. ClawHub now runs automated scanning and partnered with VirusTotal, but that happened after five of its top seven downloads were malware. Mitigation: a multi-tool pipeline. Scan locally even when the registry scans.
AST09, No Governance. Ask your team right now: which skills are installed, on which agents, approved by whom? If nobody can answer, you cannot scope an incident. Mitigation: skill inventories, plus the approval workflows and audit logging in OWASP's checklist. An inventory is not bureaucracy. It is the difference between a bad afternoon and a bad quarter.
AST10, Cross-Platform Reuse. A skill vetted on one platform gets ported to another where permissions, isolation, and packaging mean different things. Assumptions baked into a SKILL.md do not survive translation into package.json. Mitigation: the Universal Skill Format, which is also the most practically useful part of the draft.
The Universal Skill Format vs. What You Install Today
The proposed Universal Skill Format is a YAML standard with fields for name, platforms, version, description, permissions (explicit file read and write paths, network on or off), required binaries, a risk_tier from L0 (safe) through L3 (destructive), and an ed25519 signature. How those fields line up against the four manifests you already deal with:
| USF field | Where it lives today |
|---|---|
| name, version, description | Present in all four formats; version is the field your pinning depends on |
| platforms | Inferred from which registry you found the skill in |
| permissions | The real gap. Most formats imply access through requested tools rather than declaring explicit paths and network state |
| required binaries | Declared for dependencies in package.json; elsewhere you discover them at runtime |
| risk_tier (L0 to L3) | Nothing like it exists. This is your triage shortcut |
| ed25519 signature | Mostly absent. ClawHub's post-poisoning answer was scanning plus VirusTotal, which is detection, not provenance |
Two fields carry the load. The permissions block turns review from reading tea leaves into checking a contract, and risk_tier lets you route L0 and L1 skills through automated checks while forcing L2 and L3 into human review. The signature is the right endgame, but a signature no client verifies is decoration. Do not wait for registries to mandate the format. Use its fields as your internal vetting template now.
A Pre-Production Vetting Pipeline You Can Run This Week
OWASP's checklist is solid but committee-shaped: four pillars (Registry & Installation, Runtime Security, Governance & Monitoring, Development Practices) with no opinion about order of operations. Here is the order, tuned for a team that ships.
1. Verify the publisher, not just the skill
Install only from verified publishers with code signing where the registry supports it. Check the publisher's history and other artifacts. A clean-looking skill from a two-day-old account with one upload is a no. (Addresses AST01, AST02.)
2. Read the permission manifest before the code
Decision rules you can apply in minutes:
- Network access for a skill whose job is local (formatting, linting, templates): reject.
- Write access outside a designated workspace directory: reject.
- All three Lethal Trifecta capabilities in one skill: block by default, require written justification to override.
- No permission manifest at all: that absence is a finding, not a feature.
(Addresses AST03 and AST04, and cuts most AST05 exposure.)
3. Pin versions and hash artifacts
Immutable pinning, in practice, means a lockfile committed next to your agent config, and auto-update turned off for skills. Any version change triggers re-review.
# skills.lock.yml
- name: pdf-report-builder
version: 1.4.2
sha256: 9f2c44a1... # hash of the exact artifact you vetted
publisher: verified:acme-tools
permissions:
file_read: ["./workspace"]
file_write: ["./workspace/reports"]
network: false
risk_tier: L1
reviewed_by: j.doe
review_date: 2026-02-18(Addresses AST07, reinforces AST02.)
4. Sandbox-test every new or updated skill
Run the skill in a container with no network, a read-only root filesystem, fixture data, and zero host credentials. Watch for egress attempts and file reads outside declared paths. Promote only after a clean run.
docker run --rm \
--network none \
--read-only \
-v ./fixtures:/work \
--memory 1g --cpus 1 \
skill-test-harness ./run-skill.sh pdf-report-builderThen run it again with network enabled but egress filtered to an allowlist, because some skills only misbehave when they can phone home. (Addresses AST06, catches AST01 and AST05 behaviorally.)
5. Enforce signatures where you can, allowlist where you cannot
Where a platform supports ed25519-signed skills, verify against a pinned publisher keyring and fail closed. Where it does not, compensate with an explicit allowlist drawn from your skill inventory, audit logging on skill invocation, and monitoring for drift. Scan with more than one tool before anything reaches the sandbox, because AST08 exists precisely for teams that trusted a single scanner. (Addresses AST01, AST08, AST09, AST10.)
None of this needs new budget. It needs an afternoon and a policy that survives the next "the agent suggested a skill" moment.
"It Is Only a v1 Draft" and Other Reasons to Do Nothing
Fair pushback: AST10 is a volunteer effort, roughly 250 hours and zero budget, led by Ken Huang (OWASP AIVSS Lead), with platform maintainer reviewers still marked TBD and an adoption target measured in conference talks (RSA, OWASP Global AppSec). All true. Also irrelevant to the underlying evidence, which comes from Snyk, Antiy CERT, Check Point, SecurityScorecard, and Endor Labs rather than from the committee. Analysis of more than 30,000 skills across registries (National CIO Review/Cisco, 2026) found over 25% carrying at least one vulnerability. SecurityScorecard counts 135,000-plus internet-exposed OpenClaw instances. Endor Labs tracks nine OpenClaw CVEs, three with public exploits, and Oasis Security added a WebSocket hijacking issue (CVE-2026-28363) in February 2026. Consent dialogs will not save you either, because the Claude Code vulnerabilities fired before one appeared.
OWASP's own framing opens with "This is not a theoretical future risk," and for once the marketing undersells it. The draft being v1 is a reason to file comments in the public review, not a reason to wait for v2 while your agents run unreviewed code.
Key takeaways
- Treat every skill as unreviewed third-party code. On VS Code it literally ships as package.json.
- Five of ClawHub's top seven downloads were malware at peak infection, in a registry developers trusted. Registry scanning arrived after the damage.
- Block the Lethal Trifecta by default: private data access plus untrusted content ingestion plus external egress in one skill is an exfiltration channel.
- Pin versions and hash artifacts. Cheapest control on the list, and it kills update drift outright.
- Adopt the Universal Skill Format's fields as your vetting template now, verify signatures where platforms allow, and fail closed everywhere else.
