OWASP-Style Checklist for Agent Skills

Why Agent Skills Are the New Unvetted Supply Chain

In January 2026, security researchers watched daily submissions to a popular skill registry jump from under 50 to over 500 in a matter of weeks — with nothing standing between a one-week-old GitHub account and your agent's credentials. Agent skills have become the first major supply-chain threat to AI ecosystems, and the exploitation is not theoretical.

The scale is documented. The first large-scale empirical study analyzed 31,132 skills and found that 26.1% contain at least one vulnerability, spanning 14 patterns across prompt injection, data exfiltration, privilege escalation, and supply chain risk. A separate Snyk audit of 3,984 skills found 13.4% with at least one critical issue, 76 confirmed malicious payloads, and hardcoded secrets in 10.9% of all skills scanned.

Real campaigns show active exploitation, not just latent risk:

• ClawHavoc: 341 malicious skills uploaded over three days, all delivering Atomic Stealer and targeting exchange API keys, SSH credentials, browser passwords, and crypto wallets.
• A "GIF Creator" skill that silently delivered MedusaLocker ransomware, demonstrated by Cato CTRL in December 2025.
• A malicious code-review skill with 312 GitHub stars hiding instructions in HTML comments — social proof weaponized.

What makes skills structurally riskier than npm or PyPI packages is the permission model. A skill doesn't request capabilities through an OS dialog — it adds natural-language instructions the agent follows using permissions it already has: shell access, file read/write, environment variables full of credentials, persistent memory. As Mondoo puts it, a compromised skill runs code inside an agent that already has your credentials and your environment. Script-bearing skills are 2.12× more likely to be vulnerable than instruction-only ones, and 91% of confirmed malicious skills paired code with prompt injection designed to prime the agent into bypassing its own safety mechanisms.

The ecosystem-level gaps read like a checklist of absences:

• No sandboxing by default — skills inherit the agent's full permission set
• No cryptographic signing or provenance attestation
• No version pinning, lockfiles, or immutable references in any registry
• No mandatory security review, and no equivalent of npm audit
• No visibility into which skills are installed across a team

The hardest problem is that the attack surface is prose. Skills can instruct agents to perform malicious actions in natural language, evading code-level detection entirely — and for an AI agent, everything in a SKILL.md is a potential command, not documentation. Hidden instructions can live in HTML comments and invisible Unicode codepoints that no human reviewer will spot.

This is the gap SkillzBench is being built to close: pinning every skill version to a commit SHA, security-scanning and license-checking each one, and scoring trust on a 0–100 scale so install decisions stop being guesses. The waitlist is open — skills, proven.

The Five Checks Every Skill Must Pass Before You Install It

Installing a skill takes seconds; undoing the damage it causes can take weeks. That asymmetry is why a pre-install checklist matters: roughly 26% of analyzed skills carry at least one vulnerability, and publishing one requires nothing more than a SKILL.md file and a one-week-old GitHub account. Here are the five checks every skill should pass before it touches your agent.

1. Prompt-injection and obfuscation screening. In Snyk's audit of ClawHub, 91% of confirmed malicious skills used prompt injection alongside malicious code — hidden instructions priming the agent to bypass its own safety mechanisms. Scan the SKILL.md for "ignore previous instructions" phrasing, system-message impersonation, hidden HTML comments, and invisible Unicode tag codepoints. Remember that for an agent, everything in the markdown is a potential command.

2. Secrets and exfiltration-channel auditing. A Snyk scan found 10.9% of all ClawHub skills contain hardcoded secrets — real API keys and tokens committed by careless or malicious authors. Flag any skill that echoes credentials, downloads files to unknown domains, or opens external channels like webhooks and APIs it has no business touching.

3. Dependency verification and version pinning. Unverifiable dependencies appear in 21% of malicious skills versus 2.9% overall, and no registry currently offers lockfiles or immutable references. Pin every skill to a commit SHA, reject curl | bash patterns and remote instruction loading, and attest third-party provenance — this is the gap SkillzBench's Verify pillar is being built to close, with commit-SHA pinning and automated security scans on every skill it indexes.

4. Least-privilege scoping and sandboxing at runtime. Skills inherit whatever permissions your agent already has — shell access, file read/write, credentials in environment variables. Script-bearing skills are 2.12× more likely to be vulnerable than instruction-only ones, so scope tool access per task, confine filesystem reach, and enforce a network egress policy. The Frontier Model Forum puts it plainly: damage scales directly with the trust and permissions you grant, so deterministic controls must sit outside the agent's own reasoning loop.

5. Persistence and memory-poisoning checks. The ClawHavoc campaign wrote malicious instructions into agent memory files like SOUL.md and MEMORY.md, surviving both skill removal and reboots. Inspect memory files after install, watch for behavioral drift, and keep an inventory with audit trails of what's installed across your team — a gap most organizations currently can't see at all.

