OWASP Agentic Skills Top 10: A Security Guide to AI Agent Skills Risks

In the space of a year, AI agent skills went from a niche convenience to a mainstream distribution channel. A skill is a small package - usually a folder of markdown instructions and some supporting code - that you drop into an agent to teach it a new capability: format a changelog, run a deploy, scaffold a service, query a database. The same package format works across OpenClaw, Claude Code, Cursor, and VS Code, and public marketplaces now list thousands of them. The appeal is obvious. The problem is that a skill behaves like installable software - it can execute shell commands and call tools with the agent's full permissions - while it ships, updates, and gets shared like a README file, often with no signing, no review, and no version pinning.

That mismatch is why OWASP published the Agentic Skills Top 10, an awareness list that names the ten most significant risks specific to the skills layer using the AST prefix (AST01 through AST10). It is the skills-focused companion to the broader OWASP Top 10 for Agentic Applications and the OWASP Top 10 for LLM Applications. This guide is the pillar for our skills-security cluster: it explains what skills are, why the list exists, and walks all ten risks with their enterprise impact, before turning to how you actually govern the layer. If you want the foundational primer first, read what are AI agent skills.

What agent skills are, and why they became a shadow-IT layer

An agent skill is a reusable capability package that loads into an AI agent and runs with the agent's full permissions on the endpoint. Concretely, it is markdown instructions the agent reads and follows, plus code (shell or Python, typically) the agent can invoke. Skills load from a local directory or a fetched repository, and once loaded they are part of the agent's behavior for the session. There is rarely a permission prompt at the skill boundary the way there is for, say, a browser extension - the skill simply inherits whatever the agent can already do.

That inheritance is the whole story. Skills spread bottom-up: a developer finds one that saves an hour, drops it in, and shares it with the team. No one files a ticket, no one reviews the code, and security never sees it. This is the exact pattern we describe in AI agents are the new shadow IT - capability arriving through a side door that traditional controls were never built to watch. Skills are arguably the sharpest version of it, because a single shared skill can propagate a capability (or a payload) across an entire engineering org in days.

The dual attack surface every skill carries

Before the individual risks, it helps to see the shape they share. A skill exposes two attack surfaces at once. The first is the code layer: the shell or Python a skill can run, along with the tools and MCP servers it can invoke, all executing with the agent's privileges and forming the classic target of supply-chain and malicious-package attacks (the MCP server security guide covers the tool surface in depth). The second, and the one most teams overlook, is the natural-language instruction layer: the markdown documentation inside the skill, which the agent reads and follows as guidance. Hidden or obfuscated directives in that prose are a form of indirect prompt injection delivered through a trusted-looking package. Static code scanners read code, not prose, so a malicious instruction can pass every check while quietly redirecting the agent. Keep both surfaces in mind as we walk the ten risks.

The OWASP Agentic Skills Top 10 at a glance

AST01 through AST10, explained

AST01 - Malicious Skills

The most direct risk: a skill authored specifically to cause harm. The payload may sit in the code layer (a script that reads environment variables and posts them out) or in the instruction layer (markdown that quietly tells the agent to add a step, weaken a check, or contact an attacker-controlled endpoint). Because a skill runs with the agent's full permissions, a malicious skill needs no privilege escalation - it already has whatever the agent has.

The enterprise impact is that a single installed skill can become a foothold on a developer or employee machine that already holds cloud credentials, source access, and internal network reach. Academic and industry researchers have demonstrated exactly this class of payload, which we cover in depth in malicious agent skills and hidden payloads.

AST02 - Supply Chain Compromise

Even a skill you trust can turn hostile if its upstream source or its dependencies are compromised. An attacker who takes over an abandoned skill, a maintainer account, or a dependency the skill pulls in can push malicious content to everyone who installs or updates from that source. This is the same dynamic that plagues package ecosystems, now aimed at the agent layer. The dependency-takeover variant is common enough to have its own name - see skilljacking and abandoned-skill takeover - and it sits inside the broader pattern in our AI supply chain attacks guide.

AST03 - Over-Privileged Skills

A skill that formats text does not need network egress or the ability to delete files, yet because skills inherit the agent's permissions, they typically get everything the agent has. Over-privilege is the amplifier for nearly every other risk on this list: a malicious or manipulated skill is only as dangerous as the access behind it. This maps directly to OWASP LLM06 Excessive Agency and to ASI-03 Identity and Privilege Abuse. The fix is the same architectural control we cover for agents generally - scope permissions to the task and enforce them where the skill cannot reach. See least privilege for agent skills and the broader least privilege for AI agents.

AST04 - Insecure Metadata

Skills carry metadata: a name, description, declared capabilities, author, and version. When those fields are unverified or trivially spoofable, a skill can misrepresent what it is - claiming to be a benign formatter while carrying a very different payload, or impersonating a popular skill to trick users into installing it. Insecure metadata undermines every downstream decision, because vetting and inventory both start from what the skill says about itself. If the manifest lies, the whole trust chain is built on sand.

