Securing AI Agent Skills: The New Supply Chain Risk

In early February 2026, security researchers confirmed that ClawHavoc, a coordinated campaign targeting ClawHub, the skill marketplace for the open-source AI agent OpenClaw, had planted 1,184 malicious skills across the registry. Skill marketplaces are now the software supply chain for AI agents, and that number is the clearest evidence yet of what happens when nobody is guarding the loading dock. For the full risk-to-control mapping, see the OWASP Agentic Skills Top 10.

What Are AI Agent Skills, and Why Do They Need Their Own Supply Chain

A skill is a downloadable capability package that teaches an AI agent how to interact with a specific tool, API, or service, distributed through open marketplaces and installed with a single command, often without any friction beyond copying a URL or running a one-line install. This is functionally identical to how npm packages extend Node.js or PyPI packages extend Python, and the parallel matters because it means agent skills inherit the same supply chain risks that have plagued open-source package ecosystems for years: typosquatting, credential harvesting, and malicious code hiding behind a plausible README that describes exactly the functionality a developer went looking for.

The risk profile is worse, not equivalent. A malicious npm package might steal a credential from a single process or corrupt a build pipeline. A malicious agent skill inherits the full permission set of the agent running it, meaning access to file systems, cloud credentials, persistent memory, and outbound network channels, while simultaneously being positioned to manipulate the agent's own reasoning through embedded prompt injection. Security researchers have named this combination the "lethal trifecta": access to private data, exposure to untrusted content, and the ability to communicate externally. Most production agent deployments today satisfy all three conditions simultaneously, which is exactly the environment a malicious skill is designed to exploit, and it's a combination that traditional software supply chain risk almost never presents all at once in a single package.

The Runtime Trust Problem

A skill file can look completely safe at install time and still change behavior later, and this is the core limitation that every static defense runs into. A skill's manifest can be reviewed, its source code scanned, and its description read by a human or an LLM evaluator, none of which reveals what the skill actually does once it's running with live network access and real credentials. A common pattern involves a skill that behaves exactly as advertised during review, then fetches additional instructions or payloads from a remote URL at runtime, well after any static check has passed and the skill has already earned a clean bill of health.

Air Security's June 2026 research, "The Story of Skills," demonstrated exactly how effective this gap is in practice. Researchers built a deliberately malicious skill and distributed it through a trusted marketplace and social media as a proof of concept, essentially testing whether the entire ecosystem's existing defenses could catch something built specifically to slip past them. The skill reached more than 26,000 agents before it was pulled, and every scanner that evaluated it along the way cleared it as safe. The skill wasn't sophisticated in a technical sense; it was simply designed to look inert to anything that wasn't actually executing it, which is precisely the blind spot static analysis and LLM-based review both share, regardless of how thorough either check appears on paper.

ClawHavoc: What 1,184 Malicious Skills in One Campaign Actually Looked Like

The campaign began quietly. The first malicious skill appeared on ClawHub on January 27, 2026, and wasn't flagged. Upload volume surged on January 31, when a single attacker account, tracked as hightower6eu, began mass-publishing skills across nearly every category on the platform; that account alone would eventually account for 677 of the total malicious packages, more than half the entire campaign's output. Koi Security publicly named the campaign ClawHavoc on February 1, and by February 5, Antiy CERT's post-incident analysis had identified 1,184 malicious skill packages tied to 12 distinct author accounts, a figure that continued climbing even after ClawHub began removing flagged entries.

The skills themselves were designed to look unremarkable and desirable rather than obviously suspicious. Attackers targeted high-value, high-download categories: cryptocurrency price trackers, Polymarket trading bots, YouTube utilities, and typosquatted variants of the ClawHub CLI tool itself, alongside a fake "weather assistant" skill that quietly stole OpenClaw's local environment file to expose API keys for paid AI services. Every malicious skill shipped with a professional-looking SKILL.md, complete with proper formatting, feature descriptions, and version history, which is precisely why manual review and casual scanning missed most of them for as long as they did. Payloads were delivered through three main mechanisms: staged downloads pulling additional malware after installation, reverse shells executed through Python system calls, and direct credential grabs targeting whatever sensitive files sat within reach. On macOS specifically, one payload tied to an upgraded variant of the Atomic macOS Stealer harvested browser credentials, keychain passwords, Telegram data, SSH keys, and cryptocurrency wallets, then compressed and exfiltrated all of it to attacker-controlled infrastructure, all without the skill ever needing to announce what it was actually doing.

Why Skills Cross Ecosystems by Design

