Trust and Verification: The Bottleneck of Every Skill Marketplace

Installing a skill feels lightweight. You read a description, you like what it promises, you click install, and an agent starts running it against your codebase — sometimes with your credentials, sometimes with write access to your files, sometimes with the ability to shell out and run arbitrary commands. It's easy to forget, in the moment, that you just granted a stranger's code the same trust you'd extend to a vetted dependency, without the years of scrutiny that dependency probably went through.

That gap between how lightweight installing a skill feels and how much access it actually grants is the single biggest unsolved problem in this category, and the numbers back up why it deserves to be treated as urgent rather than theoretical. A 2026 audit of more than 2,600 MCP servers — the adjacent tool-plugin ecosystem that many skills lean on for live system access — found 82% vulnerable to path traversal and 67% vulnerable to code injection. Those aren't obscure, hard-to-exploit edge cases. Path traversal and code injection are two of the oldest, best-understood vulnerability classes in software security, and a majority of a fast-growing, widely-installed ecosystem is still shipping them.

Why This Category Is Structurally Prone to It

It would be comforting to write this off as a maturity problem that time will fix on its own — a young ecosystem hasn't caught up to security best practices yet, give it a few years. That's partly true, but it undersells a structural issue that won't resolve just by waiting: the format that made skills so easy to write and share, described earlier in this series, is the same format that makes them easy to write insecurely.

SKILL.md's entire appeal is that a plain markdown file plus optional scripts requires no schema validation, no build step, no gatekeeping to publish. That's exactly why it won as a portable format across more than 20 agents. But "no gatekeeping to publish" and "no gatekeeping to verify safety" are the same sentence from a different angle. A markdown file can describe a completely benign procedure while an attached script does something the description never mentions, and nothing in the format itself catches that mismatch. The openness that made skills easy to create is the same openness that makes skills easy to weaponize.

What "Verification" Actually Has to Cover

Loose talk about "trust and safety" in this category tends to flatten several genuinely different risks into one vague worry, which makes the problem harder to solve because nobody's solving the same thing. It's worth separating them.

There's the malicious-by-design risk: a skill that intentionally does something harmful — exfiltrates credentials, plants a backdoor, quietly modifies files outside its stated scope. This is rare in absolute terms but catastrophic when it happens, and it's the risk most people picture when they think "marketplace security."

There's the vulnerable-by-accident risk, which the MCP audit numbers actually speak to most directly: a well-intentioned creator ships a skill with a real security flaw — insufficient input sanitization, an overly permissive file path, a script that trusts user input it shouldn't — not because they meant harm, but because writing genuinely secure code is hard and most skill creators aren't security engineers. This is the far more common failure mode, and it's the one path traversal and code injection numbers are mostly describing.

And there's the scope-creep risk: a skill that does exactly what it says, safely, but asks for far more access than the task actually requires — a formatting skill that wants full filesystem write access, say, when it only ever needs to touch one file type. This one doesn't show up in a vulnerability scan at all, because nothing is technically broken. It's a design failure, not a security bug, and it's arguably the hardest of the three to catch systematically because it requires judgment about what a skill should need, not just a scan for known-bad patterns.

A marketplace that only screens for the first risk — the deliberately malicious case — while ignoring the second and third is solving the easy, rare problem and leaving the common, structural ones untouched.

Why Curated Marketplaces Have an Actual Answer Here

This is where the earlier piece on 70/30 revenue splits connects directly to security. A marketplace that takes a cut of every sale has a funding mechanism to run real verification — static analysis on submitted scripts, sandboxed execution testing before a skill goes live, a review process for anything requesting broad filesystem or network access — that a free-for-all GitHub listing simply doesn't have the economics to support. Nobody's paying for the review, so nobody funds the review, and the MCP ecosystem's numbers are a fairly direct consequence of exactly that dynamic: a mostly free, mostly unmediated distribution model with no structural incentive for anyone to pay for the unglamorous work of security review.

That's not an argument that curated marketplaces are automatically safe — plenty of curated platforms in other categories have shipped vulnerable products despite review processes, and a review process is only as good as the people and tooling actually running it. But it is an argument for why the marketplace model has a shot at solving this where a purely open, ungated distribution model structurally can't: someone has to be paid to look, and in an open model, nobody is.

What a Reasonable Verification Bar Looks Like Right Now

Given where the category actually stands in 2026, a few concrete practices separate marketplaces taking this seriously from ones treating it as a marketing checkbox. Scripts attached to a skill should be scanned for the exact vulnerability classes the MCP audit flagged — path traversal and injection are well-understood enough that automated tooling catches a meaningful share of both. Skills requesting broad or unusual permissions relative to their stated task should get manual review, not automatic approval, because permission scope-creep is precisely the failure mode that automated scanning misses. And critically, a skill's actual behavior — what its scripts do — should be checked against what its description claims, because the gap between the two is where the malicious-by-design risk hides most effectively.

None of this is exotic. It's the same discipline that mature software ecosystems apply to package registries and browser extensions, applied to a newer category that happens to move faster and carry higher-stakes access — agents with write permissions to real codebases, real credentials, sometimes real production systems.

The category's growth curve is not going to wait for the security problem to get solved first — buyers will keep installing skills, and creators will keep shipping them, audit numbers or no audit numbers. The marketplaces that build a real verification layer now, before a high-profile incident forces the issue, are the ones that end up owning the trust that ultimately decides which platform wins this category. Trust, once lost publicly in a category this new, is expensive to rebuild — expensive enough that getting ahead of it is worth almost any near-term cost.

Part of the "The Skill Economy" series on aiskill.market.