OWASP / Skills Top 10

Risk that adversaries publish agent skills — on registries such as ClawHub or skills.sh — that appear legitimate but contain hidden malicious payloads including credential stealers, reverse shells, backdoors, and social engineering instructions embedded in skill prose. Because skills execute with the full permissions of the host agent, a malicious skill gains immediate access to API keys, SSH credentials, wallet files, browser data, and shell, exploiting both the code layer and the natural language instruction layer simultaneously.

Ensure that cryptographic signatures (e.g., ed25519) are required for all published skills, that unsigned installs are rejected, and that hash-pinned installed skills alert on any modification to detect tampering after installation.

Ensure that skill registries implement Merkle root signing, that skills are scanned at publish time and install time using behavioral analysis (not just pattern matching), and that publisher trust level, install count, and scan status are displayed in the registry UI.

Ensure that "Prerequisites" sections in skill definitions are never automatically executed without explicit user review, and that users are warned before any skill-initiated terminal commands or external downloads are permitted.

Risk that skill registries and distribution channels — lacking the provenance controls of mature package ecosystems — are exploited through coordinated mass uploads, dependency confusion, account takeover, repository poisoning, and configuration file hijacking. Repository configuration files that were once passive metadata have become active execution paths, meaning a compromised skill inherits the agent's full credential set — not just sandboxed package permissions.

Ensure that each published skill is linked to a verified code-signing identity and that transparency logs are maintained for all registry operations (publish, update, delete) — analogous to Certificate Transparency — enabling detection of unauthorised or coordinated mass-upload campaigns.

Ensure that all direct and transitive dependencies are pinned to immutable content hashes (sha256:) rather than version ranges, and that recursive dependency trees — not just top-level skill files — are scanned for tampering or malicious indicators.

Ensure that repository configuration files including hooks, settings files, and environment overrides are treated as executable code subject to the same trust gates as skill definitions, requiring explicit user trust confirmation before any repository-controlled configuration is permitted to execute.

Risk that skills are granted broader permissions than their stated function requires — because no mandatory permission manifest system exists or users accept all permissions without review — creating excessive blast radius where a legitimate skill with overly permissive access can be weaponised by downstream prompt injection to execute operations it was never intended to perform, including accessing agent identity files or exfiltrating credentials.

Ensure that every skill is required to declare a permission manifest specifying permitted files, network access, shell access, and tools, that skills without a manifest are rejected, and that per-skill scoped credentials rather than shared agent-level API keys are enforced.

Ensure that skills requesting write access to agent identity files (SOUL.md, MEMORY.md, AGENTS.md) are automatically flagged for elevated security review, and that network access is scoped to specific domain allowlists rather than a binary network on/off permission.

Ensure that runtime permission enforcement — not just declarative manifest checking — is applied, and that manifest permission declarations are validated against actual observed runtime behaviour in sandboxed testing before skills are approved for distribution.

Risk that skill metadata fields — name, description, author, permissions, risk tier — are attacker-controlled strings with no validation, signing, or trust anchoring, enabling adversaries to impersonate trusted brands, understate permissions, misdeclare risk tiers, poison registry search results, and embed malicious instructions in skill prose using ASCII smuggling, base64 encoding, or zero-width Unicode that is invisible to human reviewers but interpreted by the agent.

Ensure that static analysis is applied to all metadata fields at publish time to flag suspicious patterns, and that declared permissions are validated against observed sandbox runtime behaviour to detect understated or misdeclared scope.

Ensure that skill definition files are scanned for ASCII smuggling, base64 payloads, and zero-width Unicode characters that could hide malicious instructions from human reviewers while remaining interpretable by the agent.

Ensure that metadata provenance — including the declaring identity, timestamp, and signing key — is surfaced in registry UI, and that brand and trademark protection mechanisms are implemented to prevent impersonation of trusted publishers at the registry level.

Risk that AI agent skill files — in YAML, JSON, and Markdown formats with well-documented deserialization vulnerabilities — are loaded using unsafe parsers or without sandboxing, enabling attackers to embed executable payloads that trigger at skill load time before any user action, with the attack surface including SKILL.md YAML frontmatter, package.json, manifest.json, requirements.txt, and any configuration pulled during skill initialisation.

Ensure that safe YAML loaders are used by default with dangerous tags explicitly disabled (e.g., yaml.safe_load instead of yaml.load, disabling !!python/object and !!python/apply), and that an allowlist of permitted YAML/JSON keys is applied to reject any unexpected fields.

