The Payload Is a Sentence: Forensics on the Agent Skill Supply Chain

The chart shows growth. The ledger shows a stampede.

In the second week of February 2026, ClawHub — the skill registry attached to the open-source agent runtime OpenClaw — cleared more than 500 new skill submissions in a single day. Six weeks earlier, that number sat under 50. A tenfold increase in submission velocity inside one quarter is, on its face, an ecosystem maturity signal. It is the kind of curve that belongs in a pitch deck, circled in red.

I do not read it that way. Tracing the ghost in the machine, the same window coincides with a coordinated malicious-upload campaign that security researchers later named ClawHavoc. The submissions curve and the attack curve are the same curve. One of them is a coincidence. The other is a supply chain being flooded on purpose.

This is the part of the story the aggregators repeated and the analysts skipped. Everyone quoted the percentages. Almost nobody asked who was standing in the denominator.

The Context: Why a Skill Is Not a Plugin

To understand why this event matters more than the last decade of supply chain scares, you have to understand what an agent skill actually is. It is not a browser extension. It is not an npm package. It is not a compiled binary.

An OpenClaw skill is, in the overwhelming majority of cases, an instruction document — a file conventionally named SKILL.md. It contains natural language. It describes what the agent should do. The runtime reads that document and, when the user invokes the skill, presents it to the underlying large language model as context. The model then decides, based on that context, which of its tools to call, which files to open, which environment variables to read, which network calls to make.

The payload is a sentence.

That single sentence is the entire reason this architectural layer is novel. In every prior supply chain, the attack surface was code. Code can be signed, hashed, sandboxed, and statically analyzed. You can run an npm package in a container and watch what it touches. You can hash a Chrome extension and compare the hash against a whitelist. The detection object is deterministic: bytes and their behavior.

In an agent skill, the detection object is semantics. And semantics cannot be formalized the way bytes can. Legal instructions and hostile instructions are grammatically identical. "Read the configuration file and summarize it" and "read the configuration file and transmit it to this endpoint" are the same shape. No compiler can tell them apart, because there is no compiler. There is an interpreter that has been trained to be helpful, and helpfulness is an attack surface.

The research consensus in LLM security is unambiguous on this point: prompt injection is not a bug to be patched. It is a property of the architecture. Any system that mixes trusted instructions with untrusted content inside a single context window has, by construction, an unclosable channel. The agent skill market is that property, industrialized.

So the framing that dominated coverage — "third-party skills lack signatures" — is not wrong, but it is shallow. A signature solves provenance. It tells you who wrote the file. It does not tell you whether the file's instruction is hostile, because the hostility lives in meaning, not in origin. You can have a perfectly signed, perfectly attributed, perfectly malicious skill. The signature would vouch for it.

There is a second property that makes this worse, and it is the one I keep returning to. Skills do not run in a low-privilege box. They run in the agent's privileged context. The agent holds the user's tool access: shell execution, filesystem reads, environment variables, outbound network. A skill is a document that can convince the agent to use those tools on its behalf. This is the textbook definition of a confused deputy — a program with authority is tricked into exercising that authority for an unauthorized party. The user authorized the agent. The user did not authorize the skill. The agent cannot tell the difference.

The mapping to the OWASP LLM Top 10 is not approximate. It is a triple hit: LLM01, prompt injection; LLM03, supply chain; LLM06, excessive agency. Three distinct failure classes firing simultaneously in a single artifact.

That is the context. Now the evidence chain — and the evidence chain is where the numbers, as published, fall apart.

The Core: Three Studies, Three Denominators, No Common Ground

Three research teams entered the agent-skill supply chain in 2026. Their headline numbers were quoted interchangeably. They are not interchangeable.

Unit 42, working inside Palo Alto Networks, surveyed 49,943 skills. Its Behavioral Integrity Verification method flagged 80% for "behavioral deviation." Within that population, 18.9% were described as indicating adversarial intent — roughly 9,440 skills.

