The OWASP Agentic Skills Top 10

Why skills need their own list

MCP defines one way an agent reaches tools. Skills supply instructions and may bring code, hooks, dependencies, and remote content. The boundary is rarely clean because community repositories commonly package several of these pieces together. Security review must follow the bundle from publisher to registry, endpoint, agent runtime, and external action.

The ten risks

AST01

Severity: Critical

Control family: Signed provenance and behavioral review

Malicious Skills

Read the OWASP AST01 description

A skill can be malware from the day it is published. Antiy CERT linked 1,184 malicious skills to the ClawHavoc campaign. Snyk later confirmed 76 malicious payloads in a 3,984-skill corpus; 36.82% of that corpus had at least one security flaw.

Applies at

Authoring, distribution, install

Control owner

AppSec and endpoint security

What to check

• Block approval when the publisher, repository, version, or installer cannot be attributed and retained.
• Inspect instructions and bundled executables, then retain the scan result and content hash.
• Alert on unknown publishers and observed runtime behavior, not only known malicious names.

Examples

Antiy CERT: ClawHavocSnyk: ToxicSkillsRelated supply-chain pattern: RubyGems and RubyDoc.info

AST02

Severity: Critical

Control family: Registry transparency and end-to-end provenance

Supply Chain Compromise

Read the OWASP AST02 description

The skill may be clean at authoring while its repository, publisher account, registry entry, dependency, or update path is compromised later. Check Point showed that repository-controlled Claude Code configuration could execute commands and expose an API key before the trust dialog in CVE-2025-59536.

Applies at

Repository, registry, update path

Control owner

AppSec and platform engineering

What to check

• Resolve each installed skill to a specific publisher and repository, not a display name.
• Detect configuration and hook changes inside repositories that agents open.
• Block approval when source-to-install provenance or publisher identity cannot be verified.

Examples

Check Point: Claude Code project-file flawsRelated registry pattern: Coder infrastructure hijack

AST03

Severity: High

Control family: Least-privilege capabilities and policy validation

Over-Privileged Skills

Read the OWASP AST03 description

A skill, plugin, or companion server can receive more file, shell, network, connector, or credential access than its task requires. Snyk documented more than 280 skills exposing API keys or personal data through excessive access. A later compromise inherits those grants.

Applies at

Approval and runtime

Control owner

Platform engineering and IAM

What to check

• Compare each skill's declared capabilities against what its stated purpose actually requires.
• Audit auto-approve and skip-confirmation settings that skills can rely on.
• Block approval when permissions cannot be scoped to the project, identity, and task.

Examples

Snyk: ToxicSkills findingsRelated access-control pattern: Instinct

AST04

Severity: High

Control family: Safe parsing, content review, and isolated loading

Insecure Metadata

Read the OWASP AST04 description

Instruction and manifest files such as SKILL.md, skill.json, manifest.json, and package.json are executable trust inputs. Unsafe parsers, deceptive metadata, hidden instructions, and brand impersonation can alter what an agent loads or what a user believes they approved.

Applies at

Authoring and load

Control owner

AppSec

What to check

• Read skill instruction files as code: diff them, review them, keep history.
• Look for instructions that reference credentials, environment variables, home directory paths, or outbound requests.
• Block approval when metadata suppresses confirmations, hides output, or cannot be parsed safely.

AST05

Severity: High

Control family: Source inventory, content pinning, and continuous review

Untrusted External Instructions

Read the OWASP AST05 description

Skills can pull live instructions from URLs, documentation, issue threads, or other sources outside the publisher's control. Air Security reported 17,822 skills with at least one untrusted external instruction source in a 142,836-skill scan. Its proof-of-concept skill reached 26,000 agents after the scanners it tested cleared it.

Applies at

Load and runtime

Control owner

AppSec and SOC

What to check

• Inventory every external source each installed skill loads instructions or content from.
• Pin external content where possible and rescan it continuously, not just at install.
• Block combinations that expose one agent to untrusted input, sensitive data, and external action: the Lethal Trifecta.

Examples

Air Security: The Circus of SkillsAir Security: The Story of SkillsRelated trust-boundary pattern: Wiz Red Agent

Observed in the wild

A malicious skill crossing the trust chain

• What Would Elon Do?

  Cisco reported nine flaws, including silent data-exfiltration behavior

• polymarket-trading-bot

  The earliest malicious package in Antiy CERT's campaign timeline

• reddit-trends

  One package tied to the coordinated ClawHavoc registry poisoning

• base-agent

  A separate ClawHavoc package distributed through the same publisher network

• polymarket-all-in-one

  Contained code capable of downloading a remote-control trojan

Each example links to the supporting Cisco AI Defense or Antiy CERT research. No executable instructions are reproduced.

Ecosystem shown: Cursor · OpenClaw · VS Code · Claude

AST06

Severity: High

Control family: Process, filesystem, credential, and network isolation

Weak Isolation

Read the OWASP AST06 description

