The New OWASP Top 10 for AI Agent Skills

The OWASP Agentic Skills Top 10 v1.0 landed Aug 17, 2026. What the ten SKILL.md risks mean for your Claude Code and Cursor setup.

OWASP now has a Top 10 for the skill files your coding agent loads. On August 17, 2026, project leader Ken Huang announced version 1.0 of the OWASP Agentic Skills Top 10, a ranked list of the ten most critical security risks in the packaged instruction bundles that agents like Claude Code and Cursor read and execute. If your repository has a SKILL.md, a .cursor/rules, or any folder an agent auto-loads to change its behavior, this list describes the attack surface you already have.

Sources: FOR IMMEDIATE RELEASE: OWASP Publishes Agentic Skills Top 10 v1.0 (Ken Huang)

One accuracy note before the details: the sourcing is split. Ken Huang, the project lead, published the v1.0 release the week after Black Hat USA and DEF CON 2026. The OWASP project page itself still carries earlier wording: it still labels the project a "New Project Proposal" with the v1.0 release targeted for later in 2026, and it is stamped "Last updated: March 2026." So the honest framing is this: OWASP's project leader has published a v1.0 of the standard, while the OWASP project page has not yet been updated to match. The ten categories below are identical across both, so the content is stable even if the label is in flux.

Sources: OWASP Agentic Skills Top 10 project page

A disclosure up front, because this post argues for process discipline and that points somewhere commercial. We build TLM Forge, a review-and-governance layer for AI coding. Three of these ten risks map directly to what that layer does, and the last section says so plainly. Read the framework summary as the load-bearing part, and read the product section knowing where it comes from.

What the Agentic Skills Top 10 actually covers

A skill is a folder an agent loads on demand to do a task better: a SKILL.md with instructions, plus optional scripts and resources. Anthropic shipped the format for Claude Code and Claude.ai in October 2025 and later published it as an open specification, and the pattern spread fast across Cursor rules, agent frameworks, and shared registries. The security problem is structural: a skill is executable behavior that an agent reads as trusted context, yet it is distributed like a README, with far less scrutiny than code that goes through review. The Agentic Skills Top 10 names the ten places that gap turns into a vulnerability.

Sources: Introducing Agent Skills (Anthropic)

• AST01 Malicious Skills: a skill package built to compromise the system that installs it.
• AST02 Supply Chain Compromise: a legitimate skill's distribution path or dependency is tampered with upstream.
• AST03 Over-Privileged Skills: a skill granted permissions and reach far beyond what its function needs.
• AST04 Insecure Metadata: name, description, and manifest fields that can be spoofed or abused to mislead the agent or the user.
• AST05 Untrusted External Instructions: a skill that pulls in and executes directions from unverified external sources without validation.
• AST06 Weak Isolation: skills that run without a sandbox, free to touch the host, the filesystem, and the network.
• AST07 Update Drift: a vetted skill silently changing behavior on a later version you never re-reviewed.
• AST08 Poor Scanning: no automated inspection of skills for known-bad patterns before or after they load.
• AST09 No Governance: no policy for which skills an agent is allowed to load, who approved them, or how they are monitored.
• AST10 Cross-Platform Reuse: a skill moving between platforms and shedding its provenance and controls on the way.

The framing that makes this list distinct is where skills sit. A lot of security attention went to the model layer, covered by the OWASP Top 10 for LLM Applications, and to the tool layer, covered by the MCP Top 10. Skills are the behavior layer in between: the instructions that decide how an agent uses those tools on your machine. The new list maps each of its entries back to those neighboring frameworks, plus OWASP AISVS, ISO/IEC 42001, and the NIST AI Risk Management Framework, so it slots into an existing program rather than starting a new one.

Sources: OWASP Agentic Skills Top 10 v1.0 announcement (Ken Huang)

The measured problem the list responds to

This is not a hypothetical threat model written ahead of the attacks. A study presented at USENIX Security 2026, titled "Do Not Mention This to the User": Detecting and Understanding Malicious Agent Skills in the Wild, analyzed 98,380 skills across two major registries and confirmed 157 of them malicious, carrying 632 distinct vulnerabilities across 13 attack techniques. The researchers describe two dominant attack strategies: credential theft through remote code execution, and agent manipulation through adversarial instructions hidden in the skill's documentation, behavior absent from the skill's public description. The title itself is a line lifted from a malicious skill instructing the agent to hide its actions.