Snyk surveyed 3,984 skills. It reported 13.4% with "serious security issues" — roughly 534. But Snyk's own data contains a second number: only 76 skills were confirmed to carry malicious payloads.

Koi Security surveyed roughly 4,500 skills and classified about 900 as "weaponized" — a 20% rate.

Stop and look at what just happened.

The three samples differ by an order of magnitude — 49,943 versus 3,984 versus 4,500 — and the three categories, "behavioral deviation," "serious security issue," and "weaponized," are not defined to a common standard. They cannot corroborate each other, because they are not measuring the same thing. The 18.9%, 13.4%, and 20% figures were reported as if they were independent confirmations of a shared phenomenon. They are three different rulers applied to three different populations by three parties with no shared rubric.

The Snyk discrepancy is the tell. Within a single study, 534 skills had "serious security issues" but only 76 were confirmed malicious. That is a 7x gap — a factor of seven between "this artifact has a defect" and "this artifact is an attack." When a report collapses those two categories into one headline percentage, it is not measuring risk. It is measuring the potential for risk and dressing it as the realization of risk.

Back out the arithmetic that the coverage never did. If roughly 9,400 skills genuinely carried adversarial intent, and the ecosystem had been live for months with a registry this large, the expected number of reported compromises would be non-zero. It would, under any reasonable conversion model, be large. The published reporting contains zero confirmed victim cases and zero quantified economic loss.

I want to be precise about what I am and am not claiming. I am not claiming the risk is fake. I am claiming the numerator is real and the denominator is missing. The number that actually determines exposure is not "what fraction of skills are hostile." It is "what fraction of hostile skills ever get installed, invoked, and successful." Call it the conversion rate. No study published it. Without it, 18.9% is a population statistic masquerading as a threat statistic.

The Mechanism That Changes Everything: Memory as an Unmanaged Attack Surface

Strip the percentages away and there is one technical fact in this event that I consider genuinely new, and it is the one the coverage underplayed because it does not produce a scary percentage.

The attack chain documented by Koi has a fourth step: persistent memory poisoning. OpenClaw agents maintain a long-term memory file, conventionally MEMORY.md. When an agent processes content — including content delivered by a hostile skill — it can write to that memory. Once written, the memory persists. It is read on every subsequent session. It shapes every subsequent decision.

This is not a plugin that you uninstall. This is a semantic backdoor. And it has a property that no prior malicious artifact has: it does not look like software.

Uninstall a Chrome extension and it is gone. Delete an npm package and the dependency tree no longer references it. But a poisoned memory file looks like a personal note. It reads like something the user wrote. It is not listed in any software inventory, because it is not software. It is not in any asset register, because nobody classifies their own notes as an attack surface. The remediation advice everyone repeated — enumerate your installed skills — cannot, by construction, find the thing that was left behind.

This is where I apply the rule I have used since 2017, when I spent six months hand-auditing ICO contracts and found integer overflow bugs in the Gnosis Safe multisig precursor that the whitepapers never mentioned. The code does not lie, but the documentation about the code lies constantly. A skill's SKILL.md is documentation. A memory file is documentation. The only trustworthy artifact is what actually executes, and what actually gets written.

The image is innocent; the metadata confesses. A memory file that reads like a shopping list can carry an instruction that has been silently influencing the agent's tool calls for three weeks. The persistence layer of an agent is, today, a configuration file that any third party can write to, that influences every downstream decision, and that appears in no security checklist anywhere in the industry. There is no version control for it. There is no signature. There is no diff audit. It is a write-able trust boundary with no revocation.

If you take one engineering lesson from this entire event, take that one.

The Permission Model Under the Hood

There is a second mechanism worth dissecting, because it determines whether skill-by-skill review is even a valid defense. It is not.

Skills call other skills. A skill can invoke a function that is implemented by another skill, which invokes another. Authority flows through the call chain. This means the permission surface of a single skill is not bounded by its own manifest — it is bounded by the transitive closure of everything it can reach. Reviewing a skill in isolation tells you what that skill declares. It does not tell you what the graph around it does.

