Script-Bearing vs Instruction-Only Skills: The Security Difference

The 2.12x Problem: Script-Bearing Skills Are Statistically Riskier

If you install a skill that bundles executable scripts, the odds it contains a security vulnerability are more than double those of an instruction-only skill. That's the headline finding from the first large-scale empirical security analysis of the agent skills ecosystem, which found script-bearing skills are 2.12x more likely to contain vulnerabilities (OR=2.12, p<0.001).

The study analyzed 31,132 skills and found 26.1% carried at least one vulnerability. Among script-bearing skills, two patterns dominate: data exfiltration appears in 13.3% of skills, and privilege escalation in 11.8%. In plain terms, scripts are where sensitive data quietly leaves your machine — and where skills try to grab permissions they shouldn't have.

Why do scripts raise the risk so sharply? A few reasons stand out:

• Scripts are executable code, so they can hide obfuscated payloads like base64-encoded exfiltration commands that scanners struggle to flag.
• A skill inherits your agent's full permissions — shell access, file system, credentials, messaging — so a single malicious script touches everything at once.
• Publishing requires almost nothing: a SKILL.md file and a week-old GitHub account, with no code signing or security review by default.

And the ecosystem is growing faster than anyone can vet it. Snyk's audit documented daily skill submissions jumping from under 50 in mid-January 2026 to over 500 by early February — a 10x increase in weeks. The result looks like early npm or PyPI before security became a first-class concern, except with higher default privileges and no analog for detecting prompt injection.

One caveat matters here: instruction-only skills are not automatically safe. Snyk found 91% of confirmed malicious skills use prompt injection alongside malicious code, and researchers demonstrated that malicious instructions alone can achieve code-execution-grade impact. Scripts raise the odds of vulnerabilities, but the instruction layer itself is a proven attack vector.

So what should you actually do with the 2.12x number? Treat it as a risk signal, not a safety guarantee. When a skill ships scripts, it deserves extra scrutiny — a security scan, a pinned version, a sandboxed test run — before it touches your agent's credentials or filesystem. That's exactly the gap SkillzBench is building for: every skill version pinned to a commit SHA, security-scanned, and tested in a sandbox, with a 0–100 trust score so you don't have to read the research yourself. Until vetting at publish time becomes the norm, the burden of verification falls on whoever installs the skill — and 26.1% vulnerability prevalence means skipping that step is a real gamble.

Why Instruction-Only Skills Are Not Safe Either

If scripts are the risk, the obvious move is to favor instruction-only skills — except that assumption collapses under scrutiny. The instruction layer is itself a weapon, and the data proves it.

Snyk's audit of confirmed malicious skills found that 91% use prompt injection alongside malicious code, meaning the two attack vectors converge rather than separate. Instructions alone can reach code-execution-grade impact: CVE-2025-68664, known as "LangGrinch," carries a CVSS score of 9.3 and enabled remote code execution through malicious instructions injected via LLM response fields — no explicit code exploit required. Even MCP tool descriptions, which are pure instruction content, can be weaponized through tool poisoning, rug pulls, and cross-origin escalation.

The deeper problem is structural. Skills inherit full agent permissions regardless of type:

• Shell access and file system read/write
• Credentials stored in environment variables and config files
• Messaging ability across email, Slack, and WhatsApp
• Persistent memory that survives across sessions

Unlike traditional packages, skills are not isolated, which is why researchers describe them as executing with implicit trust and minimal vetting. Multi-agent setups widen the gap further: 82.4% of 17 state-of-the-art LLMs executed malicious commands from peer agents that they would refuse from direct user input, a trust gap that cannot be patched through prompt engineering alone.

The honest conclusion is that the real security boundary is not "scripts versus instructions" — it is whether a skill has been vetted, sandboxed, and version-pinned at all. That is the gap SkillzBench is built to close: pinning every version to a commit SHA, security-scanning, license-checking, and testing skills in a sandbox, with a 0–100 trust score that keeps security signals separate from Lift and untouched by advertising money.

The Real Boundary: Vetted vs Unvetted, Not Scripts vs Instructions

