How Security Teams Can Operationalize the OWASP Agentic Skills Top 10
OWASP’s new Agentic Skills Top 10 gives security teams a shared vocabulary for agent skills. Most of its checks assume you already know what’s installed. Here's our read on the four risks to prioritize which unlock all the others - and why these can only be realized through a true behavioral understanding of your agents
OWASP’s new Agentic Skills Top 10 is the first community taxonomy written specifically for agent skills. A skill is a folder of instructions, scripts and metadata that gives an agent bespoke context on a specific topic. The agent calls on it for tasks it wasn’t designed for, or tasks that need insider knowledge it wouldn’t otherwise have. Anthropic introduced the format and several agent platforms have adopted it, so a skill written once can now run in many places with whatever access its host agent holds. Our MCP vs Skills explainer covers how skills differ from tools and MCP servers.
Most of the report’s mitigations are checks made at installation, and they assume the security team knows an installation is happening. In most enterprises, that assumption doesn’t hold. A skill can be installed with a single command, or on some platforms by uploading one file. Many are now pulled from public skill marketplaces or written by agents themselves, and none of those routes creates a record the SOC will see.
How the ten risks fit together
OWASP groups its ten risks by where they appear in the skill ecosystem:
- Sourcing and registry trust: malicious skills, supply chain compromise and insecure metadata.
- What a skill can reach once it runs: over-privileged skills, untrusted external instructions and weak isolation.
- How skills are managed over time: update drift, poor scanning and missing governance.
- Cross-platform reuse: what gets lost when a skill moves between platforms.
Of the ten risks, four stand out to us because they explain why the other six are hard to catch in a real enterprise: they describe how a skill goes unexamined, keeps more access than intended, or changes after approval.
AST03: Over-Privileged Skills
OWASP pinpoints where least privilege breaks down. Prompt injection can push a skill permitted to run SELECT queries into running DELETE, because the permission check happens at the tool call and never considers the agent’s intent: what it was asked to do, and why it decided to make the call. The evidence includes more than 280 ClawHub skills exposing API keys and personal data beyond their declared function.
A skill rarely has permissions of its own. It inherits them from the agent that loaded it, which sometimes inherits them from a person, a service account or a platform integration. Whether a skill is over-privileged depends on which agent runs it and what that agent’s identity can reach, so the same skill can be harmless in one department and dangerous in another.
Controls for skills therefore need to depend on context. An agent in finance that is authorized to process financial data should be able to do so, while the same pattern in marketing should be steered away from that data without stopping the workflow. Doing this consistently across thousands of agents takes deterministic policy enforced through the agent’s own configuration, rather than a blanket allow or block on the skill.
Many agent platforms already offer part of this. Enterprise tiers let administrators manage agent configuration centrally and allowlist or blocklist skills, which is a sensible foundation. What a managed configuration can’t show is whether anything is running outside the list. Checking that means knowing what each agent actually loads, on every platform, which is the inventory problem AST09 describes (see below).
AST07: Update Drift
OWASP opens this entry with “Skills are installed and forgotten.” Without pinning and verified updates, a deployed skill drifts from the version anyone reviewed. That can leave a known vulnerability open, or let an auto-update apply a malicious “patch” from a compromised author account. On platforms with hot-reload, an edited SKILL.md file takes effect mid-session.
A skill approved in March isn’t necessarily the skill running in September, and a point-in-time review can’t tell the difference. OWASP recommends recording the version, content hash and last-verified timestamp of every installed skill. Keeping that record current on every platform where agents run is the hard part, which makes drift a posture management problem before it’s a patching problem. That’s true of every agentic tool, but it matters most for skills, because they’re so simple to create and modify.
AST08: Poor Scanning
OWASP sums this one up in a line: “The enemy of AI security is the infinite variability of language.” The core of a skill is SKILL.md, a markdown file of plain text that the agent reads as instructions, and that text can do as much damage as any script bundled with it. A regex scanner looks for code signatures such as curl in a shell script. A paragraph of prose asking the agent to fetch a file and send it elsewhere has the same effect and no signature to find.
Snyk found critical issues in 13.4% of the skills in its ToxicSkills corpus, most of which simple pattern matching missed. In June, Trail of Bits bypassed every scanner it tested, including one backed by an LLM guard model. In one test, an LLM judge rated a malicious registry redirect as benign once it was framed as a corporate network configuration.
Intake scanning reads what a skill says, and the risk lies in what the skill does once loaded. OWASP describes skills that behave safely in testing and activate only under specific runtime conditions, which pre-install analysis won’t reliably catch. Understanding a skill means pairing its declared configuration with its observed behavior over time.
The Trail of Bits result also shows why an LLM shouldn’t make the final control decision. We use language models for analysis and anomaly detection, where they are strong, but a verdict that can be argued away is a poor basis for enforcement. Enforcement should be deterministic.
AST09: No Governance
OWASP describes organizations that lack “the inventories, policies, review processes, and audit trails needed to manage skills at enterprise scale.” Individuals install skills with no SOC visibility, no approval workflow and no way to revoke them, and asset management tools have no concept of a skill at all. Bitdefender, cited in the report, found hundreds of OpenClaw deployments on corporate machines and more than 800 malicious skills.
One scenario in this entry is worth singling out. OWASP’s “unreachable skill” runs inside a managed SaaS copilot or agent platform whose endpoints and registries the security team doesn’t administer. With no host to scan and no local manifest to read, endpoint and registry discovery never see it, and every downstream control skips it. The report calls it “invisible by architecture.”
Agents are systems, not surfaces. Their configuration, identity, tools and activity span cloud, code and endpoint, and a tool watching one surface sees one slice. Skills also generate no outbound traffic for a gateway to intercept, because they are loaded from configuration inside the agent’s harness. Finding them means reading that configuration wherever agents run.
The gap is rarely small. One biotech company in France found 327% more agents than its CTO and security team had estimated, and our piece on shadow AI and agent sprawl explains how that happens.
OWASP’s mitigations here amount to a specification: name, version, hash, install date, installer identity and scan status for every skill, plus revocation tied to offboarding. Surveys and spreadsheets can’t supply most of those fields. The installer field matters because, as the report’s orphaned-skill scenario shows, a skill can keep running on a departed developer’s credentials. Catching that requires knowing how each skill connects to an agent, and each agent to an owner and an identity.
Where to start
For a security team working through the list, we’d take these four steps in roughly this order.
- Inventory skills specifically, across endpoint, code and managed cloud platforms. If the answer comes from a survey, treat it as a lower bound.
- Tie every skill to an agent, an owner and an identity, and add skill revocation to offboarding and incident response playbooks.
- Keep checking after approval. Record which version was approved and flag it when the running version changes.
- Judge skills by how they behave at runtime, with baselines that show when a skill starts doing something new. Intake scanning won’t catch a skill designed to pass it.
Mapping the list to your own controls
The report maps every entry to other frameworks, including OWASP’s AI Security Verification Standard, the Agentic Security Initiative Top 10, the MCP Top 10, CSA MAESTRO and, for AST09, the GOVERN function of the NIST AI RMF. Few teams adopt one framework wholesale, and most need to see how a risk lines up across several.
That cross-mapping matters because no single framework fully accounts for the pace at which the agentic landscape is shifting. Teams are choosing their own combinations of NIST, OWASP, ISO and others, and the real challenge is less about which framework to follow than about keeping any of them current against what is actually deployed. One Geordie customer put it plainly:
“The field is moving so fast. We hand it to Geordie to say, ‘here’s what is important that you need to be looking at.’”
New frameworks will keep arriving at that pace, and each is only useful once a team can apply it to the skills actually running in its environment. For every risk on OWASP’s list, that starts with knowing what’s there.