Sources: "Do Not Mention This to the User": Detecting and Understanding Malicious Agent Skills in the Wild (arXiv)

That last detail is the load-bearing one for anyone using SKILL.md in production. The dangerous skills did not look dangerous in their metadata. The malicious instruction lived in the body, phrased to the agent, telling it to do something and not surface it. A human skimming the description would approve it. This is why AST04 (insecure metadata) and AST08 (poor scanning) sit on the list together: the field you read is not the field that runs.

Three risks that land on your coding setup

Most of the ten matter to platform and registry owners. Three of them land squarely on the individual engineer or team running Claude Code, Cursor, or a coding agent day to day, because they describe what happens inside your own repository and workflow. These are AST05, AST03, and AST09.

AST05: untrusted external instructions

A skill that fetches and follows text from an external source is a prompt-injection channel with a folder around it. The moment a skill reads a URL, an issue comment, a scraped page, or a file the agent did not write, that content can carry instructions the agent then executes with your credentials. This is the same failure that already bites tool-using agents, now packaged and reusable. The defense is to treat everything a skill ingests at runtime as untrusted data, never as instructions, and to review what a skill loads before you let it run. TLM's work on prompt injection in AI-generated code covers how that boundary breaks and how to draw it.

AST03: over-privileged skills

A skill inherits whatever your agent can do: your shell, your tokens, your cloud credentials, your ability to push. Most skills need a fraction of that. AST03 is the gap between what a skill is granted and what it needs, and it is the difference between a compromised skill leaking one file and a compromised skill exfiltrating a repository. The fix is least privilege applied to skills the same way you apply it to service accounts: scope what each skill can reach, and refuse to run one that asks for the whole machine to do a small job. Guardrails for AI-generated code makes the same argument for the agent's own reach.

AST09: no governance

AST09 is the one most teams fail silently, because there is nothing to see. It is the absence of any policy for which skills an agent may load, who approved them, and how a change gets caught. Skills get copied from a gist, dropped into a repo, and loaded automatically, with no record of who read the body or when. Governance here is not bureaucracy: it is a short, enforceable answer to "what is this agent allowed to load, and who signed off." An enforceable AI coding policy is where that answer lives.

A governance checklist for skills

The list is easier to act on as a checklist than as a taxonomy. Run any skill your agents load against these questions before it becomes part of the workflow, and keep the answers somewhere durable so the next person does not repeat the review from zero.

• Provenance: where did this skill come from, and who added it to the repository? (AST02, AST10)
• Body read: has a human read the full instruction body, beyond the name and description? (AST04)
• External fetch: does it pull and execute anything from an external source at runtime? (AST05)
• Privilege: what can it reach, and is that the minimum the task requires? (AST03)
• Isolation: does it run sandboxed, or with full access to the host, filesystem, and network? (AST06)
• Version pin: is the version pinned, and is there a re-review step on update? (AST07)
• Scanning: is there any automated check for known-bad patterns before it loads? (AST08)
• Approval record: is there a written answer to who approved this skill and when? (AST09)

The proposal accompanying the list goes one step further with a Universal Skill Format manifest, so a skill can move between platforms without shedding its provenance and controls in transit, which is the AST10 problem stated as a fix. Whether or not that format lands, the checklist above works today against whatever skills your agents already load.

Sources: OWASP Agentic Skills Top 10 v1.0 announcement (Ken Huang)

Three of these checks are exactly the discipline TLM Forge exists to enforce. Reviewing what a skill loads and instructs, before code runs, is the AST05 case: a spec audit reads the instruction body as data to be checked, not context to be trusted. Keeping an agent scoped to the minimum reach is the AST03 case. And an approval record that a human signed is the AST09 case, which is where an enforceable AI coding policy and an adversarial convergence gate turn "we should review skills" into a step that blocks a merge until it happens. The one durable piece is memory: a private, persistent memory layer keeps the record of which skills were approved and why, so the review survives the session that did it.

A Top 10 is a starting map, not a verdict on any specific skill, and most skills people use are benign and useful. The claim is narrower: skills are now a real, measured attack surface with a named framework behind them, and the three risks that reach into your own repository (untrusted instructions, over-privilege, and no governance) are handled by the same review discipline you already need for AI-written code. Extend that discipline past what the agent writes to what the agent loads.