Ensure that all skill configuration files — including requirements.txt, package.json, and pyproject.toml — are parsed and validated in an isolated subprocess or container before execution, and that skill files are never deserialised with elevated privileges.

Risk that skills execute in the same security context as the host agent — with full file system access, shell access, and network egress — because sandboxing is unavailable, optional, or disabled by default, removing all containment guarantees and enabling any installed skill to achieve full system compromise, persistent host backdoors, network pivoting, and localhost-based attacks against the agent's control interface.

Ensure that container or Docker isolation is the default for skill execution and that host-mode execution requires explicit opt-in with documented risk acceptance, with seccomp and AppArmor profiles applied to constrain agent system call surface and per-skill process isolation enforced in separate namespaces.

Ensure that agent control interfaces (e.g., WebSocket endpoints) are bound to localhost with strong authentication, are never exposed on 0.0.0.0 by default, and that all connections including those from localhost are rate-limited and authenticated to prevent cross-origin brute-force attacks.

Ensure that skill hot-reload is restricted and disabled in non-development environments, and that explicit user confirmation is required for any workspace skill overrides that could shadow built-in functionality through runtime precedence mechanisms.

Risk that installed skills drift out of sync with known-good versions — either because patches are not applied leaving known vulnerabilities exploitable, or because auto-update mechanisms blindly apply upstream changes that may themselves be malicious — amplified by the absence of enterprise patch management for individually installed skills and the inability to verify "fix" versions without cryptographic pinning.

Ensure that all installed skills are pinned to immutable content hashes (sha256:) rather than version ranges, that cryptographic signature verification is required on every update with unsigned updates refused, and that an inventory of installed skills with version, hash, and last-verified timestamp is maintained.

Ensure that skill updates in enterprise deployments are subject to a human approval step before being applied, that production deployments operate in a freeze mode prohibiting hot-reload, and that security advisories for installed skills are actively monitored with alerts on CVE matches.

Risk that security scanning tools designed for traditional code are ineffective against agent skills — because skills blend natural language instructions with code in ways that defeat pattern matching, regex filters, and signature-based detection — enabling adversaries to distribute malicious skills that pass all available checks, including through pure natural-language social engineering with no detectable code signatures and through obfuscation techniques invisible to text-based scanners.

Ensure that behavioral analysis scanners that evaluate intent rather than just signatures are deployed alongside deterministic rules, that both the code layer and the natural language instruction layer are scanned independently, and that multi-tool scanning pipelines combine pattern matching, semantic analysis, and behavioral sandbox evaluation.

Ensure that skills are tested in isolated sandboxes with actual runtime behaviour observed and compared against declared behaviour in the manifest, and that installed skills are continuously re-scanned as scanner models improve — not only at initial install time.

Risk that organisations deploying AI agents lack the inventories, policies, review processes, and audit trails needed to manage skills at enterprise scale — with skills installed by individual developers without SOC visibility, approval workflow, or revocation mechanism — creating a shadow AI layer that security teams cannot see or control, enabling undetected compromise, orphaned credentials, regulatory exposure, and cascading agent compromise across multi-agent pipelines.

Ensure that a centralised skill inventory is established recording skill name, version, content hash, install date, installer identity, and last scan status for all agent skills across the organisation, integrated into existing CMDB and ITSM tooling.

Ensure that all skill installations in enterprise environments require a formal security review and approval workflow, that non-human identities (NHIs) with scoped credentials are assigned to agents on a rotation schedule, and that comprehensive audit logging covers all skill actions including file access, network calls, shell commands, and memory writes.

Ensure that a formal skill revocation process exists, linked to employee offboarding workflows and incident response playbooks, so that skills installed by departing employees are deprovisioned and credentials associated with compromised skills are immediately revoked.

Risk that skills ported across platforms — OpenClaw to Claude Code to Cursor to VS Code — are not re-validated for security properties of the target format, causing permission manifests, risk tier declarations, and signing metadata present in the source format to be silently stripped in translation, and enabling the same malicious payload to be deployed simultaneously across multiple platforms whose separate scanning and governance systems are unaware of each other's incidents.

Ensure that new skill development adopts a universal skill format that normalises security properties — including permission manifests, risk tier, cryptographic signatures, content hash, and scan status — across all target platforms, with the security metadata re-validated when skills are ported between platform ecosystems.

Ensure that cross-registry threat intelligence sharing is established between major skill registries so that malicious skills detected on one platform trigger automated scanning and removal processes on all other platforms where the same payload may have been deployed.