The Agent Skills Ecosystem in 2026: A Field Guide

The 10x Explosion Nobody Vetted: Why the Skills Ecosystem Has a Trust Problem

In mid-January 2026, ClawHub was receiving fewer than 50 new agent skill submissions per day. By early February, that figure had passed 500 — a 10x explosion in a matter of weeks, according to Snyk's security research. Nobody in that growth curve was checking what was actually inside the packages.

The numbers from Snyk's audit of 3,984 skills are stark. Some 13.4% of skills contain at least one critical security issue, and 36.82% carry a flaw of any severity. The researchers confirmed 76 malicious payloads — credential theft, backdoors, data exfiltration — and eight were still live on clawhub.ai when the report published.

What makes this worse than the early npm and PyPI era is the blast radius. As Snyk's team put it, the skills ecosystem has "a supply chain security problem that mirrors the early days of npm and PyPI — except with unprecedented access to credentials, file systems, and APIs." Publishing a skill requires only a SKILL.md file and a GitHub account one week old. There is no code signing, no security review, and no sandboxing by default.

The attack mechanics are also new. Every confirmed malicious skill contains malicious code patterns, and 91% pair that code with prompt injection that primes the agent to bypass its own safety mechanisms. A malicious skill doesn't just run bad code — it can permanently reshape agent behavior through persistent memory.

• 10.9% of ClawHub skills contain hardcoded secrets — 32% of malicious samples do
• 17.7% of ClawHub skills expose users to third-party content, enabling indirect prompt injection
• 2.9% of ClawHub skills use unverifiable runtime dependencies; that figure jumps to 21% among malicious samples

Even well-intentioned skills create risk. A popular, well-reviewed skill that fetches third-party content can be compromised by that content — as Snyk noted, "the skill author did nothing wrong. The user installed a popular, well-reviewed skill. Yet the agent is compromised." Runtime-fetched instructions even let attackers change a skill's behavior after it has been reviewed, a pattern the researchers called "insecure by design."

Anthropic's own guidance acknowledges the gap, telling users to install skills only from trusted sources and to treat them like installing software. But advice to "audit thoroughly" doesn't scale when submissions grew 10x in weeks and most users lack the tooling to audit anything.

This is the trust layer the ecosystem is missing, and it's the problem SkillzBench is being built to address: pinning every skill to a commit SHA, running security scans and license checks, and scoring trust from security, quality, and maintenance signals — so that "install from a trusted source" becomes something you can actually verify rather than something you have to take on faith. Snyk's verdict stands for now: this isn't theoretical risk, it's an ecosystem already under attack.

How Skills Actually Work: Progressive Disclosure and the Missing Empirical Layer

The most elegant thing about a skill is what you don't see. When an agent starts a session, each installed skill costs roughly 100 tokens of metadata — a name, a description, a trigger — and nothing more until the agent actually needs it.

That's progressive disclosure, the three-stage loading design Anthropic calls the core principle making Agent Skills scalable. Metadata loads at session start, the SKILL.md instruction body (typically under 5,000 tokens) loads only when triggered, and bundled resources or scripts load on demand. According to Anthropic's engineering team, the context bundled into a skill is "effectively unbounded" because files cost zero tokens until accessed — which is how a single agent can host hundreds of skills without bloating its context window.

Skills also sit in a precise layer of the production stack. The emerging convention, articulated in community documentation, runs: MCP for access, tools for actions, skills for behavior. MCP handles connections — auth, transport, tool discovery. Tools are the individual functions an agent invokes. Skills define the workflow: what to do, in what order, with what guardrails.

But here's the gap nobody is closing. Anthropic's own best-practices documentation admits that "Skills act as additions to models, so effectiveness depends on the underlying model" — what works for Opus may need more detail for Haiku. Skill quality, in other words, is a moving target that varies by model. Yet no standardized, model-controlled measurement of whether a skill actually helps exists anywhere in the ecosystem's documentation or research.

The security world has started counting — a Snyk audit of 3,984 skills found 36.82% carry at least one flaw — but nobody is measuring the value side. A skill can be clean, well-licensed, and popular, and still make an agent worse at its job.

