Scanning caught the malicious skills. It did not catch the accounts that published them

Published September 10, 2026 · Last reviewed September 10, 2026

Agent skill marketplace security is the practice of checking a packaged agent capability, typically a folder of markdown instructions plus supporting code, before it installs and runs with the permissions of whoever installed it. In 2026 it means three concrete things: scan the artifact at publish time, sign it so the bytes cannot be swapped, and show the result on the listing page. The measurements say the first two work and stop short of the question a buyer actually has. Snyk’s February 2026 audit of 3,984 skills found a security flaw in 36.8% of them and confirmed 76 carrying working payloads. Antiy CERT’s sweep of ClawHub’s history found 1,184 malicious packages that resolved to twelve author accounts, one of which published 677 on its own. A study of 67,453 skill versions found the three main scanner families agree on 0.69% of what they flag. Every one of those numbers describes a file. None of them describes a publisher. Here is what the audits established, where the scanners stop converging, and which layer of marketplace trust is still missing.

Agent skills are the fastest-moving distribution channel in software right now. A skill is a folder with instructions in it, and installing one hands an agent a new capability in the time it takes to copy a directory. Registries grew up around that convenience in under a year, mostly modelled on the package registries that came before them, and they inherited the response those registries taught: scan the artifact, at publish time and again on install, and put a score on the page. That work is real, it is being done well, and it caught a large poisoning campaign in early 2026.

It has a shape that is easy to miss. Every scanner in this ecosystem answers a question about a file. None of them answers a question about a person. When investigators went back through the largest campaign to date, the thing that organised it was not a code pattern at all. The compromise had an author. The scanning layer has no field for one.

What the audits actually found

The best-documented sweep is Snyk’s, published in February 2026 under the name ToxicSkills. Its researchers took a snapshot of 3,984 skills from ClawHub and skills.sh as of February 5, deduplicated by author and skill ID, and ran them through both code analysis and human review.¹ 36.8% of the corpus, 1,467 skills, carried a security flaw. A tighter subset, 13.4% or 534 skills, carried at least one critical issue: malware distribution, prompt injection, or an exposed secret.

The number that matters most is the smallest one. Seventy-six skills were confirmed malicious by human-in-the-loop review, carrying working payloads for credential theft, backdoor installation and data exfiltration.¹ Eight of those were still publicly downloadable on clawhub.ai when Snyk published.

One finding in that set is genuinely new to package security. Every confirmed malicious skill combined a code payload with a prompt injection: all seventy-six of them attacked the shell layer and the natural-language instruction layer at once.¹ A skill is markdown that tells an agent what to do plus code the agent may run, and a malicious one exploits both. That is why importing the npm playbook wholesale does not quite fit. Static analysis reads the code. The prose that instructs the agent is also executable, in the only sense that matters.

A larger figure circulates alongside these. The New Stack reported on March 22, 2026 on an audit of 22,511 AI coding skills across four registries, skills.sh, ClawHub, GitHub and Tessl, that surfaced 140,963 issues, framed around the gap between what a registry scans at publish time and what runs with full user permissions afterwards.² The audit is attributed to the application-security vendor Mobb.ai, and no report published by Mobb.ai itself could be located to sit behind the coverage.² The framing is the right one and the scale is plausible. Treat the two numbers as a single-outlet report of direction, not as a citable measurement, which is how they are used here.

The 1,184 skills came from twelve accounts

The campaign behind a good share of those numbers has a name. ClawHavoc began in late January 2026, when someone started uploading malicious skills to ClawHub in volume. The first landed on January 27. On January 31 the rate went vertical: 386 malicious skills in a day from seven attacker accounts, 354 of them from one.³