AST05 - Untrusted External Instructions

Many skills fetch content at runtime - a template from a URL, a config from a repository, data from an API - and feed it to the agent. If any of that external content carries instructions, the agent may follow them. This is indirect prompt injection with the skill as the delivery vehicle: the skill itself may be clean, but it opens a channel for untrusted instructions to steer the agent mid-task. The impact scales with the agent's reach, and it is precisely the mechanism behind data-exfiltration chains like the lethal trifecta.

AST06 - Weak Isolation

Skills generally run inside the agent's own process and context, with no sandbox between them. One skill can read secrets in the environment, tamper with files another skill relies on, or observe and alter the agent's state. Weak isolation means the blast radius of any single bad skill is the entire agent context, including credentials mounted for unrelated tasks. Proper isolation - separate execution contexts, restricted filesystem and network access - is what keeps a compromised skill from becoming a compromised endpoint.

AST07 - Update Drift

You vet a skill on Monday and it is safe. It auto-updates or gets re-fetched on Thursday and it is not. Without version pinning and re-review on change, the artifact you approved is not the artifact that runs later - a gap attackers exploit deliberately by pushing a clean version first and a payload after adoption. Update drift also defeats point-in-time audits: a clean scan yesterday says nothing about today's code. Pinning, change detection, and re-vetting on every update are the countermeasures.

AST08 - Poor Scanning

Most detection tooling was built to scan code. Skills carry a natural-language instruction layer that code scanners simply do not read, so a malicious directive written in plain English inside the markdown passes every static check. Poor scanning is the risk of assuming a green scan means a safe skill. Effective scanning has to inspect both layers - the code and the prose - and treat obfuscated or hidden instructions in the documentation as first-class findings, not comments.

AST09 - No Governance

The meta-risk. Most organizations have no inventory of which skills are installed, no owner assigned to each, no approval step before install, and no audit trail of changes. Without governance, none of the other controls are enforceable, because you cannot vet, scope, isolate, or re-review what you cannot see. This is the risk Anomity exists to close, and it is why discovery and inventory are the prerequisite for everything else - the same principle we apply to building an AI agent inventory.

AST10 - Cross-Platform Reuse

The property that makes skills convenient - one format that runs on OpenClaw, Claude Code, Cursor, and VS Code - is also what makes them dangerous at scale. A single compromised skill can spread across every platform that loads it, and a vulnerability in the shared format affects them all at once. The mass exposure of agents in incidents like the OpenClaw security crisis shows how quickly a shared surface turns a local problem into a fleet-wide one. Cross-platform reuse means your skills-governance policy has to span every agent your people run, not just one.

How Anomity helps govern the skills layer

Every risk on the AST list assumes a capability most organizations do not have: the ability to see and control skills across the fleet. That is the gap Anomity closes. Its category is agentic endpoint security, built on a simple principle - you can't govern what you can't see.

A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint (Windows, macOS, and Linux) and discovers eight AI artifact types: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. Skills are one of the eight. For each skill, Anomity records where it came from, who installed it, its version, and what it can reach - the inventory that AST09 (No Governance) and AST04 (Insecure Metadata) both demand. The sensor sends metadata only over HTTPS to the Anomity Cloud; never source code, never prompts, and secrets are redacted on the endpoint.

At runtime, on agents that expose a hook, Anomity evaluates each tool call a skill triggers and returns allow, deny, or log before it runs. That is the enforcement point for AST01, AST03, AST05, and AST06 - an over-privileged or manipulated skill's action is checked against policy first, so an unexpected shell command or network call can be denied rather than executed. Continuous policy evaluation means AST07 update drift surfaces as a change event, and violations route to your SIEM, Slack, email, and Jira. Every skill added, removed, or modified lands in a queryable 90-day audit trail, so a clean-scan-then-poison sequence is visible after the fact, not invisible.

Anomity is SOC 2 Type II and complements rather than replaces your EDR/XDR, DLP, network and gateway controls, and GRC program - it adds the artifact-layer visibility those tools were never built to see. To operationalize the AST list, pair this inventory with a vetting and approval playbook before install and least privilege for agent skills at runtime.

You can't govern what you can't see.The Anomity principle

The bottom line

The OWASP Agentic Skills Top 10 exists because skills quietly became one of the highest-leverage ways to change what an AI agent does - and one of the least governed. The ten risks are not exotic; they are the familiar problems of malicious code, supply-chain compromise, over-privilege, weak isolation, and missing governance, sharpened by two things unique to skills: a natural-language instruction layer that scanners ignore, and a shared format that lets one bad package spread across every platform. The controls are the ones you already know - least privilege, provenance, isolation, human vetting - but none of them work on skills you cannot see. Start there: inventory every skill across every endpoint, then vet, scope, and govern from a place the skill cannot rewrite. To see your own skills posture, book a 30-minute demo.