Key Insights
The Open Web Application Security Project (OWASP) Agentic Skills Top 10 (AST10) is OWASP's security framework for the files that tell artificial intelligence (AI) agents how to do things. A skill can look like documentation: a SKILL.md file of plain-language steps, perhaps a helper script, perhaps a link to an outside web page.
Once an agent loads it, those words turn into behavior, which the agent carries out with whatever file, shell, network, and credential access it already holds. Many organizations install skills from public registries with a click, and often nobody records who approved the install or which version arrived. Package ecosystems took years to build provenance checks; skill registries mostly have not caught up. This trust gap can turn an ordinary-looking instruction file into a consequential security decision.
This guide walks you through each of the ten AST10 entries by lifecycle stage, trace how sourcing, execution, governance, and portability weaknesses chain into real attack paths like typosquatted registry entries and the "lethal trifecta," and lay out a prioritized set of controls, from content-hash pinning and scoped credentials to behavioral monitoring and revocation. The result is a practical map of where skill risk actually lives and which countermeasures close the widest exposure first.
Key Takeaways
Skill risk builds in stages, from the moment a skill is discovered in a registry to the moment it is copied onto a different agent platform.
The ten entries interact, so a weakness in sourcing becomes far more damaging when execution boundaries and governance are also weak.
Containment controls such as isolation and scoped credentials deserve early priority because they reduce harm regardless of which entry an attacker exploits.
Existing supply-chain, least-privilege, and governance guidance applies to skills, but teams still need their own analysis of how each skill behaves.
What the OWASP Agentic Skills Top 10 Covers
The OWASP Agentic Skills Top 10 covers the skill layer of an AI agent: packaged instructions, code, and metadata that agents discover, load, and execute, plus the registries and update channels delivering them.
Agentic Skills as Executable Instruction Bundles
OWASP's Agentic Skills Top 10 whitepaper defines skills as "reusable bundles of progressive instructions, code, resources, and operational know-how that agents can discover, load, and execute." In practice, a skill is a folder built around a SKILL.md file holding that metadata, the agent's natural-language steps, and pointers to bundled scripts.
That bundling is why skills earned their own list: a single skill combines instructions, code, and metadata, three things a scanner and a reviewer normally inspect separately, so neither evaluates what the prose tells the agent to do.
The Boundary Between Skills, Tools, Protocols, and Agents
OWASP distinguishes skills from neighbors by function and location: a tool is one callable function, an MCP server runs separately under the MCP Top 10, and a plugin may bundle all three, with AST01 through AST10 applying only to the skills inside it.
MCP tools define what capabilities are available. Meanwhile, skills define how to sequence them, and protocol, model, scanner, and non-agentic-plugin risks all sit outside AST10's scope.
AST10's Scope, Edition, and Maturity Caveats
AST10 remains a developing framework, so readers should treat its release and severity labels as provisional. OWASP's project page lists it as Version 1.0-2026, an Incubator Project in the Documentation category, and Ken Huang leads the project as well as OWASP's AI Vulnerability Scoring System (AIVSS). Release status is less settled than the version label suggests, though: no OWASP-hosted page gives an official publication date, the project site still shows a roadmap with a release candidate and later full release, and some OWASP pages display a placeholder version.
Severity is split too: the whitepaper withholds ratings until AIVSS is available, while the website's overview uses Critical, High, and Medium labels. Reading the list by lifecycle stage avoids treating ID numbers as a ranking OWASP has not formally issued.
How Agentic Skill Risk Moves Through the Lifecycle
Agentic skill risk accumulates in four stages, and each handoff grants the skill more trust than the one before it.
Sourcing and registry trust decide whether an untrusted skill crosses in at all, usually on nothing more than a publisher-controlled name and popularity count. Execution boundaries then set its permissions and blast radius, since most platforms hand a loaded skill the same access the agent itself holds. Governance decides whether anyone notices a version or ownership change months later. Cross-platform reuse can strip away protections that existed only in the original platform's permission model. Each stage gets fuller treatment in the table and entry breakdown below.
The OWASP Agentic Skills Top 10 Risks by Lifecycle Stage
The ten OWASP entries map to four lifecycle stages, each with a recognizable mechanism and a detection signal. The table follows the whitepaper's grouping; the signals are editorial suggestions drawn from each entry's mechanism.
ID and Risk | Lifecycle Stage | How It Happens | Detection Signal |
|---|---|---|---|
AST01 Malicious Skills | Sourcing | A legitimate-looking skill hides credential stealers, reverse shells, backdoors, or manipulative instructions in its prose | Reads of credential stores or outbound connections the skill's purpose does not explain |
AST02 Supply Chain Compromise | Sourcing | Registries and distribution channels lack provenance controls, and config files act as execution paths | A publisher or content hash that differs from the recorded install |
AST04 Insecure Metadata | Sourcing | The loader trusts fields that impersonate brands, understate permissions, or misdeclare risk tiers | Declared permissions narrower than observed behavior |
AST03 Over-Privileged Skills | Execution | Permissions exceed what the stated function requires | Granted scopes that normal runs never use |
AST05 Untrusted External Instructions | Execution | The agent reads mutable external documents at runtime | Fetches from domains outside an allowlist, or referenced content that changes between runs |
AST06 Weak Isolation | Execution | The skill shares the host agent's file, shell, and network access | Shell commands or file writes outside the task's workspace |
AST07 Update Drift | Governance | Unpinned skills drift or auto-update to malicious versions | A version or hash change with no approval record |
AST08 Poor Scanning | Governance | Hybrid prose, code, and metadata evade pattern matching | A clean scan followed by suspicious runtime behavior |
AST09 No Governance | Governance | No inventory, approval, audit trail, or revocation | Skills found on endpoints that are missing from inventory |
AST10 Cross-Platform Reuse | Reuse | Translation between formats removes security properties | One skill carrying different declared permissions on different platforms |
AST01, AST02, and AST04: Malicious Skills, Supply Chain Compromise, and Insecure Metadata
Sourcing controls fail when malicious payloads, weak provenance, and deceptive metadata combine:
AST01 Malicious Skills: The payload: credential stealers, reverse shells, backdoors, or social-engineering prose, running with the agent's full permissions. The ClawHavoc campaign compromised more than 1,184 agent skills to deliver infostealers.
AST02 Supply Chain Compromise: Weak provenance lets attackers publish freely; a poisoned config file can trigger code with no installer.
AST04 Insecure Metadata: Metadata is an "attacker-controlled input the loader reads with little or no validation," so unsafe deserialization can fire a payload once it's parsed.
Detection depends on comparing what a skill claims with what it does.
AST03, AST05, and AST06: Over-Privileged Skills, Untrusted External Instructions, and Weak Isolation
An academic agent skills study found 26.1% of skills analyzed had at least one vulnerability. These three entries create a connected path:
AST03 Over-Privileged Skills: Skills granted "broader permissions than their stated function requires," reaching files and systems the task doesn't need.
AST05 Untrusted External Instructions: A skill referencing external documentation hands part of its behavior to content the reviewer never saw, which is how review on Monday can become attacker instructions by Friday.
AST06 Weak Isolation: A skill sharing the agent's security context can touch anything the agent can, letting untrusted instructions and excessive permissions meet inside one process.
Together, over-privilege supplies access, external instructions supply intent, and weak isolation lets them meet; scoped credentials and isolation address all three.
AST07, AST08, and AST09: Update Drift, Poor Scanning, and No Governance
A sound day-one decision decays after installation, as trust in a skill outlasts its original contents:
AST07 Update Drift: Unpinned references or auto-updates move skills off known-good versions, as a disclosed coding-agent flaw showed, swapping a trusted configuration "without triggering any warning or re-prompt."
AST08 Poor Scanning: Scanners built for code alone miss the hybrid of prose, code, and metadata a skill actually is, so malicious prose looks harmless, and false flags on legitimate skills train reviewers to ignore warnings.
AST09 No Governance: Organizations without inventories, policies, or audit trails cannot tell what exists, who owns it, or what changed; a skill missing from inventory is itself the detection signal.
Abnormal's AI Governance module, for instance, is designed to discover approved and shadow AI tools with ownership attribution, the inventory AST09 calls for.
Drift invalidates scans, and missing governance stops teams from finding affected copies.
AST10: Cross-Platform Reuse and Lost Security Properties
Porting a skill to a new platform can strip whatever security properties lived in the original one's format: one platform enforces a permission manifest, another strips it, so a skill reviewed under tight constraints runs under loose ones elsewhere.
Reuse also scrambles provenance: a copied skill may carry no record of its original registry or version, so a registry-only inventory can miss it.
The detection signal: one skill name carrying different permissions on two platforms. Until portable manifests exist, each port deserves a fresh install's scrutiny.
How AST10 Risks Combine into Real Attack Paths
Attacks chain entries together: sourcing weaknesses give initial access, execution weaknesses give reach, and governance weaknesses give time.
Poisoned Discovery Turns Marketplace Trust into Initial Access
A skill's name, description, and popularity count are publisher-controlled, so a typosquat with understated permissions (AST04) and no provenance check (AST02) gets through. Its prose tells the agent to fetch code from a remote server, the dependency-confusion playbook ClawHavoc used; a scanner for embedded malware payloads finds nothing, since the malware downloads only at runtime. Source allowlisting, a fetch-and-execute prose review, and egress restriction each stop this path.
Mutable Instructions and Broad Permissions Expand the Attack
A skill clean on review day tells the agent to consult "the latest guidelines" at an attacker-controlled URL (AST05); weeks later the page changes to instruct reading local environment files to an outside address. Broad credentials (AST03) give that instruction something valuable to reach; a scoped token yields little. Snapshotting external references, domain allowlisting, and task-scoped credentials each interrupt this chain.
Weak Isolation Converts Agent Decisions into System Actions
Weak isolation puts sensitive data, untrusted content, and external communication in one process, the "lethal trifecta" for agents: a hidden instruction in a pull request, full shell access, and open network access let one tool call move secrets off the machine, a phrasing command denylists rarely catch. Removing any single leg, a credential-free sandbox, an egress allowlist, or human confirmation, stops this path.
Update Drift and Portability Extend Exposure Over Time
A compromised maintainer account pushes a malicious update to an unpinned skill (AST07); the old scan never re-examines it (AST08); no inventory means nobody notices once the registry pulls it (AST09); and a second platform ignoring the first one's permission manifest (AST10) runs it with broader access than ever. Content-hash pinning, approval on version changes, and a platform-aware inventory each close part of this window.
How to Prioritize OWASP Agentic Skills Top 10 Controls
The strongest order is a trusted baseline, then containment, then detection and governance: containment limits harm even when a skill slips past every check. OWASP doesn't rank controls, so this sequence is editorial, built on the attack paths above.
Inventory, Provenance, and Pinning Establish a Trusted Baseline
An inventory comes first, recording each skill's source, hash, version, platform, and owner (addressing AST09, and making AST07 and AST10 detectable). Provenance controls then narrow entry (AST01, AST02): approved sources and publisher verification counter typosquats, hash pinning turns any change into a visible mismatch, and metadata validation checks permissions against behavior (AST04).
Scoped Credentials and Isolation Limit Execution
Containment addresses AST03, AST05, and AST06, protecting against unknown threats the way detection cannot. Containers or ephemeral workspaces keep a skill's access inside that boundary, not the whole machine. Task-scoped credentials stop pivoting to adjacent systems, and blocking credential-store and SSH-key access removes the main exfiltration target. Domain-allowlisted egress cuts off downloads and theft, and human approval on high-impact actions adds a checkpoint teams often undercut with skip-prompt flags.
Layered Scanning and Behavioral Monitoring Improve Detection
Several scanners together, including ones reading natural-language instructions, catch more for AST08 than any single tool, but results work best feeding human review, since malicious prose evades patterns and legitimate skills trigger false alarms. Behavioral monitoring covers what scanning misses: a baseline of what each skill reads, contacts, and runs makes drift visible, and logging needs tool invocations and credential scopes, not just the model's text, or investigators can't reconstruct what happened.
Approval, Logging, Revocation, and Ownership Sustain Governance
Governance addresses AST09, AST07, and AST10 together: an approval workflow and a named owner per skill give security teams someone to call when behavior changes. Abnormal's AI Agent Security module, for instance, is designed to discover agents across platforms, map ownership, and flag off-task behavior, giving a revocation decision something concrete to act on. Logs belong in the SOC, and revocation needs to be a tested procedure that finds every copy across every platform; treating each port as a new install keeps no platform inheriting trust it never earned.
How AST10 Relates to Other Security Frameworks
AST10 sits between OWASP's protocol- and model-level lists, and its core controls line up with government guidance that doesn't yet mention agent skills.
Adjacent OWASP Lists Address Different Layers of Agent Security
The Agentic Applications list covers how organizations direct deployed agents, the LLM list covers model-level risks, and the MCP Top 10 covers the agent-to-tool protocol. OWASP maps AST01 to Tool Poisoning, AST02 to the supply-chain entry, AST03 to Scope Creep, and AST10 to Shadow MCP Servers; the rest have no crosswalk yet.
Government Guidance Reinforces Integrity, Least Privilege, and Monitoring
Government documents do not mention agent skills yet, so this mapping is editorial. The National Institute of Standards and Technology's (NIST) security controls for signed components map to AST01, AST02, and AST07; its confined-execution controls, plus the Cybersecurity and Infrastructure Security Agency's (CISA) agentic AI guide naming privilege creep, map to AST03 and AST06; and NIST's inventory rules plus CISA's event-logging concerns map to AST09. AST04 and Cross-Platform Reuse have the weakest coverage.
Standards Mappings Support Governance but Do Not Replace Risk Analysis
Standards confirm a governance process exists, not whether a given skill reads SSH keys or loses its manifest when ported. NIST's AI Risk Management Framework and ISO/IEC 42001 (the International Organization for Standardization's AI management standard) cover similar ground: a clean certification can coexist with an unpinned, over-privileged skill on every laptop, and skill-level analysis still finds the actual exposure.
Building Security Around the Skill Lifecycle
Treating AST10 as a lifecycle turns separate entries into one connected story: what enters the environment, what it can reach, how long it stays unnoticed, and what happens when it moves. Teams that inventory skills, pin them, contain them, and assign owners interrupt that story at several points instead of hoping one check catches everything. As registries add signing and OWASP finalizes severity scoring, the most useful habit is revalidating each trust boundary whenever a skill, platform, or registry changes.
Abnormal extends this kind of monitoring to AI tools and agents through its AI Security suite, built on the same behavioral detection approach the company uses for email and identity. AI Governance is designed to discover approved and shadow AI tools with ownership attribution, giving teams the inventory AST09 calls for and making the drift behind AST07 and AST10 visible. Meanwhile, AI Agent Security is designed to discover agents across platforms, map ownership, and flag off-task or rogue behavior, the execution-boundary problem AST03 and AST06 describe. AI Cloud Security extends that baseline into AWS, Azure, and Google Cloud.
The Abnormal platform gives security teams one behavioral model spanning AI tools, agents, and cloud activity, rather than a separate console for each surface AST10 touches. Book a demo to see how Abnormal maps agent and AI-tool risk across an environment.
Frequently Asked Questions
Does AST10 Assign Severity Scores to Every Risk?
Not formally. The whitepaper withholds ratings until AIVSS reaches release; the website's Critical, High, and Medium labels are informal and provisional, not a priority ranking.
Does AST10 Apply to Tools and Protocol Servers?
Only partly. AST10 covers skills; a single tool function or a protocol server falls outside its definition and belongs to the MCP Top 10 instead, so a typical review uses both lists together.
Can Organizations Rely on Skill Scanners Alone?
No. Prose-phrased instructions can pass pattern checks. Scanners are most valuable for triage, sorting a backlog so reviewers see the riskiest skills first, feeding human review rather than acting as the only gate.
How Should Teams Handle Skills Used Across Multiple Platforms?
Keep one canonical copy of each approved skill with its hash and intended permissions, generate each platform's version from that copy, and verify its native settings match, since some formats drop constraints others enforce. Tracking platform as an inventory field lets one revocation reach every copy.