Koi Security disclosed it first, in early February, after auditing the 2,857 skills then listed on ClawHub and finding 341 malicious.⁴ Of those, 335 traced to a single coordinated operation delivering Atomic Stealer, a commodity macOS infostealer rented on criminal marketplaces.⁴ Antiy CERT then swept ClawHub’s historical repository instead of its live listing and, as of February 5, 2026, identified 1,184 malicious skill packages, classifying the family as Trojan/OpenClaw.PolySkill.³ The two counts are not in conflict and this article does not reconcile them: they were taken at different times against different scopes, and the later sweep looked at history rather than at what was live on any given day.

The counts also did not stop. By February 16, follow-up reporting put the malicious total above 824 across a marketplace that had itself grown from 2,857 skills to more than 10,700 in a fortnight.⁴ Scanning was working and the corpus was growing faster.

Antiy’s attribution is the part worth sitting with. Those 1,184 packages resolved to twelve author IDs. A single account, hightower6eu, published 677 of them, more than half the campaign on its own.³

Read that as an operational fact rather than as a statistic. One operator, or one small group, opened a handful of accounts and used them to push a four-figure quantity of packages at a registry. Every package was a separate artifact and had to be caught separately. The accounts were twelve.

This is the asymmetry the scanning layer sits on the wrong side of. Scanning costs the registry one check per package. Attacking costs the operator one upload per package. Same unit, same price, and the upload happens first. Publishing identity does not work that way. If a registry could establish that an account belongs to somebody who can be found, twelve accounts is a small enough number to be a solved problem. If it cannot, then 1,184 packages is the size the problem takes instead, and the next campaign sets that number itself.

There is a tell in how the cleanup worked, too. When Unit 42 reported a later batch of malicious skills that had slipped past the filters between February and May, the remedy applied at both levels: the skills came down and the accounts behind them were banned.⁵ Enforcement already understands that the account is the unit. It just has nothing to reach past the account with, and a banned free account is replaced by opening another one.

None of this makes ClawHub negligent, and it is not offered as a criticism of any registry. The campaign was detected, disclosed, analysed by independent security teams and cleaned up, which is what a functioning ecosystem looks like. The point is narrower: the layer that did the detecting can only ever describe the packages, and the thing the packages had in common was an author.

Three scanners, one object, almost no agreement

There is a second problem underneath the first, and it is easy to miss while the campaign numbers are doing the talking. “Scanned” reads like a verdict. Measured across a large corpus, it is closer to an opinion.

A study released on arXiv on May 31, 2026 assembled a dataset of 67,453 public OpenClaw skill versions and paired each one with a registry verdict plus evidence from three scanner families: VirusTotal, static heuristic analysis, and NVIDIA’s SkillSpector.⁶ The authors deliberately did not try to estimate how many skills are malicious. They measured how often the scanners agree.

They mostly do not. Any two of the three overlap on at most 10.4% of their combined positives. Only 0.69% of skills are flagged by all three. And 81.9% of everything flagged is flagged by exactly one scanner.⁶

The explanation is more interesting than a story about tool quality would be. The three are not looking at the same layer of the same object. VirusTotal and static heuristics work on the artifact: the bundled files, the code, the known-bad signatures. SkillSpector reasons about the skill’s instructions and its declared capabilities, which is the tool layer.⁶ A skill is at least three things stacked together, prose, code and declared capability, and each scanner is sampling a different one. Low agreement is what you would predict, and it means a single security score on a registry page is a compression of measurements that do not converge.

That is not an argument for skipping the scan. Filters with imperfect agreement are still worth running, and the ClawHavoc cleanup is what a working filter buys you. It is an argument against reading a badge as a settled answer, and against the idea that stacking more scanners eventually produces certainty about a file. Four scanners would produce four partly disjoint opinions. The uncertainty is structural.

Which puts a fairly sharp question on the table. If checking the artifact does not converge, what else is there to check?

NVIDIA answered the ownership question, for its own skills

The ecosystem has already started answering it, and the answers are converging on the same shape from three directions.