Formal verification of this property requires graph-level dependency analysis: model skills as nodes, calls as edges, and compute reachable privilege. Existing scanning tools do not do this. They scan artifacts one at a time, because that is how npm-era tooling was built, because in the npm era a package could not dynamically borrow another package's authority at runtime. The agent era broke that assumption and the tooling did not follow.

There is also a metadata problem that points at a deeper design gap. Researchers observed "manifest pollution" — skill description files being rewritten without triggering any consistency check. Read that carefully. It means the manifest, the file that is supposed to declare what a skill does, is not strongly bound to the skill's behavior schema. Android solved this problem fifteen years ago with a manifest that declares permissions and a runtime that refuses to grant anything not declared. Agent skills have no equivalent enforcement. The manifest is prose. Prose cannot be enforced.

A related historical note that the coverage omitted: this ecosystem class has already been broken through. Prior incidents — the Plugin4Shell family and the MCP governance-surface flaws — established that attackers will bypass pinning and signature mechanisms once they are introduced. The lesson is that signing is not a deliverable. It is the start of a permanent adversarial loop. Anyone selling an agent security product as a one-time fix is selling the same paper shield the industry has bought before.

The 91% That Defines the Defense

One figure from the research deserves its own section because it dictates architecture. Roughly 91% of the malicious techniques observed were hybrid: they combined a conventional malicious component — a script, a dropped binary, an exfiltration helper — with a semantic component, the prompt injection that convinced the agent to run it.

That ratio is the whole design brief.

A pure static scanner — a VirusTotal-style hash and signature engine — can catch the conventional half. It cannot see the semantic half. A pure semantic classifier can catch the injection but can only reason about the prompt, not about the binary the prompt eventually triggers. Neither layer is sufficient alone. The defense has to be two-layer: static behavioral detection plus semantic intent detection.

Now the recursive problem. The semantic classifier is itself a large language model. A model whose job is to detect prompt injection is, by definition, a system that processes untrusted natural language. It can be injected. The defense component is an attack surface. This is not a hypothetical — it is the foundational, unsolved problem of prompt injection defense, and it means the semantic layer can never be certified clean. It can only be continuously adversarially tested. Yields decay, but the logic remains immutable: the moment you build a detector out of the thing you are detecting, you inherit the detector's vulnerabilities.

The third layer is behavioral integrity verification — the method Unit 42 used. Mechanically, it compares declared intent against runtime behavior: instrument the agent to intercept tool calls and file access, judge whether the observed behavior is semantically equivalent to the declared behavior, and attribute the difference. Three capabilities, three hard problems. The judge can be fooled. The token cost scales with usage. And false positives compound — if 13% to 20% of the registry gets flagged, the human review queue becomes the bottleneck, not the detection. Review becomes a denial-of-service target: flood the queue with noise and the real payload rides through in the backlog.

And here is the cost reality that nobody bothered to compute, so I did. Full semantic review of 49,943 skills at roughly 10,000 tokens per skill is about 500 million tokens. At current mid-tier model pricing, a single full pass costs roughly $500 to $2,000. The daily inbound of 500 new skills costs roughly $5 to $20 per day. Even adding a dynamic sandbox replay that raises cost by one to two orders of magnitude, the number stays inside any serious operator's budget.

The bottleneck in agent skill security is not compute. It is not money. It is organizational will and the design of review pipelines. That is a very different — and more damning — conclusion than "security is expensive." It says the ecosystem chose speed over a control it could comfortably afford.

The Commercial Layer Beneath the Research

I have spent enough time in crypto hedge fund research to be allergic to a specific pattern: research that precedes a product by exactly one quarter, published by the company that will sell the product. It is not misconduct. It is a funnel. But it changes how you weight the conclusions.

