In late January 2026, attackers registered as developers on ClawHub and flooded the registry with 341 malicious skills in three days. The skills stole exchange API keys, wallet keys, SSH credentials, browser passwords and .env files. Some also wrote hidden instructions into the agent's memory files so the backdoor survived across sessions.
It was the first time an AI agent registry was poisoned at scale. It was not the last.
Skills are now the fastest way to extend AI coding agents, and the least governed. A skill is reviewed once, at install. It acts every time the agent runs. The gap between review time and run time is where most skill attacks in 2026 did their damage, and it is the gap the OWASP Agentic Skills Top 10 was written to close.
This guide explains the ten risks, the incidents behind them, and why DAXA believes skill security has to be enforced where skills act, not only where they are installed. For the wider OWASP picture, see our breakdown of the OWASP LLM Top 10 2026 and the Agentic Top 10.
What Is the OWASP Agentic Skills Top 10?
The OWASP Agentic Skills Top 10 (AST10) is an OWASP project that lists the ten most critical security risks in AI agent skills, from AST01 Malicious Skills to AST10 Cross-Platform Reuse. It covers OpenClaw, Claude Code, Cursor, Codex and VS Code, and gives security teams mitigations for each risk.
AST10 is the first security framework built specifically for the skill layer. The project is an OWASP incubator project, and V1 is open for public review.
Two risks are rated critical, four high and four medium. Each is tied to a documented 2026 incident rather than a hypothetical. That makes it usable as a working checklist for security teams, not just an awareness document.
What Are AI Agent Skills and How Do They Differ From MCP Tools?
AI agent skills are reusable packages of instructions and scripts that tell an agent how to complete a multi-step task. MCP tools expose what an agent can access. Skills decide how the agent uses those tools, in what order and with what data, so a harmful skill can misuse even well-secured tools.
OWASP draws the line clearly: MCP defines how the model talks to tools, while skills define what those tools actually end up doing.
That difference changes the threat model in three ways:
- Skills are mostly natural language. A skill can cause harm by instructing the agent, with no malicious code for a scanner to find.
- Skills inherit the agent's access. Whatever the agent can read, write or call, the skill can direct it to.
- Skills can change after review. They can be updated, or they can fetch new instructions from outside the package at runtime.
OWASP uses the lethal trifecta as its triage test. A skill is most dangerous when it can reach private data, is exposed to untrusted content, and can send data out, all at the same time. By OWASP's own assessment, most production agent deployments meet all three conditions. We covered how the same pattern drives indirect prompt injection in AI coding agents.
The OWASP Top 10 for Agentic Applications names supply chain risk under ASI04, and we have written about how MCP security risks enter through the tool layer. Neither goes down to the skill file itself. AST10 does.
Why Agent Skill Scanners and Version Pinning Fail to Stop Malicious Skills
Skill scanners and version pinning fail because they only check a skill before it runs. Scanners look for code patterns, but many skill attacks are plain-language instructions. Pins can be bypassed, and skills can fetch new instructions after review. None of these checks see what the skill makes the agent do.
Snyk's ToxicSkills audit of 3,984 skills found security flaws in 36.82% and critical issues in 13.4%. Most organizations still rely on install-time checks to catch them: scan the skill, pin the version, prompt the developer to trust the project. The 2026 record shows each of these can fail on its own.
- Scanners miss instruction-based attacks. In June, Trail of Bits bypassed every public skill scanner it tested in under an hour, in part by prompt-injecting the scanner's own LLM judge.
- Trust prompts can be skipped. Check Point Research disclosed two Claude Code flaws (CVE-2025-59536, CVSS 8.7, and CVE-2026-21852, CVSS 5.3) where repository config could run shell commands and leak API keys at project open, before any trust dialog appeared. Both were patched before disclosure.
- Reviewed skills keep changing. Air's scan of 142,836 live skills found 17,822 (12.4%) relied on at least one untrusted external instruction source.
- Pins can be bypassed. In September, researchers at Air disclosed Plugin4Shell, a zero-click RCE shared by Claude Code, Codex, GitHub Copilot and Gemini CLI. Each agent checked out the pinned commit without confirming the checkout actually landed there, so an attacker could swap in malicious code while the pin still looked intact.
This is DAXA's core point about skills. Every one of these controls runs before the skill does. None of them sees what the skill actually makes the agent do. Install-time checks are necessary, but they cannot be the last line of defense. The same pattern runs through our threat briefing on the agentic attack surface.
OWASP Agentic Skills Top 10 List: All 10 Risks Explained
The ten risks are Malicious Skills, Supply Chain Compromise, Over-Privileged Skills, Insecure Metadata, Untrusted External Instructions, Weak Isolation, Update Drift, Poor Scanning, No Governance and Cross-Platform Reuse. Two are rated critical, four high and four medium.
The table below follows OWASP's own risk table, with real-world evidence and the key mitigation for each risk.
AST01, AST02, AST04, AST08 and AST10 are decided before a skill runs. AST03, AST05 and AST06 play out while it runs. AST07 and AST09 decide whether anyone notices when things change. Plugin4Shell is a recent AST07 case: the pin looked intact while the code underneath it had changed.
What Is Runtime Governance for AI Agent Skills?
Runtime governance checks every model call and tool call a skill triggers against policy at the moment it happens. Instead of trusting a skill because it passed review, it blocks harmful actions and sensitive data exposure while the agent runs, whichever skill made the request.
A skill has no power of its own. Everything it does passes through the agent's model calls and tool calls. So instead of trying to judge every skill perfectly at install, DAXA governs what any skill can make an agent do.
That is the idea behind DAXA's Identity and Action Management approach: enforce policy at AI runtime so sensitive data stays off limits and unauthorized actions are stopped before they happen, whichever agent, app or model makes the request. For AI coding assistants, teams point the assistant's configuration at DAXA's model gateway and MCP gateway. Developers keep their existing workflow.
Here is how that maps to the skill risks above:
- Safe Infer on the model path. It inspects prompts, code snippets and completions in real time and blocks or redacts sensitive content by policy. A skill that tries to pull secrets into the model, or push source code out, is stopped at the data layer. This covers the data exposure behind AST01 and AST03.
- Safe Agent on the tool path. It validates permissions and sanitizes payloads on every MCP tool call. It blocks unsafe actions such as database deletes or secret exfiltration, regardless of which skill requested them. This limits the damage from AST01, AST03 and AST06.
- Injection checks on what comes back. MCP tool responses are classified for injection before the agent acts on them. Instructions a skill fetches after review still face a check, which is the core of AST05.
- Change detection after approval. Guardian Agent tracks tool-definition changes after approval and cuts the connection when a tool changes. This is the tool-layer answer to AST07.
- Inventory, identity and audit. MCP server vetting, an SBOM-style inventory of agent tools, per-agent identity through the customer's IdP, and full audit trails of AI interactions. This gives security teams what AST09 asks for.
DAXA does not replace registry signing or skill scanning. Those still decide what gets in. DAXA decides what any skill, trusted or not, is allowed to do once it runs. Together they close the gap between review time and run time.
How to Secure AI Agent Skills: A 5-Step Enterprise Checklist
To secure AI agent skills: inventory every installed skill, restrict sources to verified publishers, cut each skill's permissions to what its task needs, verify versions on every load, and enforce policy on the agent's model and tool calls at runtime, with every action logged.
A practical rollout takes about a month and does not require slowing developers down.
- Build a skill inventory (week 1). List every agent platform in use and every skill installed on it, including skills on developer laptops. Skills installed outside IT's view are shadow AI at the agent layer. OWASP treats this inventory as an immediate priority.
- Restrict skill sources (week 2). Move to an allowlist of registries and verified publishers. Remove any skill you cannot trace to a known source. This addresses AST01, AST02 and AST04.
- Cut permissions and verify integrity (week 3). Review each skill's file, network and shell access against its stated purpose. Pin versions and verify hashes on every load, not only on install. This addresses AST03 and AST07.
- Enforce policy at runtime (week 4). Route agent model traffic and tool calls through a governance layer, so an over-privileged or changed skill is stopped at the action. For coding agents, the AI coding assistants setup is a configuration change. This addresses AST05 and AST06.
- Log and prepare to respond. Send skill actions to your SIEM and adapt the OWASP incident response playbook for skill compromise. Use the OWASP security assessment checklist to confirm coverage.
Conclusion
The OWASP Agentic Skills Top 10 names a risk that grew faster than anyone governed it. Skills are not documentation. They are an execution layer that runs with your agent's credentials and your data in reach.
The 2026 incidents point to one conclusion. Install-time checks decide what gets in, but they cannot see what a skill does next. Enterprises scaling AI agents need both layers: registry controls to reduce what enters, and runtime governance to control what any skill can do once it runs.
To see how DAXA governs agent actions and data at runtime, request a demo.
