OWASP Agentic Skills Top 10: What AST01–AST10 Actually Say

The OWASP Agentic Skills Top 10 (AST01 through AST10) is the first community framework to treat agent skills as what they have quietly become: a first-class attack surface. The OWASP Foundation published it in August 2026. Skills are reusable bundles of natural-language instructions, code, and resources that agents discover, load, and execute. The framework's core observation is that this moves risk into a new layer where prose instructions, executable helpers, dependencies, metadata, registry trust, and runtime permissions all meet, and none of the industry's existing tooling was built to look at that layer as a whole.

We read the full whitepaper. Here is what the ten entries actually say, the evidence behind them, and what a security team should do with it this quarter. The primary sources are the AST Top 10 whitepaper (PDF) and the OWASP project page.

The ten risks at a glance

The executive risk map groups AST01 through AST10 by where each risk lands in the ecosystem, which is a more useful way to read the list than the numbering. Short descriptors below; the whitepaper carries the full entry titles and control mappings.

Why skills needed their own Top 10

OWASP already maintains a Top 10 for LLM applications and one for MCP servers. The skills list exists because skills fail differently. A malicious npm package hides in code. A malicious skill can hide in either the code layer or the natural-language instruction layer, and the second one is where traditional tooling goes blind. Snyk demonstrated that three lines of markdown in a SKILL.md file were sufficient to exfiltrate SSH keys. No binary, no obfuscated payload, just prose an agent obediently followed. If you are working through both frameworks, we covered the protocol-side list separately in the OWASP MCP Top 10.

The barrier to entry explains the rest. At the time of the ClawHavoc campaign, publishing to a major skill marketplace required nothing more than a SKILL.md file and a one-week-old GitHub account. No code signing, no security review, no sandbox by default, and the skill inherits the host agent's full credential set the moment it runs. If the artifact type itself is new to you, we covered the basics in what an AI agent skill is, and why it is a supply chain risk.

Source and registry trust: AST01, AST02, AST04

This zone covers malicious skills, supply chain compromise, and insecure metadata. The evidence section is the most sobering part of the paper. The ClawHavoc campaign in January 2026 planted 1,184 malicious skills across 12 publisher accounts, all sharing a single C2 IP, delivering the Atomic Stealer to harvest macOS crypto wallets, SSH keys, and browser credentials.

At peak infection, five of the seven most-downloaded skills on ClawHub were confirmed malware. A USENIX 2026 measurement study of 98,380 skills found that 73.2% of confirmed-malicious skills implemented shadow features hidden from the user.

The metadata entry (AST04) is the one most teams overlook. A skill's name, description, declared permissions, and risk tier are the primary trust signals an installer relies on, and every one of them is attacker-controlled. ClawHub hosted skills named "Google Calendar Integration" and "Solana Wallet Tracker" with no affiliation to either brand, and Snyk documented instructions hidden via ASCII smuggling and base64 in SKILL.md, invisible to human reviewers. The hidden-capability pattern is the same one we wrote about in shadow features.

Execution boundary: AST03, AST05, AST06

Over-privileged skills, untrusted external instructions, and weak isolation share a root cause: skills execute in the host agent's security context. The paper's canonical example is a "weather assistant" that reads the agent's entire environment file, every API key, far beyond anything a weather lookup needs. The deeper problem is architectural: permission checks happen at the tool-call level, but skills layer natural-language intent on top of system permissions, so a skill permitted to run SELECT queries can be coerced by prompt injection into running DELETE.

AST05 deserves special attention because it defeats the review process itself. Skills routinely point agents at external documentation to read at runtime. That referenced content is mutable, lives outside the trust boundary, and can be rewritten by its author after the skill passes review, so the skill that was audited is never the skill that actually runs. On isolation, the numbers speak plainly: Bitdefender found more than 135,000 internet-facing agent deployments in February 2026, and Microsoft's guidance now says host-mode agent runtimes "should be treated as untrusted code execution with persistent credentials."

Lifecycle governance: AST07, AST08, AST09

Update drift, poor scanning, and no governance describe what happens after installation, which is where enterprise exposure actually accumulates. Skills get installed and forgotten, with no pinning, no advisory feed, and hot-reload mechanisms that make a compromised upstream repository instantly active.

