An agent skill is a folder of instructions, scripts and resources that an AI agent discovers and loads on demand. Anthropic introduced the concept in October 2025 and published the specification as an open standard on 18 December 2025, stewarded through the Agentic AI Foundation.
Adoption was unusually fast. By mid-2026 roughly 40 products supported the format, including Claude Code, Cursor, GitHub Copilot, VS Code, Codex, Amp, Letta and OpenCode. A skill written for one agent runs unmodified in a competitor’s.
The design principle is progressive disclosure. At startup, an agent pre-loads only the name and description of every installed skill. When a task matches, it loads the full SKILL.md. Only when sub-tasks require it does the agent reach deeper resources or execute code.
That design is efficient, and it creates the security surface. Every installed skill’s description sits in the model’s context at all times, whether or not the skill is used — and descriptions are natural language the model treats as guidance.
Agent skills security therefore spans four layers at once: the prose instructions, the bundled executable code, the registry the skill came from, and the permissions the skill inherits from its host agent.
Key Takeaways
- Standards for agent skills security now exist. OWASP’s Agentic Skills Top 10 documents ten risk categories with prescribed mitigations. Registry adoption of those mitigations is the part that has not happened.
- Snyk’s audit of 3,984 skills found 36.82% contained at least one security flaw, 13.4% at least one critical issue, and 76 with active malicious payloads.
- The ClawHavoc campaign placed 1,184 malicious skills across 12 publisher accounts sharing one command-and-control address. At peak infection, five of the seven most-downloaded skills were confirmed malware.
- Publishing to an open skill registry has typically required a SKILL.md file and a GitHub account at least one week old. No signing, no review, no sandbox by default.
- Signing is necessary but not sufficient. OWASP’s own guidance is explicit that a signature proves authorship, not safety.
Quick Navigation
- Why Agent Skills Security Failed So Quickly
- The Incident That Defined Agent Skills Security
- What the Agent Skills Security Audits Found
- Agent Skills Security Standards Now Exist
- Gap 1: No Provenance at Publish Time
- Gap 2: Permissions Checked at the Wrong Layer
- Gap 3: Scanners Miss Natural-Language Payloads
- Gap 4: No Revocation or Update Discipline
- Why Signing Alone Will Not Fix Agent Skills Security
- Comparing Registries on Agent Skills Security
- An Agent Skills Security Checklist
- Primary sources
- Frequently Asked Questions
Why Agent Skills Security Failed So Quickly
Package ecosystems took a decade to build provenance controls. npm and PyPI have signing, transparency logs, lockfiles and revocation because each was added after an incident forced it.
Skill registries started from zero and scaled faster than any of them.
ClawHub, the registry serving the OpenClaw agent framework, held 2,857 skills in early February 2026 and more than 70,000 by June. OpenClaw itself went viral in late January, crossing 145,000 GitHub stars and 100,000 users within two weeks.
The publishing requirement during that period was a SKILL.md file and a GitHub account at least one week old. No code signing. No security review. No sandbox by default.
Three properties made the resulting exposure unusually severe.
Skills execute with the host agent’s full permissions. A malicious skill gains whatever the agent has — API keys, SSH credentials, wallet files, browser data, shell access.
The payload can be prose. Unlike a package, a skill can attack purely through natural-language instructions in its markdown, with no code to scan.
Portability spreads compromise. The same skill format runs across registries, so a malicious skill ports from one marketplace to another unchanged.
This is the distinction between systems that generate text and systems that act, explored in agentic AI versus generative AI — and skills are precisely where agency gets granted.
The Incident That Defined Agent Skills Security
February 2026 compressed what usually takes years.
Koi Security identified a coordinated wave of malicious uploads on ClawHub beginning 1 February. Its audit of all 2,857 skills then on the registry found 341 malicious.
Antiy Chert’s post-incident analysis confirmed the fuller scope: 1,184 malicious skills across 12 publisher accounts, sharing a single command-and-control address, delivering Atomic Stealer against macOS wallets, SSH keys and browser credentials. The campaign is now referred to as ClawHavoc.
The detail that should worry anyone running an open registry: at peak infection, five of the seven most-downloaded skills were confirmed malware. Download count functioned as a trust signal and was pointing at the wrong things.
Related disclosures landed in the same window. Check Point Research documented remote code execution in Claude Code through poisoned repository configuration files (CVE-2025-59536 and CVE-2025-21852). Oasis Security disclosed a WebSocket hijacking issue tracked as CVE-2026-28363. Microsoft Defender issued an advisory characterizing OpenClaw as untrusted code execution with persistent credential access.
One widely reported user incident illustrates the practical stakes: an OpenClaw bot granted iMessage access sent more than 500 messages to the owner’s contacts before he regained control.
ClawHub has since implemented automated scanning and partnered with VirusTotal. The broader ecosystem largely has not.
What the Agent Skills Security Audits Found
Two audits give the clearest quantitative picture, and they disagree in an instructive way.
Snyk’s ToxicSkills audit, February 2026, scanned 3,984 skills across ClawHub and skills.sh:
- 1,467 skills (36.82%) contained at least one security flaw
- 13.4% contained at least one critical-level issue
- 76 were confirmed malicious with active payloads
- 280+ leaked credentials
A larger subsequent analysis of 42,447 skills found 26.1% carrying at least one vulnerability.
The gap between 36.82% and 26.1% is worth noting rather than papering over. Different populations, different scanning methodologies, different definitions of “flaw.” Both figures indicate that roughly a quarter to a third of published skills have problems, and neither should be quoted as a precise measurement.
The more actionable number is the malicious count. Confirmed active payloads ran at roughly 1.9% of the Snyk sample. Most flawed skills are badly written rather than hostile — but at registry scale, 1.9% of 70,000 is a large absolute number.
Agent Skills Security Standards Now Exist
Here is the correction to a claim still circulating widely: it is no longer true that no standards exist.
OWASP’s Agentic Skills Top 10 (AST10), authored by Ken Huang and published as an OWASP Incubator Project during 2026, is the first comprehensive security framework aimed specifically at the skill layer — the markdown file, its frontmatter, its bundled scripts, its registry, and its inherited permissions.
| ID | Risk | Severity | Key mitigation |
|---|---|---|---|
| AST01 | Malicious Skills | Critical | Merkle root signing, behavioural scanning |
| AST02 | Supply Chain Compromise | Critical | Transparency logs, dependency pinning |
| AST03 | Over-Privileged Skills | High | Least-privilege manifests, runtime enforcement |
| AST04 | Insecure Metadata | High | Schema validation, sandboxed loading |
| AST05 | Untrusted External Instructions | High | Source inventory, content pinning, rescanning |
| AST06 | Weak Isolation | High | Containerisation, process isolation |
| AST07 | Update Drift | Medium | Immutable pinning, hash verification |
| AST08 | Poor Scanning | Medium | Multi-tool pipeline, semantic analysis |
| AST09 | No Governance | Medium | Skill inventories, audit logging |
| AST10 | Cross-Platform Reuse | Medium | Universal format, platform validation |
Publication dates cited across sources vary between March, April and a version 1.0 milestone in August 2026, so treat the exact date with caution. The framework itself is live and citable.
The real gap is not the absence of standards. It is that registries have not implemented them. Merkle root signing, transparency logs and revocation are prescribed and largely unbuilt. That distinction matters, because “nobody knows what to do” and “the fix is known and unadopted” call for completely different responses.
Gap 1: No Provenance at Publish Time
The first gap is the one OWASP ranks most critical.
Skill registries generally lack the provenance controls that took npm and PyPI a decade to build: no signing, no transparency log, no lockfile, no revocation.
Without provenance, you cannot answer three basic questions. Who published this? Has it changed since I reviewed it? Can it be withdrawn if the publisher is compromised?
OWASP’s prescribed fix is Merkle root signing at the registry level, treating every publication as a cryptographically verifiable event — the same approach that hardened certificate transparency for browsers.
The implementation detail in OWASP’s whitepaper deserves attention because it is easy to get wrong. A signature must bind to a resolvable, revocable publisher identity — a key ID plus a publisher identifier such as a domain or did:web, plus a published verification key — rather than a bare key. And the public key must be resolved from a trust store keyed by publisher identity, never accepted from the skill payload itself, or a self-signed attacker key verifies successfully.
Gap 2: Permissions Checked at the Wrong Layer
The second gap explains why over-privileged skills are so common.
Permission is typically checked at the tool call, not at the intent. A skill is either allowed to read files or it is not. Nothing evaluates whether this particular read fits what the skill is supposed to do.
OWASP’s illustrations are pointed: a weather assistant that reads the entire .env file, or a skill cleared for SELECT that gets talked into DELETE.
Both actions pass the permission check. Both are wildly outside the skill’s stated purpose.
The prescribed mitigation is least-privilege manifests with runtime enforcement — declaring what a skill needs, then enforcing that declaration at execution rather than trusting it at install. Roughly 280 skills in the Snyk sample leaked credentials, and most did so through access they were nominally allowed to have.
Gap 3: Scanners Miss Natural-Language Payloads
The third gap is the most technically interesting, and it undercuts the industry’s default response.
When registries respond to incidents, they add scanning. ClawHub did exactly this, partnering with VirusTotal. That helps against executable payloads.
It does considerably less against prose.
Adversa AI contributed an eight-scanner bypass study cited in AST08, demonstrating pattern-matcher bypass via natural-language injection. A separate proof of concept referenced under AST05 reportedly bypassed all scanners tested.
The reason is structural. A malicious skill does not need code. It can carry instructions in its markdown that steer the agent toward harmful behavior, and there is no signature to match because the payload is a sentence.
OWASP’s answer is semantic and behavioral analysis in a multi-tool pipeline rather than pattern matching alone. That is meaningfully harder to build, and it is why “we scan our registry” should prompt a follow-up question about what kind of scanning.
Gap 4: No Revocation or Update Discipline
The fourth gap concerns what happens after installation.
Skills update. Most users never re-review an updated skill, because approval happened once at install. OWASP categorizes this as update drift, with the ClawJacked case and patch-lag exploitation as evidence.
Three controls close it, and almost nobody applies all three.
Immutable pinning. Pin to a content hash, not a version tag or a branch.
Hash verification at load. Confirm the skill you are loading is the one you reviewed.
Change alerting. Treat a modified skill description as equivalent to a dependency update requiring review, not as a silent refresh.
Absent revocation infrastructure, there is also no mechanism to withdraw a skill once a publisher is found compromised. A compromised publisher on npm can be revoked. On most skill registries, there is nothing to revoke.
Why Signing Alone Will Not Fix Agent Skills Security
This is the nuance most commentary skips, and OWASP states it directly in its own whitepaper.
A signature proves authorship, not safety. A verified publisher can still ship malicious content. Signing composes with behavioral scanning and reputation; it does not replace them.
The ClawHavoc campaign makes the point concretely. Twelve publisher accounts operated the campaign. Under a signing regime, all twelve could have signed their skills perfectly validly. Signatures would have proved that the malware came from exactly the accounts it came from.
What signing actually buys is attribution and revocability. Once you know which publisher shipped what, you can revoke a compromised key, trace the blast radius, and stop the next upload from that identity.
That is genuinely valuable — and it is a containment control, not a prevention control. The layered position: signing for attribution, behavioral scanning for detection, least-privilege manifests for blast radius, and human approval on high-privilege installs where automation has not caught up.
Comparing Registries on Agent Skills Security
Registries differ enormously, and the differences are not advertised prominently.
| Registry | Approximate catalogue | Security posture |
|---|---|---|
| Anthropic official directory | Small | Manually curated, verified |
| Agensi | Smaller, curated | Reviewed before listing, multi-point scan |
| SkillHub | 7,000+ | Automated AI evaluation |
| Skills.sh | Hundreds of thousands | Builder-side auditing |
| ClawHub | 70,000+ | Automated scanning added post-incident |
| SkillsMP | ~1.9 million | None — scraped from public GitHub |
Catalogue size and security posture run in opposite directions, which is the trade-off worth understanding before choosing a source.
There is also a quality argument for curation independent of security. Analysis indicates curated skills raise agent task pass rates by around 16 percentage points on average. Curation is not only a safety tax.
For anyone mapping where skills sit in a broader threat model, the five hidden layers of the AI attack surface covers the surrounding surface.
An Agent Skills Security Checklist
Ordered by what reduces exposure fastest.
Inventory installed skills. You cannot govern what you cannot enumerate. Include skills individual developers installed on their own machines.
Read the description, not the label. The description enters model context for every installed skill at every session start. Read the raw frontmatter.
Pin to content hashes. Not tags, not branches. Then alert on change.
Assume host-level permissions. A skill runs with whatever the agent has. If your agent holds production credentials, so does every skill installed in it.
Prefer curated sources for anything privileged. Use open registries for experimentation, curated ones for anything touching real systems.
Sandbox by default. Skills that execute code should run in a container, not on the host.
Check for the lethal trifecta. OWASP flags the dangerous combination directly: access to private data, exposure to untrusted content, and an ability to communicate externally. Break any one of the three and most exfiltration paths close.
Primary sources
- OWASP Agentic Skills Top 10
- Agent Skills open standard
- HiddenLayer — Malicious Skills in Agentic AI
- Cloud Security Alliance — Claude Agent Skills risks for CISOs
Audit percentages vary substantially by methodology and population; ranges are shown rather than single figures. Publication dates for AST10 differ across sources and are noted inline. Corrections with a primary source are welcome.
Frequently Asked Questions
Are there any standards for agent skills security?
Yes. OWASP’s Agentic Skills Top 10 documents ten risk categories with prescribed mitigations including Merkle root signing, transparency logs and least-privilege manifests. The gap is registry adoption, not the absence of a framework.
What percentage of published skills are malicious?
Confirmed active payloads ran at roughly 1.9% in Snyk’s 3,984-skill sample. A far larger share — between 26% and 37% depending on the study — contain at least one security flaw without being deliberately malicious.
Does a signed skill mean a safe skill?
No. OWASP’s guidance is explicit that a signature proves authorship rather than safety. A verified publisher can still ship malicious content, so signing must compose with behavioral scanning and reputation.
Can antivirus scanning catch malicious skills?
Partially. It catches executable payloads and misses prose attacks. Research demonstrates pattern-matcher bypass via natural-language injection across multiple scanners, which is why semantic and behavioral analysis is prescribed instead.
Which registry should I use?
For anything touching production credentials, prefer curated registries with pre-listing review. Open registries with millions of scraped entries are appropriate for experimentation in sandboxed environments only.
Keep reading
Here are the latest posts from the blog.
Agent Skills Security: 4 Hidden Gaps in Every Registry
AI Red Teaming: 4 Hidden Flaws in a Passing Test
Memory Bandwidth: The 4 Hidden Limits of AI Chips