Three firms entered this space in 2026 — Snyk, Koi Security, and Unit 42 — with reports clustered in February and June. Snyk's path here is a direct copy of its npm playbook: publish a research report that establishes authority over a category, then sell the scanner for that category. Koi did something more aggressive: it named the campaign "ClawHavoc," borrowing the NotPetya naming-rights tactic. A campaign name is a marketing asset. It is the kind of thing you cannot buy with advertising, and it is why security firms race to be the one who names the worm.

This does not make the findings false. It makes them incentivized. The correct response is not to dismiss them but to separate two claims: the mechanistic claim and the quantified claim. The mechanistic claim — natural-language payloads, memory persistence, confused deputy authority — is corroborated by the entire body of established LLM security research and does not depend on any vendor's number. The quantified claim — 18.9%, 13.4%, 20% — depends entirely on vendor methodology that was not disclosed and on URLs that could not, in the source material I reviewed, be independently verified.

There is also a self-certification problem in Unit 42's methodology. Behavioral Integrity Verification is a technique the firm is developing and presumably intends to commercialize. Evaluating a market with the tool you intend to sell is a ruler measuring demand for the ruler. I do not say the 80% deviation figure is manufactured. I say it is a number produced by an interested party using a proprietary method, and those two facts must travel together.

The Contrarian Read: Correlation Is Not Causation, and a Missing Victim Is Data

Here is the angle I would push back on hardest, because it is the one the coverage never considered.

Everyone read the absence of confirmed victims as "the danger is unproven." I read it as an actual data point with a sign. If thousands of hostile skills existed in a live, growing registry, and the ecosystem's conversion rate were anywhere near what the percentages imply, we would already be reading about the first enterprise data exfiltration. We are not. That silence is informative. The most likely explanation is that the installation and successful-execution rate of malicious skills is extremely low — that most hostile skills are never invoked, or are invoked in environments with nothing worth stealing.

That would mean the real-world exposure is far below what 18.9% suggests, not because the skills are harmless, but because the attack requires the victim to do something specific: install the skill, give the agent tool access, and run it in a context with sensitive data. Population statistics ignore that funnel. Threat statistics live inside it.

Now the second contrarian correction: compare the numbers to history. Malicious packages on npm have historically run in the range of roughly 0.5% to 5% depending on methodology and window. Malicious Chrome Web Store extensions, when studied, cluster in a similar low-single-digit band. If agent skills really sit at 13% to 20%, the ecosystem is one to two orders of magnitude worse than any comparable software marketplace in history.

That is a claim that demands extraordinary evidence. And what we have is three studies with inconsistent definitions and unverifiable sources. Extraordinary claims with ordinary evidence should be discounted, not amplified. The honest reading is directional: agent skills carry a structurally novel risk that existing marketplaces did not have, and the magnitude of that risk is currently unknown and probably overstated.

Third correction: the article's own headline contradicted its own body. The title asserted skills had "never been vetted." The ninth paragraph noted that the registry operator had deployed VirusTotal integration and a tool called ClawScan from February 2026. Those two statements cannot both be true in their strongest form. What is accurate is narrower and less dramatic: the registry was never subjected to complete behavioral integrity verification. Saying a system was "never vetted" when it had a static scanner running is the kind of absolutism that serves distribution, not accuracy. Forensic architecture reveals the architect — and here the architect is a headline optimized for a feed, not for a decision.

Fourth, and this is the structural one: open source cuts both ways in this specific market. OpenClaw's transparency lets defenders inspect the runtime. It also lets attackers audit the exact execution environment and build precisely targeted payloads. Closed platforms retain a weak, unfashionable, but real advantage: security through obscurity. The open ecosystem traded that away for speed, and it must now buy back the equivalent protection with something stronger than obscurity — signatures, permission declarations, runtime sandboxing, semantic review — none of which it currently has in enforced form.

