Community skill and MCP-server registries have become a real, exploited attack surface — the fix is an inspection gate between registry and runtime, not endpoint hardening after the fact.
Table of Contents #
If your team has started pulling “skills” into Claude, OpenClaw, or any MCP-connected agent from a community registry, you’ve quietly added a new dependency tree to your production system — one that installs like an npm package but runs with the combined reach of natural-language instructions and executable code. Most teams are treating that install the way they’d treat npm install some-utility: check the star count, skim the README, ship it. That’s the wrong trust model, and the evidence that it’s already being exploited at scale is now public.
The problem isn’t theoretical. Between late January and early February 2026, a campaign researchers named ClawHavoc uploaded 1,184 malicious skills to ClawHub, the marketplace for the OpenClaw agent framework. By the time Antiy CERT finished its post-incident analysis, roughly 900 of the platform’s 4,500 skills — about one in five — had been weaponized, and five of the seven most-downloaded skills at peak infection were confirmed malware. The payloads delivered Atomic Stealer (AMOS), a macOS-targeted credential harvester built to pull crypto wallets, SSH keys, and browser sessions off developer machines. This wasn’t a fringe registry with three users; it was the default place engineers went to extend their agents.
That incident forced a reckoning that’s still playing out in the tooling layer, and it’s the reason this is now an architecture decision, not a hygiene reminder.
The Skill Registry Is a New Dependency Tree #
A “skill” is a bundle of markdown instructions and, increasingly, executable code that an agent loads into its context and runs with whatever tool permissions the agent session already has. That combination is what makes it a different risk class from a library import. A malicious npm package can only do what its code does. A malicious skill can do that and manipulate the agent’s own reasoning through embedded natural-language instructions — jailbreak phrasing, hidden directives, false claims about what a tool call will do — stacked on top of a payload.
Snyk’s ToxicSkills audit, published after scanning 3,984 skills pulled from ClawHub and skills.sh, quantified this: 13.4% of all scanned skills (534 of 3,984) contained a critical-level security issue, 36.8% had at least one flaw of any severity, and 91% of the confirmed malware combined a language-based jailbreak with an executable payload in the same package. That last number is the architecturally important one. It means the attack surface spans two domains that most security tooling still treats separately — static code analysis on one side, prompt-injection defenses on the other — and the exploit lives in the seam between them.
The pattern isn’t limited to skills specifically. Enterprises running MCP servers have the same exposure one layer down: over 42,000 OpenClaw instances were found publicly exposed via unauthenticated MCP endpoints, leaking API keys, Slack credentials, and chat histories. The mcp-remote package carried a remote-code-execution vulnerability (CVE-2025-6514) across more than 437,000 downloads before it was patched. And the first tracked malicious-MCP-server supply-chain incident — a poisoned postmark-mcp package on npm — silently BCC’d every processed email to an external domain. Skills, MCP servers, and the registries that distribute them are one continuous supply chain, and until recently, none of it had a vetting layer equivalent to what container registries or package managers have had for a decade.
Why Standard AppSec Scanning Misses This #
The reason this gap persisted isn’t negligence — it’s that the two halves of the risk don’t show up to the same scanner. Static analysis tools trained on code vulnerabilities will flag a reverse shell in a Python subprocess call but have no model for “this markdown file instructs the agent to exfiltrate credentials if it ever sees a file named .env.” Prompt-injection classifiers built for chat inputs choke on legitimate technical language — a skill that says “run this diagnostic script with elevated permissions” is indistinguishable, to a naive classifier, from an attacker’s identical phrasing, which is exactly why false-positive rates on injection detection stay stubbornly high in production. Treating skill review as either a code-security problem or a content-moderation problem misses the cases where the exploit needs both halves to work, which per Snyk’s data is nine times out of ten.
OWASP formalized this gap in August 2026 with version 1.0 of the Agentic Skills Top 10, which names ten risk classes specific to the layer where agents discover, load, and execute reusable instructions: malicious skills, tool misuse, identity and privilege abuse, agentic supply-chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents. It’s a useful checklist, but a checklist doesn’t stop an install — it tells you what to build a gate against.
What’s Emerging: The Inspection Gate Pattern #
The clearest evidence that the industry has converged on an answer arrived on September 3, when Tenable and OpenAI launched the CyberAgents Exchange AI Inspector, a review process that sits in front of Tenable’s open-source, cybersecurity-native registry for agents, skills, MCP servers, and multi-agent playbooks. The design is worth studying regardless of whether you adopt this specific product, because it’s the shape of the control enterprises now need to build or buy: a frontier-model assessment pass (OpenAI’s GPT cyber models scanning for the LLM-instruction and tool-chaining risks that traditional SAST tools miss), a code and exposure inspection pass (Tenable One AI Exposure scanning the executable side), and a human expert review layered on top — with the model tier assigned to each submission scaled to its declared risk level, so trivial skills don’t wait behind a full manual review.
That three-layer shape — LLM-native instruction review, code-level exposure scanning, human judgment for anything above a risk threshold — is the pattern to replicate internally, whether your organization builds its own gate, adopts a vendor registry that already inspects submissions, or restricts installs to a small allowlist reviewed by hand. The registry itself launched in August 2026 and already carries more than 100 community-submitted components; the inspector is the missing control that makes trusting that registry defensible.
Architecture Impact #
What changes in system design? Agent platforms need an explicit install-time control point between “skill exists in a registry” and “skill runs with production tool access” — today that boundary is usually just a human clicking install. This means introducing a gateway or broker that mediates skill and MCP-server installation the same way an artifact repository mediates package installation, with provenance checks, signature verification, and a scan result attached to every approved entry before it reaches a runtime.
What new failure mode appears? The failure mode is combined-vector compromise: a skill passes code review because the payload is benign-looking Python, and passes a content check because the embedded instructions read as legitimate technical guidance — but together they cause the agent to exfiltrate credentials or execute unintended tool calls. Standard code-security and content-moderation pipelines run in isolation will both report clean on exactly the packages Snyk classified as malicious 91% of the time.
What enterprise teams should evaluate:
- Platform/infrastructure engineering: whether the agent runtime enforces sandboxed execution by default (container isolation, no host-mode access) for any skill not on an explicit allowlist.
- AppSec/security engineering: whether existing SAST and prompt-injection tooling can be composed into a single combined-vector review, or whether a dedicated agent-skill scanner (internal or vendor) is needed.
- Platform/DevEx teams managing internal skill catalogs: whether skill publication requires cryptographic signing and provenance metadata, mirroring SBOM requirements already applied to container images.
Cost / latency / governance / reliability implications: A tiered inspection gate (lightweight automated scan for low-risk skills, full frontier-model-plus-human review for anything requesting elevated tool permissions) adds review latency measured in minutes to hours per submission rather than blocking real-time agent execution, since the gate sits at install time, not invocation time. The governance payoff is concrete: teams that can point to a signed, scanned skill catalog have an audit trail for incident response and regulatory review that “we downloaded it from GitHub” does not provide, and with 13.4% of unvetted skills carrying critical flaws, the expected cost of skipping the gate is not hypothetical.
Implementation Guide #
Start with inventory, not tooling. Before building or buying an inspection gate, get an honest list of every skill, MCP server, and agent extension currently installed across your engineering org — most teams discover this list is longer and more decentralized than expected, because individual developers have been installing skills into personal Claude or OpenClaw configurations without any central registration. This inventory is the highest-leverage first step because it turns an abstract risk into a concrete, bounded remediation list, and it’s usually where the first real findings show up.
The mistake to avoid is treating this as a one-time audit. A skill that passed review in March can be silently updated by its publisher in June, and unless your gate re-scans on version changes — the same discipline container registries apply to image tags — you’ve built a control that only covers day zero. Pin skill versions the way you’d pin a package version, and treat any auto-update behavior in your agent runtime as a configuration to disable by default, not a convenience to leave on.
You’ll know the gate is working when two things happen: first, when security review of a new skill request takes minutes for routine cases and escalates automatically for anything requesting filesystem, network, or credential-adjacent tool access — if every request takes the same amount of time, the risk-tiering isn’t actually differentiating; second, when your incident response team can answer “which agents had this skill installed and when” from the provenance log alone, without grepping through individual developer machines.
The six-to-twelve month maturity path looks like this: teams that get this right move from ad hoc developer installs, to a centrally maintained internal allowlist with manual review, to an automated tiered gate (fast-path scanning for low-risk skills, full review for anything touching credentials or external network calls) integrated into the same CI/CD and artifact-provenance tooling they already run for regular software dependencies. The end state isn’t a separate “AI security” program bolted onto the side of application security — it’s agent skills folded into the existing software supply-chain security program, because that’s structurally what they are.
Sources #
Enterprise AI Architecture
Want more enterprise AI architecture breakdowns? #
Subscribe to SuperML.