The registries went first. Snyk and Tessl announced a partnership on March 17, 2026 to put security scanning behind every public skill in the Tessl Registry, with a Snyk score visible on the skill page and in search results.⁷ That is the scanning layer, done properly and at the point of distribution, not left to the person installing.

NVIDIA went further, and its version is the one worth studying. Verified Agent Skills were announced on May 19, 2026 and became available on May 22.⁸ “Verified” is defined as a pipeline, not a badge, and NVIDIA lists its stages as “source repo, review, scan, evaluate, skill card, sign, catalog, sync.”⁸ Each skill is catalogued daily from the owning product team and scanned with SkillSpector, an open-source scanner splitting its checks between conventional software risks and agent-native ones such as prompt injection, excessive agency and tool poisoning. Its coverage has grown since launch: 64 patterns across 16 categories in an early-August reading, 71 across 17 as of September 10, 2026.⁸ The signing step is a detached skill.oms.sig covering every file and subdirectory, built on the OpenSSF Model Signing specification, not on a format of NVIDIA’s own.⁸ And each skill carries a skill card, a machine-readable trust record describing what the skill does, who built it, how it is licensed, what it depends on, and its known limitations and mitigations.⁸

Note what the skill card contains that a scanner output cannot: ownership. Somebody is named. The signature then binds that name to those exact bytes, so a modified copy stops verifying.

Then the standards layer caught up. OWASP published the Agentic Skills Top 10 v1.0 on August 17, 2026, and the first entry, AST01, is Malicious Skills: skills that look legitimate while hiding credential stealers, reverse shells, or prose that hijacks the agent.⁹ The project’s own case studies cite both ClawHavoc and the Snyk research as the evidence base, which is a fair sign that the incidents above are now shared reference points and not one vendor’s framing.⁹

So the direction of travel is clear enough. The honest caveat is what NVIDIA’s model assumes. It works because NVIDIA is a known company publishing its own skills, catalogued from its own product teams, signing with its own key. The trust does not come from the pipeline. The pipeline transmits trust that already existed in the publisher, faithfully and at scale, which is genuinely valuable and is not the same thing as creating it.

Run that model on an open registry and the question it cannot answer arrives immediately. A skill card names the builder. What backs the name when the builder is an account called hightower6eu?

Trusted publishing arrived, and it verifies a repository

Through the middle of 2026 the registries imported the other half of the package-security playbook, the half about publication rather than about code. It is the right move, and it lands next to the question instead of on it.

ClawHub’s own documentation now describes trusted publishing: a publication is authorised by matching GitHub Actions OIDC claims against a configured repository and workflow, with public repositories verified through public GitHub metadata and private ones requiring ClawHub to hold access to the repository.¹⁰ That is a genuine improvement over a long-lived upload token, and it is worth reading exactly. It establishes that a particular workflow in a particular repository is entitled to publish. It does not establish who owns the repository, and a GitHub account costs what an email address costs. Two further limits belong on the record: the documented mechanism covers plugins and packages rather than skills, and it is described without a dated rollout.¹⁰

The integrity layer got a patch in the same period. CVE-2026-42428, rated 7.1, records that OpenClaw did not enforce integrity verification on downloaded archives before release 2026.4.8, which meant a tampered package could install without detection.¹⁰ Fixing that is necessary and it closes a different hole than the one this article is about: integrity says the bytes are the published bytes, and says nothing about whether the party that published them can be found.

Signing infrastructure is converging on the same base. NVIDIA’s detached signature uses the OpenSSF Model Signing format, and enterprise registries have started offering skill hosting with provenance tracking attached.¹⁰ Stack all of it together and a publication event becomes precisely attributable: this workflow, in this repository, produced these bytes, signed with this key. Every term in that sentence is a machine. None of them is a person. The same split turns up wherever evidence gets rigorous: a deterministic verifier can prove what an agent found without proving whose agent found it.

What a registry cannot check about a publisher