• Screen for injection, obfuscation, and hidden instructions before install
• Audit for hardcoded secrets and suspicious exfiltration channels
• Pin versions to commit SHAs and verify every dependency
• Scope privileges per task and sandbox script-bearing skills
• Check memory files for poisoning and maintain audit trails

No single check catches everything — malicious skills in one study averaged four distinct attack vectors each. But running all five turns an unvetted gamble into a defensible decision, and it's exactly the evaluation pipeline SkillzBench is building so every skill arrives pre-screened with a 0–100 trust score.

What You Can't Check by Hand — and Why Detection Alone Isn't Enough

Even a meticulous manual review of a SKILL.md file can't close the gaps that matter most, because the biggest risks are structural — baked into the ecosystem itself, not the text you're reading. According to Mondoo's ecosystem analysis, no skill registry today offers version pinning, lockfiles, or immutable references, and there is no standard inspection tooling — nothing equivalent to npm audit that would tell you whether a skill has a known problem before you install it.

That means every manual check you perform is a point-in-time snapshot of a moving target. A skill's upstream repository can change the moment after you approve it, and nothing in the current ecosystem will flag the difference. Snyk's research adds two more structural gaps: skills support hot-reload, meaning a compromised skill can be swapped and activated mid-session, after you've already vetted it, and three-tier skill precedence lets a workspace-level skill shadow legitimate functionality (Snyk).

Static analysis has its own hard ceiling. Behavioral verification is still immature, and researchers note that static inspection routinely misses time-delayed payloads and environment-gated triggers — malicious instructions that only fire days later or only when a specific condition is met. The ClawHavoc campaign showed why this matters: malicious skills wrote instructions into agent memory files like SOUL.md and MEMORY.md, enabling persistence that survived reboots, skill removal, and updates.

What you can't easily see by hand:

• Whether the version you reviewed matches the version your agent actually loads — no registry pins skills to a commit SHA
• Instructions hidden in HTML comments or invisible Unicode codepoints inside otherwise clean-looking markdown
• Behavior that only activates under specific environmental conditions, defeating one-time static review
• Changes to a skill after installation, including hot-reloaded swaps mid-session

This is why detection alone is a losing strategy. The Frontier Model Forum warns that "robust agent security should not rely on detection alone" and that "the potential damage from any agent failure scales directly with the level of trust and permissions a user has granted." In other words: the more capable your agent, the more a single missed skill costs you.

The practical response is layered, deterministic control rather than better eyeballing. That's the philosophy behind what SkillzBench is building — pinning every skill version to a commit SHA, re-scanning on upstream changes, and letting users scope exactly which skills and tools each agent can see. Verification has to be continuous and enforced outside the agent's own reasoning loop, because by the time a payload reveals itself, the review you did by hand is already out of date.

Turning the Checklist into a Workflow: From Script-Bearing Risk to Verified Loadouts

A checklist only becomes security when it runs on every install, not when it sits in a wiki. The research points to exactly which controls matter most — and which ones can be automated into a repeatable pipeline.

Start with the highest-leverage decision: instruction-only skills. The first large-scale empirical study of 31,132 skills found that skills bundling executable scripts are 2.12× more likely to contain vulnerabilities than instruction-only ones (OR=2.12, p<0.001). That single filter removes a disproportionate share of risk before any scanning begins.

Next, close the provenance gap. Mondoo's analysis found no skill registry currently offers version pinning, lockfiles, or immutable references — meaning today, "installing a skill" means trusting whatever the upstream repo looks like tomorrow. Pinning every skill to a commit SHA turns a moving target into a fixed, auditable artifact.

Then apply least privilege at runtime. As the Frontier Model Forum puts it, damage from any agent failure scales directly with the trust and permissions granted — and skills inherit everything the agent already has, including credentials and shell access. A verified loadout should scope tools per agent, so a coding agent never sees the filesystem access a docs agent needs.

A working pipeline looks like this:

• Prefer instruction-only skills — the 2.12× vulnerability multiplier makes script-bearing skills a later-phase problem, not a day-one one.
• Pin every skill to an immutable commit SHA at intake, so re-verification is always against a known artifact.
• Scope tools per agent via least-privilege loadouts — the agent sees only what was explicitly enabled for it.
• Re-verify on upstream changes: re-scan and re-benchmark whenever the pinned source moves.

This is the workflow SkillzBench is building: automated scanning, sandboxed benchmarking, and per-agent loadouts delivered through a single MCP server, with a 0–100 trust score that rolls up security, quality, license, maintenance, and community signals. Because Snyk's audit found 13.4% of scanned skills carry a critical issue, no score should ever rest on a single pass — verification has to be continuous, not a one-time gate.

The result is a shift in posture: from "script-bearing risk" to a verified loadout, where every instruction your agent reads has a pinned source, a scanned history, and a scoped permission set.