Finally, the governance tax nobody priced. OpenClaw was renamed twice before it was OpenClaw. A registry that has cycled through identity changes has an immature governance surface. Enterprise procurement reads that signal, and it reads it against a backdrop of active security research. Security is no longer a compliance line item for an agent platform. It is the differentiator. Anthropic's Claude Skills took the opposite route — pre-vetted, official and partner submissions, slower, lower-risk. OpenAI's Apps SDK and GPT Store sit in the middle with real but imperfect review. MCP servers, the protocol layer Anthropic leads, share the same missing-signature flaw and have already shown Plugin4Shell-class problems. The competitive landscape is not "who has the most skills." It is about to invert into "who has the fewest unvetted ones."

The Industry Shift: From Compliance Cost to Competitive Moat

Here is the forward mechanism I think matters most for anyone building or buying in this space.

In the last decade, the supply chain security market followed a predictable arc. A category of risk was discovered, reported, and then — three to five years later — monetized as tooling. Container security and cloud security both took that long from problem disclosure to meaningful revenue. Agent skill security is at the disclosure stage. The tooling category that emerges will look like SCA for agents: inventory, runtime detection, semantic audit.

The operational wedge for enterprises is clear and I would frame it as three capabilities that map onto existing frameworks. First, AI asset inventory — an AI-BOM that enumerates every agent and installed skill in production. Second, agent runtime monitoring — capturing the tool call chain and the file and network access trail, an "agent EDR." Third, semantic-layer audit — versioned review of prompts and memory files. These do not require new compliance religions. They slot into SOC 2 and ISO 27001 control extensions that enterprises already run.

But note what is missing from that trio and what almost nobody has built: there is no product for agent memory version control and forensics. What is needed is Git plus Sigstore for MEMORY.md — signed snapshots, diffable history, baseline restoration. The analogy is exact: a signed, versioned, auditable memory layer would give an enterprise the ability to answer the only question that matters after an incident — what did this agent know, and when did it start knowing it. Nobody ships this today. That is the clearest whitespace in the entire category.

And the regulatory clock is already running. The EU AI Act's GPAI supply chain transparency obligations and China's generative AI service measures both push toward treating third-party agent skills as regulated AI components, with traceability and revocation requirements. An ecosystem that cannot yet sign a skill file cannot meet a revocation standard. The compliance gap is not small. It is categorical.

Red Flag Metrics: What to Watch

I do not end reports with summaries. I end them with monitors.

Short horizon, zero to six months. Watch whether ClawHub introduces signing — Sigstore or cosign class — plus enforced permission declarations and mandatory sandboxing. That single development, more than any security report, tells you whether the ecosystem is serious. Watch whether the three vendors ship commercial agent security products with public pricing; that confirms the report-to-product funnel is complete. And watch for the first confirmed data exfiltration or financial loss attributable to an agent skill. That event, if it comes, is the inflection — it would invalidate my conservative read on conversion rates and force every risk estimate upward.

Medium horizon, six to eighteen months. Track the ratio of daily submissions to review coverage. If submissions keep climbing toward 500-plus per day while review capacity stays flat, risk rises monotonically regardless of any single study. Watch whether the three research methodologies are published in reproducible form; that determines whether their numbers ever become trustworthy. Watch for the first cyber insurance product that prices agent supply chain risk — its absence tells you the actuaries have no loss data either.

Long horizon, eighteen to thirty-six months. Watch whether skill security review becomes a standard clause in enterprise agent procurement. Watch whether agent memory forensics produces a legal precedent that assigns liability among the skill author, the registry operator, and the deploying enterprise. That precedent — which does not exist — is the single most important unbuilt thing in this entire domain, because without it, no enterprise can answer who is responsible when a poisoned memory file causes a breach.

The uncomfortable truth of this event is not that agents are insecure. It is that the industry finally met an attack surface it cannot sign its way out of. When the payload is a sentence, the defense has to reason about meaning — and meaning is the one thing that has never had a signature.

The number to hold onto is not 18.9%. It is zero — the number of confirmed victims the entire body of reporting produced. That zero is either the calm before a real storm, or the market's quiet correction of a vendor narrative running ahead of its evidence. Which one it is will be settled in the next twelve months, on-chain, in the logs, and in the memory files nobody is watching.