Malicious skill campaigns don't stay contained to the platform where they originated, because attackers deliberately port working payloads across ecosystems to maximize reach before defenders catch up. A skill designed for OpenClaw's ClawHub marketplace can be lightly reformatted and republished for Cursor, VS Code extensions, or distributed as a Model Context Protocol server, since the underlying attack, whether it's a credential-stealing payload or a prompt-injection-based instruction override, doesn't actually depend on the specific platform's plumbing to work. This cross-posting is efficient for attackers precisely because most security teams evaluate tools on a per-platform basis, treating each marketplace as its own contained risk surface with its own review process, so a payload that's been flagged and removed from one marketplace can continue circulating, unflagged, on another for weeks. Defending against this pattern requires threat intelligence and detection that spans ecosystems rather than a platform-by-platform approach, since a signature or indicator discovered on one marketplace is often directly reusable to catch the same payload appearing somewhere else entirely.

The 53,000+ Blind Spot

By March 2026, SecurityScorecard's threat intelligence team had confirmed more than 135,000 OpenClaw instances publicly exposed to the internet with insecure default configurations, and more than 53,000 of those exposed instances correlated directly with prior breach activity. That number is a striking proxy for a much broader organizational problem: most companies running AI agents cannot answer a basic question about their own environment, namely what skills are actually installed and running across it. There's typically no inventory tracking of which skills exist, no approval workflow gating what gets installed, and no audit logging capturing what a given skill has actually done since it was added, which means the gap isn't a matter of degree so much as a total absence of visibility. Bitdefender's enterprise telemetry from the same period confirmed the mechanism behind this gap directly: employees were installing OpenClaw and its skills on corporate devices using single-line install commands, with no security review and no SOC visibility into the deployment at all. A skill running without inventory, approval, or logging isn't a monitored risk with unknown severity; it's an unknown entirely, indistinguishable from nothing being wrong until it demonstrably is, at which point the organization is reconstructing what happened after the fact rather than catching it in progress.

Static Analysis vs. Dynamic Detonation

Why Static Scanning and LLM-Based Evaluation Both Miss Runtime Behavior

The current default approach to skill security relies on one of two methods, and neither actually executes the skill being evaluated. Static code analysis reads a skill's source and manifest, pattern-matching against known-malicious signatures, but it cannot see behavior that only manifests when the skill actually runs, such as a remote payload fetch triggered by a specific condition that never appears anywhere in the code's static structure. LLM-based evaluation, where a model is asked to review a skill's manifest and judge whether it looks safe, has a deeper structural flaw: the same class of technology that can be manipulated through prompt injection is being used as the security gate itself. A skill built specifically to evade an LLM evaluator can include content designed to influence the evaluating model's judgment, meaning the judge and the defendant are effectively built from the same underlying architecture. Snyk's own February 2026 research into this exact limitation concluded that pattern-matching scanners provide a false sense of security precisely because they validate structure, not behavior, and structure is the one property a determined attacker can always make look clean.