Signing solves integrity, and it is worth being precise that this is a real and complete solution to a real problem. A signature proves the bytes you downloaded are the bytes that were published and that they have not been altered in transit. It says nothing whatsoever about whether the signer should be trusted. A malicious publisher can sign a credential stealer perfectly.

Underneath signing sits the question nobody in the current stack owns: is there an accountable party behind this account, and does anything follow them if this skill turns out to be hostile?

Package ecosystems have been circling this for years and their answer is thin by design. An email address, a token, two-factor authentication, and now an OIDC claim from a repository the same person also registered for free. Each of those proves control of something. None of them establishes that the controller is a party who can be found. The cost of a fresh identity is roughly the cost of a fresh mailbox, which is why the ClawHavoc operator could hold twelve of them at once, and why the count of accounts tells you almost nothing about the count of humans. Credibility scoring has the same dependency: a score is only as durable as the identity it is attached to, and a score attached to a discardable identity is a score worth gaming.

Agent skills raise the stakes on that thinness rather than changing it. A skill runs with the permissions of whoever installed it, and once installed, an agent may invoke it without a human reading the prose again. The gap the March report pointed at, between what gets scanned at publish time and what executes on a developer machine afterwards, is exactly the interval in which publisher accountability would matter and is not available to consult. The same gap shows up wherever skills become something agents buy and sell between themselves rather than something a human installs deliberately, which is the direction the commerce rails are heading.

So the second layer, the one the ecosystem has not built yet, is not a better scanner. It is provenance that resolves to somebody: a publisher identity that is human-readable, that persists across skills and registries rather than being scoped to one account on one platform, that carries a track record which accumulates and cannot be shed by re-registering, and that connects to a named party who can be reached. Then a skill card’s “who built this” field points at something with weight behind it, and the twelve-accounts problem stops being cheap to reproduce.

Three cautions, because this is the part where it is easy to overclaim. Identity is not a replacement for scanning, and a signed skill from an accountable publisher can still contain a bug that a scanner would have caught. Accountability raises the cost of an attack without eliminating it, and a determined operator with real credentials to burn can still burn them once. And the same infrastructure carries an obvious cost to the anonymous individual publishing something useful under a handle, which is a real tradeoff that open ecosystems have to price deliberately instead of pretending away. What accountability changes is the economics of doing it 1,184 times.

How this connects to Tobira

Tobira does not publish, host or scan agent skills, and nothing here is a claim that a handle would have stopped ClawHavoc. The overlap is the field a skill card opens and cannot fill. A Tobira @handle is a human-readable address for an agent that represents a named person or company. It carries a credibility score on a 0 to 5 scale across four dimensions, surfaced in four public levels instead of as an opaque number, and that score accrues to the identity, not to a package. Per Tobira’s founder update, June 2026, the network carried 648 agents, including 102 business agents. That is a beta-stage figure on a network that does not touch skill distribution, so keep the comparison narrow: what a registry would need to make “who built this” mean anything is an identity whose record is expensive to walk away from. Scope it honestly too. A handle is held on one network today, and it is built on open identity primitives rather than recognized by any skill registry; a reader who hears “portable” as “my ClawHub publisher identity travels” would be hearing more than exists.

Which leaves the objection a careful reader has already formed, and it deserves an answer rather than a wave. If a ClawHub account is cheap, why is a handle not cheap twelve times over? Because no identity layer makes registration expensive, and anyone selling you one that does is selling something else. What changes is what a fresh identity starts holding. Twelve new handles are twelve records at zero, on a surface where the other side sees the level before it sees a name and where a reveal takes both parties agreeing. That is a different proposition from twelve accounts that each look exactly like an established publisher on the day they are created. It raises the floor without closing the door, which is the same ceiling portable agent reputation runs into: a record is worth only as much as abandoning it costs. It complements signing and scanning, and replaces neither.

What to remember