So which skill type should you trust? Neither — and the data proves it. The real security boundary runs between vetted and unvetted skills, not between scripts and instructions.

The 2.12x finding is real, but it's a risk multiplier, not a safety guarantee. Skills bundling executable scripts are 2.12x more likely to contain vulnerabilities than instruction-only skills, according to a large-scale analysis of 31,132 agent skills. But that leaves roughly half of vulnerable skills in the instruction layer itself.

Instruction-only skills are a primary attack vector. Snyk's ToxicSkills audit found that 91% of confirmed malicious skills use prompt injection while 100% contain malicious code patterns — the two vectors converge, with injections priming agents to accept code safety mechanisms would otherwise reject. The researchers concluded that the ecosystem resembles early npm and PyPI, but is worse in key ways: higher default privilege, prompt injection with no analog in code-based detection, and persistence through agent memory (Snyk).

The npm/PyPI parallel is instructive because the missing controls are the same ones that eventually secured package registries. AI skill registries today lack code signing, standardized SBOMs, version pinning, and provenance verification — baseline controls for mature package ecosystems (Alice). Publishing a skill requires only a Markdown file and a week-old GitHub account. That gap is already being exploited: in February 2026, the first coordinated malware campaign targeting Claude Code and OpenClaw users was documented, with 76 confirmed malicious payloads including credential theft, backdoors, and data exfiltration — and 8 malicious skills remained publicly available at publication. OWASP has responded by launching the Agentic Skills Top 10 (AST10), the first comprehensive security framework for AI agent skills.

The mitigation consensus across sources is consistent:

• Sandbox testing: run untrusted skills in a Docker container, VM, or disposable environment before ever letting them near production agents.
• Deterministic permission controls: enforce trust boundaries in code surrounding the LLM, since models cannot reliably enforce them themselves — capability-based permission systems and rule whitelisting, not prompt engineering.
• Mandatory vetting: security scanning, license checks, and version pinning before a skill earns any trust at all.

This is exactly the standard SkillzBench is being built around: every skill version pinned to a commit SHA, security-scanned and license-checked, then tested in a sandbox with the same model with and without the skill — and a 0–100 trust score derived from security, quality, license, maintenance, and community signals, with money never touching scores. Whether a skill carries scripts or instructions matters for risk assessment. Whether it's been vetted matters for whether you install it.

How to Choose Skills Safely: A Practical Checklist

A skill with no scripts can still steal your credentials, and a script-bearing skill is 2.12x more likely to carry a vulnerability than an instruction-only one. Safe adoption means checking both layers, not trusting either by default.

Start with what the skill actually bundles and what your agent will grant it. Skills inherit full agent permissions — shell access, filesystem read/write, credentials in environment variables, messaging, and persistent memory. Before installing anything, open the package and confirm whether it ships executable scripts or only instructions, then ask which of those permissions the skill genuinely needs.

• Inspect the bundle: read the manifest and any scripts, and note every external fetch, download, or credential reference.
• Prefer pinned versions: a commit-SHA pin locks the exact code you reviewed, so later edits cannot silently change behavior.
• Sandbox first runs: test untrusted skills in a disposable container or VM before they touch real files or accounts.
• Load least privilege: give each agent only the skills and tools that job requires, never a blanket install.
• Use trust signals: security, quality, license, and maintenance history act as a decision shortcut when you cannot read every line.

Vetting is not optional, because the ecosystem is already under attack. A Snyk audit of 3,984 skills found 13.4% carry at least one critical security issue, and 91% of confirmed malicious skills pair malicious code with prompt injection. That overlap is the point: instructions alone can be weaponized, so "no scripts" never means "safe."

This is what SkillzBench is building toward — pinning every version to a commit SHA, security-scanning and license-checking each one, and benchmarking skills in a sandbox with the same model, with and without the skill, so the Lift is published in percentage points. A 0–100 trust score from security, quality, license, maintenance, and community signals gives non-technical readers a shortcut, and per-agent loadouts mean your agent only ever sees what you chose. The directory, the MCP connector, benchmarks, and alerts are all free — join the waitlist at skillzbench.com.