The fix is Lift-based benchmarking: run the same model on the same task twice, once with the skill enabled and once without, and publish the difference in percentage points. That isolates the skill's actual contribution while controlling for the model-dependence Anthropic warns about.

This is the empirical layer SkillzBench is building into its Benchmark pillar — sandboxed runs, same model with and without the skill, Lift published in percentage points and always kept separate from trust ratings. Until the ecosystem measures outcomes the way it now measures vulnerabilities, "does this skill help?" remains the one question every installer is asking and no one can answer.

The Threat Model: Malware, Prompt Injection, and 'Insecure by Design'

The most dangerous skill on your agent may be the one that passed review. Snyk's audit of 3,984 skills found that 100% of confirmed malicious skills contain malicious code patterns, and 91% also use prompt injection to prime the agent into executing that code, according to the security research documenting the first coordinated malware campaign against Claude Code users.

This convergence is what makes the skills threat model genuinely new. Traditional package registries never had a prompt-injection analog: a malicious npm package can steal credentials, but it cannot talk its way past your runtime's safety mechanisms. A malicious skill can do both, and because skills inherit full agent permissions — shell access, file system read/write, credential access, persistent memory — a compromised skill can permanently modify agent behavior even after the skill itself is removed.

The subtler problem is that even benign, well-reviewed skills create attack surfaces. Snyk's analysis identified two "insecure by design" vectors:

• Third-party content fetching — 17.7% of ClawHub skills pull external content, enabling indirect prompt injection even when the author "did nothing wrong."
• Runtime-fetched instructions that change skill behavior after review, so a clean audit is only a snapshot in time.
• Unverifiable runtime dependencies — remote execution paths that appear in 21% of malicious samples versus just 2.9% of skills overall.

That last statistic is the basis for a defensible safety boundary: instruction-only skills. A package consisting of SKILL.md plus text references can be read, diffed, and pinned to a commit SHA in full — what you review is what runs. Script-bearing skills cannot offer that guarantee, which is why SkillzBench's launch scope treats instruction-only skills as the verifiable tier and lists script-bearing skills link-out only, with security scanning and version pinning applied to everything it indexes.

The gap is real and acknowledged from the top. Anthropic's own guidance warns users to install skills only from trusted sources and to treat installation "like installing software," while official documentation notes that enterprise content scanning covers claude.ai uploads but not Skills API or Console uploads. Vendor warnings plus absent enforcement is exactly the combination that invites independent verification infrastructure — continuous crawling, re-scanning on upstream changes, and benchmarking in a sandbox rather than trusting a marketplace listing.

None of this means the ecosystem is doomed; it means the ecosystem is early. As Snyk's researchers put it, the current state resembles early package managers before security became a first-class concern. npm survived that era. Skills will too — but only with the trust layer built deliberately.

ctaText: See how SkillzBench verifies and benchmarks agent skills — join the waitlist socialProofText: Skills, proven. Independent testing from SkillzBench, AIQ Labs' agent-skills lab.

The Field Guide: Five Practices for Choosing Skills You Can Trust

You wouldn't npm install a package from an anonymous account without checking it — yet that's exactly what most teams are doing with agent skills, except these packages inherit shell access, credentials, and file systems. The good news is that a small set of habits closes most of the gap.

Practice 1: Pin versions to commit SHAs. In a market where daily submissions grew from under 50 to over 500 in weeks, "latest" is a moving target. A skill you reviewed yesterday can be a different skill today. Pinning each skill to a specific commit SHA gives you an immutable record of exactly what you audited.

Practice 2: Security-scan before use. Snyk's audit of nearly 4,000 skills found that 36.82% carry at least one security flaw, and 13.4% contain a critical issue. Don't assume platform protection covers you — Anthropic's own documentation confirms its enterprise content scanning applies to claude.ai and Claude Cowork uploads, but not to Skills API or Console uploads. The verification gap is real even inside a single vendor.