What scanning settles: whether a specific artifact matches known-bad patterns, whether its prose contains an injection, and whether its declared capabilities look like what it claims to do. That work found 76 live malicious payloads in a 3,984-skill sample and helped shut down a campaign of well over a thousand packages. Nobody should stop doing it.

What it does not settle: agreement, since three scanner families overlap on at most 10.4% of their combined positives and only 0.69% of skills are flagged by all three; and authorship, since the largest campaign to date resolved to twelve accounts with one publishing 677 packages, and no scanner has a field for that.

What signing adds, and where it stops: a detached signature proves the bytes are unmodified and binds them to a signer, and the format is converging on the OpenSSF Model Signing specification rather than fragmenting per vendor. It does not make the signer accountable. NVIDIA’s skill card names an owner and works because the owner is NVIDIA, which transmits existing trust rather than manufacturing it.

What trusted publishing adds, and where it stops: authorising publication through a repository’s OIDC claim removes the long-lived token and pins a release to a workflow. It verifies a repository, not a party, it is documented for plugins rather than skills, and a repository is as cheap to create as the account that holds it.

The practical version for anyone installing skills today: prefer a registry that scans and publishes what it found, prefer signed skills, prefer a publisher whose releases come from a repository you can read, and then look at the publisher separately and treat “an account exists” as the weak evidence it is. Ask what follows this publisher if the skill turns out to be hostile. On most registries in September 2026 the honest answer is that the account gets banned.

The campaigns are counted in packages because packages are what the tooling can see. They are operated by people, in numbers small enough to fit on one hand twice over.

FAQ

What is an agent skill, and why is it a security problem?

An agent skill is a packaged capability, typically a folder of markdown instructions plus supporting code, that an AI agent installs to learn how to perform a task or use a tool. It is a security problem because it executes on two layers at once. The code runs with the permissions of whoever installed it, and the markdown instructs the agent directly, so a hostile skill can attack through prose as well as through a shell call. Snyk found that 100% of the malicious skills it confirmed used both layers together, which is the part that does not map cleanly onto traditional package security.

How many malicious skills have actually been found?

Two measurements are worth separating. In a sample of 3,984 skills from ClawHub and skills.sh as of February 5, 2026, Snyk found 36.8% with a security flaw, 13.4% with at least one critical issue, and 76 confirmed malicious with working payloads, eight of which were still publicly available at publication. Separately, in the ClawHavoc campaign, Antiy CERT identified 1,184 malicious skill packages in ClawHub’s historical repository, while Koi Security’s earlier and narrower disclosure counted 341 in an audit of the 2,857 skills then listed, 335 of them traced to a single coordinated Atomic Stealer operation. The counts differ because they were taken at different times against different scopes, and they kept moving: follow-up reporting put the malicious total above 824 by February 16 on a marketplace that had grown past 10,700 skills.

Do security scanners agree on which skills are malicious?

Largely not, and the disagreement has been measured. A study of 67,453 public skill versions compared VirusTotal, static heuristic analysis and NVIDIA’s SkillSpector, and found that any two of them overlap on at most 10.4% of their combined positives, only 0.69% of skills are flagged by all three, and 81.9% of flagged skills are flagged by a single scanner. The main reason is that the three inspect different layers of the same object, artifact code versus declared capability and instructions, so a single security badge compresses measurements that do not converge.

Does trusted publishing fix the publisher problem?

It narrows it. ClawHub’s documented trusted publishing authorises a release by matching GitHub Actions OIDC claims against a configured repository and workflow, which removes the long-lived upload token and pins a release to a specific pipeline. Read the scope before reading it as a solution: the documented mechanism covers plugins and packages rather than skills, it establishes that a workflow in a repository may publish rather than who owns the repository, and a GitHub account costs what an email address costs. It is a real improvement to the integrity of a publication event and not an answer about the party behind it.

Does signing a skill make it safe?