The scanning entry is blunt about the state of the art. A regex scanner can detect curl in a shell script. It cannot detect a skill that tells the agent, in plain prose, to retrieve a file and send it to an address using the system's default HTTP client. Trail of Bits bypassed every scanner it tested in June 2026, three of its four malicious test skills took under an hour to build, and Snyk found that 13.4% of its ToxicSkills corpus contained critical issues that pattern matching mostly missed.

The paper's prescription is layered analysis that evaluates intent: combining calibrated models with deterministic rules, scanning both the code layer and the instruction layer independently, and re-scanning on a schedule rather than once at install. That is the same conclusion we reached building our own scanner, and we have written about why static analysis alone cannot catch malicious agent skills and the case for hybrid scanning. It is validating to see it codified as the recommended control.

AST09 is the entry to hand your CISO. Traditional software asset management has no concept of agent skills; installation is a one-line command with no CMDB entry, no approval workflow, and no revocation path. Cisco's State of AI Security survey found 83% of organizations planning to deploy agentic AI while only 29% felt ready to secure it. The recommended first control is unglamorous and correct: a centralized skill inventory recording name, version, hash, install date, installer identity, and last scan status. If that sounds like a bill of materials for AI artifacts, it is, and with the EU AI Act's Article 12 logging obligations beginning to apply from August 2026, an auditable inventory is becoming a compliance artifact rather than a nice-to-have.

Cross-platform reuse: AST10

The final entry covers what happens when skills move between runtimes, and it is the most forward-looking. A skill ported from one platform to another is often stripped of its permission manifest along the way, silently inheriting broader default access on the target. Snyk confirmed the same threat actors publishing identical malicious skills to multiple registries simultaneously, exploiting the fact that no two marketplaces share scanning intelligence. The paper proposes a Universal Skill Format so security properties survive translation; until something like it lands, every platform in your stack is a separate governance problem.

What the framework gets right

Three theses run through all ten entries, and they match what we see in the wild scanning skills, MCP servers, and agent configs every day.

First, the attack surface is language. The paper puts it memorably: the enemy of AI security is the infinite variability of language. Any control that only reads code is examining half the artifact.

Second, a scan is a snapshot, not a verdict. External references drift, updates arrive unsigned, and a skill approved under one backbone model can become exploitable under another. Point-in-time approval has to give way to continuous re-verification against pinned hashes.

Third, governance starts with visibility. Nearly every mitigation in the document, signature verification, permission manifests, revocation, approval workflows, presupposes that you know which skills exist in your environment. Most organizations today cannot answer that question. Start there.

Where to start this quarter

If the ten entries feel overwhelming, the paper's own decision tree suggests a sequence:

1. Inventory every skill across every agent runtime your teams use, including the ones on developer laptops.
2. Gate installation on a scan that reads instructions as well as code, and reject skills without a declared permission scope.
3. Pin what you approve to content hashes, not version ranges.
4. Treat metadata and externally referenced URLs as attack surface in their own right.
5. Re-scan on a schedule, because the artifact you approved is not guaranteed to be the artifact that runs tomorrow.

None of this requires waiting for the ecosystem to fix itself. The framework's value is that a security team, a marketplace, and a vendor can now point at the same risk and call it the same name. That shared vocabulary is how supply chain security matured for packages and containers. Skills just got theirs.

FAQ

What is the OWASP Agentic Skills Top 10? It is a community framework published by the OWASP Foundation in August 2026 that catalogues the ten most significant security risks in AI agent skills, numbered AST01 through AST10. It covers the SKILL.md form specifically: the instructions, code, and resources an agent loads into context.

Does the Agentic Skills Top 10 replace the MCP Top 10? No. MCP servers are separate processes exposing tools over a protocol and remain covered by the MCP Top 10. The AST list applies specifically to the skill form. The two lists cross-reference each other throughout.

Wouldn't code signing solve most of this? It helps with provenance, not safety. The paper is explicit that a signature proves authorship, and a verified publisher can still ship malicious content, so signing has to compose with behavioral scanning and reputation rather than replace them.

Why doesn't the framework rank the ten risks by severity? Deliberately. It cites AISVS controls for verification but withholds severity scoring until AIVSS v1 ships, expected by the end of 2026, to avoid anchoring the industry on unscored guesses.

Where can I read the original document? The full whitepaper is available as a PDF from the OWASP Agentic Skills Top 10 project page.