A skill without process, filesystem, credential, and network boundaries can act with the host user's authority. Microsoft Defender recommends treating self-hosted agent runtimes such as OpenClaw as untrusted code execution with persistent credentials and running them in a dedicated isolated environment.

Applies at

Runtime

Control owner

Endpoint security and platform engineering

What to check

• Run agents and their skills in isolated environments wherever the platform allows it.
• Implement network restrictions for agent processes, especially egress from machines with regulated data.
• Block deployment when isolation cannot be demonstrated with a runtime test and retained evidence.

Examples

Microsoft: OpenClaw isolation and runtime risk

AST07

Severity: Medium

Control family: Immutable pinning, change detection, and reapproval

Update Drift

Read the OWASP AST07 description

Approval applies to reviewed content, not a permanent skill name. Branch references, silent publisher changes, transitive dependencies, and bundled repository updates can make the installed artifact differ from the approved one.

Applies at

Update and continuous monitoring

Control owner

AppSec and platform engineering

What to check

• Pin skills to versions or commits instead of tracking a branch.
• Detect content changes to installed skills and re-review on change.
• Block changed content until the new hash, dependency set, and behavior are reviewed again.

AST08

Severity: Medium

Control family: Layered static, semantic, and behavioral review

Poor Scanning

Read the OWASP AST08 description

A clean scanner result is not an approval. Skill risk may sit in natural-language instructions, remote content, bundled scripts, conditional behavior, or interactions between packages. Trail of Bits reported bypassing the public skill scanners it tested in under an hour.

Applies at

Install, update, and runtime

Control owner

AppSec and SOC

What to check

• Do not treat a scanner pass as approval; scan results are one signal, not a verdict.
• Prefer tools that combine static, semantic, and behavioral analysis over signature matching.
• Block approval when the review excludes instructions, dependencies, remote references, or runtime behavior.

Examples

Trail of Bits: the state of skill distribution

AST09

Severity: Medium

Control family: Unified inventory, ownership, policy, and revocation

No Governance

Read the OWASP AST09 description

Security teams cannot govern packages they cannot find or assign. Skills often arrive through a larger plugin, extension, MCP server, or community repository, so a skill-only inventory misses the deployment unit, its owner, and the path needed to revoke it.

Applies at

Discovery through incident response

Control owner

Security operations and IT

What to check

• Build a live inventory of skills, MCP servers, and extensions across endpoints.
• Assign an owner to every skill so findings and policies have someone to route to.
• Test that one policy action can quarantine or revoke a package across affected endpoints.

AST10

Severity: Medium

Control family: Portable identity, provenance, and policy metadata

Cross-Platform Reuse

Read the OWASP AST10 description

The same capability can be copied between marketplaces, repositories, plugins, and agent products under different names and package formats. Each port can drop provenance, permissions, ownership, or prior findings, leaving separate teams to review the same underlying behavior again.

Applies at

Distribution and inventory

Control owner

AppSec and platform engineering

What to check

• Normalize your inventory across platforms so one skill is one entry regardless of packaging.
• Watch for the same publisher or payload appearing under different names on different registries.
• Block approval when a port cannot be linked to its source artifact and prior review record.

Approval gate for a skill bundle

Apply this gate to the whole installed bundle: skill, plugin, extension, MCP server, repository files, dependencies, and remote sources.

1. Publisher and provenance. Pass when every artifact resolves to a verified source and retained version. Investigate identity gaps. Block unattributed or mutable sources.
2. Instructions and metadata. Pass when reviewed content matches the stated job. Investigate hidden or remote instructions. Block attempts to suppress confirmation or output.
3. Code and hooks. Pass when every bundled script, hook, and dependency is scanned and pinned. Block unreviewed install-time execution.
4. Capabilities. Pass when tools, permissions, identities, and MCP servers are limited to the task. Block broad shell, data, or network access without a documented reason.
5. Destinations. Pass known, required outbound routes. Investigate newly observed domains. Block undeclared egress.
6. Persistence. Pass documented state changes. Investigate memory and project-file writes. Block hidden persistence.
7. Combined risk. Review the complete installed set. Block any path that joins untrusted input, sensitive data, and external action without an enforceable boundary.

References

Official OWASP descriptions

• AST01: Malicious Skills
• AST02: Supply Chain Compromise
• AST03: Over-Privileged Skills
• AST04: Insecure Metadata
• AST05: Untrusted External Instructions
• AST06: Weak Isolation
• AST07: Update Drift
• AST08: Poor Scanning
• AST09: No Governance
• AST10: Cross-Platform Reuse

Examples and supporting research

• Antiy CERT: ClawHavoc
• Snyk: ToxicSkills
• Check Point: Claude Code project-file flaws
• Snyk: ToxicSkills findings
• Air Security: The Circus of Skills
• Air Security: The Story of Skills
• Microsoft: OpenClaw isolation and runtime risk
• Trail of Bits: the state of skill distribution

For these risks in real incidents, read the Civilizations threat briefings.