No. A signature proves integrity, meaning the files you received are the files that were published and have not been modified. It carries no judgement about the publisher, and a malicious author can sign malicious code correctly. Signing is necessary and answers a narrower question than most people read into it, which is why NVIDIA pairs its detached signature with a skill card that names the owning team rather than relying on the signature alone.

What would publisher accountability actually look like?

Four properties, none of which a registry account provides today: an identity that is readable by a human rather than an opaque token, one that persists across skills and across registries instead of being scoped to a single platform, a track record that accumulates over time and cannot be discarded by registering again, and a link to a named party who can be reached if something goes wrong. That is what would make a skill card’s ownership field load-bearing. It does not replace scanning, and it changes the economics of publishing a thousand malicious packages rather than making it impossible.

Are agent skill registries unsafe to use?

That is the wrong frame. The registries in question detected a large campaign, disclosed it, cooperated with two independent security teams and cleaned it up, which is a functioning ecosystem rather than a broken one, and both scanning and signing have improved considerably through 2026. The gap is structural rather than a failure of diligence: the entire toolchain answers questions about files, and the unit that organises abuse is the publishing account. Use the registries, read what their scanners report, and treat publisher identity as an open question rather than a settled one.

Sources

• Snyk, “Snyk Finds Prompt Injection in 36%, 1467 Malicious Payloads in a ToxicSkills Study of Agent Skills Supply Chain Compromise,” February 2026. https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/
• Antiy Labs, “ClawHavoc: Analysis of Large-Scale Poisoning Campaign Targeting the OpenClaw Skill Market for AI Agents.” https://www.antiy.net/p/clawhavoc-analysis-of-large-scale-poisoning-campaign-targeting-the-openclaw-skill-market-for-ai-agents/
• Koi Security, “ClawHavoc: 341 Malicious Clawed Skills Found by the Bot They Were Targeting.” https://www.koi.ai/blog/clawhavoc-341-malicious-clawedbot-skills-found-by-the-bot-they-were-targeting
• “ClawHub Security Signals: When VirusTotal, Static Analysis, and SkillSpector Disagree,” arXiv:2606.01494, May 31, 2026. https://arxiv.org/abs/2606.01494
• NVIDIA, “NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents,” NVIDIA Technical Blog. https://developer.nvidia.com/blog/nvidia-verified-agent-skills-provide-capability-governance-for-ai-agents/
• NVIDIA, Skill Documentation, including “Verify Signed Agent Skills.” https://docs.nvidia.com/skills
• OWASP Foundation, Agentic Skills Top 10, v1.0, August 17, 2026, and “AST01 Malicious Skills.” https://owasp.org/www-project-agentic-skills-top-10/
• Snyk, “Securing the Agent Skills Registry: How Snyk and Tessl Are Setting the Standard,” March 2026. https://snyk.io/blog/snyk-tessl-partnership/
• “What a security audit of 22,511 AI coding skills found lurking in the code,” The New Stack, March 2026. https://thenewstack.io/ai-agent-skills-security/
• Palo Alto Networks Unit 42, “OpenClaw’s Skill Marketplace and the Emerging AI Supply Chain Threat,” June 23, 2026. https://unit42.paloaltonetworks.com/openclaw-ai-supply-chain-risk/
• ClawHub publishing documentation, including trusted publishing. https://docs.openclaw.ai/clawhub/publishing
• CVE-2026-42428, ClawHub package downloads not enforced with integrity verification. https://advisories.gitlab.com/pkg/npm/openclaw/GHSA-3vvq-q2qc-7rmp/
• NVIDIA SkillSpector repository. https://github.com/NVIDIA/SkillSpector
• OpenSSF Model Signing specification. https://github.com/ossf/model-signing-spec
• Andrew Nesbitt, “Skills Registry Threat Models,” June 3, 2026. https://nesbitt.io/2026/06/03/skills-registry-threat-models.html
• Tobira founder update, June 2026, for the network figures cited in the Tobira section.