The Sandbox Detonation Approach (and What It Catches That Static Methods Don't)

Sandbox detonation applies a methodology the broader cybersecurity industry has relied on for years to evaluate suspicious executables, adapted specifically to the agent skill ecosystem. Rather than reading a skill's code, this approach executes the skill in a fully controlled, isolated environment and records everything it actually does: every LLM action, every network call and domain resolution, every file write, and every attempt to access environment variables or credentials. Encrypted SSL traffic gets intercepted and decrypted for inspection rather than passed through blind, and the resulting behavioral record gets evaluated against detection engines built for exactly this kind of evidence rather than static pattern matching, giving analysts a verdict backed by what the skill did rather than what its code merely implied it might do.

This catches precisely the category of threat static methods miss: a skill that behaves innocuously during any code review but fetches a malicious payload from a remote URL only under specific runtime conditions, or a skill that waits for a particular trigger before attempting credential exfiltration. Because detonation observes actual behavior rather than inferring intent from source code or manifest text, it isn't vulnerable to the same evasion techniques that defeat both static scanners and LLM judges, since there's no static artifact for an attacker to disguise in the first place. Permiso Security's SandyClaw platform, launched in April 2026 as the first dynamic sandbox built specifically for AI agent skills, works across major agent frameworks including OpenClaw, Cursor, and Codex, reflecting the same cross-ecosystem reality that makes skill threats hard to contain through single-platform defenses alone.

Building a Skill Governance Program

A functioning skill governance program rests on three pillars. Inventory comes first, since an organization can't govern what it can't see; this means continuous, automated discovery of every skill installed across every agent, not a periodic manual survey that's stale within days of being compiled. Approval workflows come next, gating new skill installations behind a review step rather than allowing direct, unmonitored installation by individual employees or developers, however convenient that direct path might be. Continuous revalidation closes the loop, since a skill that was safe at install time can be updated by its publisher into something malicious later, meaning a one-time approval isn't sufficient on its own and needs to be paired with ongoing checks that trigger whenever a skill's underlying code changes. Full implementation guidance, including specific workflow configurations, is covered in Akto's release notes and in the OWASP Agentic Skills Top 10 documentation rather than repeated here.

How Akto Secures AI Agent Skills

Akto's May 2026 release extended its AI security platform to cover the skill supply chain directly, applying continuous discovery and red teaming to the same class of risk that produced ClawHavoc. Rather than relying solely on static manifest review, Akto's approach is built around the recognition that skill risk is fundamentally a runtime problem, mapping directly onto the categories defined in the OWASP Agentic Skills Top 10 so that findings translate into audit-ready evidence rather than an unstructured list of flagged files a security team has to manually triage. Discovered skills feed into the same AI Agent Context Graph that powers Akto's broader agent security coverage, meaning a newly installed skill is immediately visible alongside the agents, tools, and permissions it can reach, rather than existing as an isolated, unmonitored addition to the environment that nobody notices until something goes wrong.

FAQs: Securing AI Agent Skills

What are AI agent skills, and why are they considered a supply chain risk?

AI agent skills are downloadable capability packages that teach an agent how to interact with a specific tool, API, or service, distributed through open marketplaces much like npm or PyPI packages. They're a supply chain risk because a malicious skill inherits the full permission set of the agent running it, including file system access, credentials, and network egress, while also being positioned to manipulate the agent's reasoning directly through prompt injection.

What was the ClawHavoc campaign, and how many malicious skills did it involve?

ClawHavoc was a coordinated supply chain attack against ClawHub, the skill marketplace for the OpenClaw AI agent, beginning January 27, 2026. By February 5, security researchers at Antiy CERT had confirmed 1,184 malicious skill packages tied to 12 attacker accounts, delivering payloads including credential-stealing malware and reverse shells.

How can a skill file look safe during installation but become malicious later?

A skill's manifest and source code can pass every static review while containing logic that only triggers malicious behavior at runtime, such as fetching an additional payload from a remote URL under specific conditions. Because static analysis and LLM-based evaluation never actually execute the skill, neither method can observe behavior that only manifests once the skill is running live.

Why do malicious skills get deliberately ported across Claude Code, Cursor, and other tools?

Attackers reformat and republish working payloads across ecosystems because the underlying attack mechanism doesn't depend on any single platform's plumbing, and most security teams evaluate tools on a per-platform basis. A payload removed from one marketplace can continue circulating unflagged on another for weeks, making cross-ecosystem porting an efficient way to maximize reach and outrun single-platform detection.

What percentage of organizations have no inventory or monitoring of the skills they use?

There isn't a single official percentage, but the scale of the underlying problem is well documented: SecurityScorecard confirmed more than 53,000 exposed OpenClaw instances correlated with prior breach activity in March 2026, and enterprise telemetry from the same period confirmed employees regularly installing agent skills on corporate devices with no security review and no SOC visibility whatsoever.

Why can't static code analysis or LLM-based evaluation fully catch malicious skill behavior?

Static analysis reads code and manifests but cannot observe behavior that only appears at runtime, such as a conditional payload fetch. LLM-based evaluation has a deeper flaw: the same technology vulnerable to prompt injection is being used as the judge, so a skill built to evade an LLM evaluator can include content specifically designed to influence that evaluator's own judgment.

What is sandbox detonation, and how does it differ from static analysis?

Sandbox detonation executes a skill in a fully isolated, controlled environment and records everything it actually does, including network calls, file writes, and credential access attempts, rather than inferring intent from source code. This catches behavior, like a remote payload fetch under specific conditions, that static analysis and LLM review both miss because neither ever executes the skill.

What does the OWASP Agentic Skills Top 10 framework cover?

It provides a structured risk-to-control mapping specifically for the agent skill supply chain, drawing on documented real-world incidents including ClawHavoc, along with vulnerability research from firms like Snyk, SecurityScorecard, and Air Security, to define the categories of risk a skill governance program needs to address.

What should a skill governance program actually include?

At minimum, continuous automated inventory of every installed skill, an approval workflow gating new installations rather than allowing unmonitored direct installs, and continuous revalidation, since a skill that was safe when approved can be updated into something malicious afterward without triggering a fresh review.

How does Akto detect and govern AI agent skills across an organization?

Akto's May 2026 release extended continuous discovery and red teaming to the skill supply chain, mapping findings to the OWASP Agentic Skills Top 10 and feeding discovered skills into the same AI Agent Context Graph that tracks agents, tools, and permissions, so a newly installed skill is immediately visible within the broader environment rather than existing as an isolated blind spot.