Practice 3: Check the license. A skill that works beautifully and carries an incompatible license is a liability, not an asset. License checks belong in the same gate as security scanning, before anything reaches a production agent.

Practice 4: Verify maintenance signals. Who wrote it? When was it last updated? Is the repository active? Anthropic itself recommends installing skills only from trusted sources and treating installation "like installing software" — which means looking at the author, not just the skill.

Practice 5: Re-scan on upstream changes. This is the practice most teams skip, and it's the most dangerous one to ignore. Snyk found that runtime-fetched instructions let attackers modify skill behavior after review — meaning a one-time audit is never enough. Continuous tracking, re-scanning, and re-benchmarking is the only honest posture in a 10x-growth market.

Two structural realities shape how these practices get applied:

• Skills don't sync across surfaces. Each surface — claude.ai, the API, Claude Code — requires separate upload and management, with different sharing models per surface.
• Per-agent loadouts change the security model. When the agent only sees what was explicitly chosen for it, curation becomes your primary control — every enabled skill is a deliberate trust decision.

This is the philosophy SkillzBench is being built around: pin every version to a commit SHA, scan and license-check before anything ships, and continuously re-verify as upstream skills change. Skills, proven — because in this ecosystem, trust should never be assumed.

What Comes Next: Verification and Benchmarking Infrastructure for Skills

Every hypergrowth software ecosystem eventually gets its trust layer. npm got audit trails and code signing after supply chain attacks forced the issue. The agent skills ecosystem is at that same inflection point now — and the infrastructure being built around it in 2026 tells you exactly where things are headed.

Commercial infrastructure is already forming. Composio's MCP Gateway offers a single endpoint for 1,000+ integrations with team-based access controls and audit logs, and skill-creation meta-tools are proliferating across the ecosystem. Meanwhile, the skills themselves are reaching into serious territory: multi-agent orchestration skills like "great_cto" now span 13 compliance frameworks including GDPR, PCI-DSS, HIPAA, and ISO 27001. When agents handle regulated workflows, "trust me, it works" stops being an acceptable quality bar.

Anthropic's roadmap points the same direction. The company has stated it hopes to enable agents to "create, edit, and evaluate Skills on their own, letting them codify their own patterns of behavior into reusable capabilities." Self-authoring agents will make the trust problem exponentially harder — you can't manually review what an agent writes at 10x the current submission rate. ClawHub daily submissions already jumped from under 50 in mid-January 2026 to over 500 by early February, and Snyk's audit found 13.4% of scanned skills carry at least one critical security issue.

That's why the natural next layer is independent verification and benchmarking — five functions no single vendor is performing today:

• Discover — continuously crawling and deduplicating skills from GitHub so the ecosystem has a real inventory.
• Verify — pinning versions to commit SHAs, security-scanning, license-checking, and quality-judging every skill.
• Benchmark — testing each skill in a sandbox with the same model, with and without the skill, and publishing the Lift in percentage points.
• Equip — one MCP server plus per-agent loadouts, so each agent only sees the skills and tools you actually chose.
• Stay current — tracking upstream changes, re-scanning, and re-benchmarking, since runtime-fetched instructions let attackers modify skill behavior after review.

This is the gap SkillzBench is being built to fill: an independent testing lab where trust scores come from security, quality, license, maintenance, and community signals — with Lift always shown separately, and money never touching scores. Launch scope is deliberately conservative: instruction-only skills, with script-bearing skills listed link-out only, because unverifiable runtime dependencies appeared in 21% of malicious samples in Snyk's research.

The verification layer matters even for well-intentioned users. Anthropic's own guidance is to install skills only from trusted sources and treat them "like installing software" — but its enterprise content scanning doesn't cover Skills API or Console uploads, leaving a gap that vendor infrastructure alone won't close.

For readers positioning themselves now: authors should build verifiable track records before marketplaces demand them; teams should adopt per-agent loadouts and allowlists before an audit forces the question; and everyone should demand Lift numbers, not star ratings. The ecosystems that mature fastest are the ones where verification becomes a first-class concern — and that moment, by every signal, is now.