The Next AI Supply Chain Risk: Malicious Skills in Agentic AI

Executive Summary

Agentic AI has arrived, and its adoption has moved faster than most anticipated. Everyday users already run agents that browse the web, manage files, write code, and execute tasks autonomously on their personal machines. Enterprise adoption is following close behind, with coding agents becoming the most sought-after category. 

At the heart of modern agentic AI solutions is the skills layer: modular, shareable instruction sets that tell agents what to do and how to do it. Paired with a rapidly expanding MCP ecosystem, skills are becoming the connective tissue of agentic AI, a marketplace of agent capabilities that is growing faster than security practices have kept pace with. As agents move up the corporate toolbox, they bring their attack surfaces with them. Although most of the publicly known in-the-wild incidents so far occurred in the consumer space, the attack techniques can be easily applied to enterprise settings, and businesses constitute much more profitable targets, not to mention they also have much more to lose.

The software industry learned the hard way that supply chains are the favorite targets for adversaries. The fastest way to compromise many systems at once is to compromise the thing they all depend on, and the skills infrastructure is shaping up to be the next major supply chain risk. In enterprise environments, developer workstations are particularly attractive targets because they contain valuable intellectual property, including source code, proprietary models, business logic, cloud credentials, and other sensitive development artifacts. By compromising a developer workstation, attackers can not only gain access to sensitive information but also potentially influence the software and AI supply chain itself, creating downstream risk for every system that depends on it.

This post examines how consumer agents have been targeted through malicious skills, using OpenClaw as a case study, and explores what happens when those same patterns reach enterprise environments where the blast radius is bigger, the data is more sensitive, and the stakes are much higher.

Agentic anatomy

Over the past few years, AI assistants have evolved from simple chatbots into autonomous agents capable of executing real-world tasks. By combining tools that take actions, skills that enhance capability, and a reasoning model that decides which capability fits the situation, agents are changing the nature of work, dramatically shortening the path from idea to action. 

What is an Agent?

Before delving into skills, it's worth taking a step back to examine what an agent actually is. Having the right mental model makes it much easier to see where the real problems lie and realize that many of them stem from similar insecurities faced by traditional software. 

Fundamentally, an agent is just a software package, and like any software package, it needs functions and business logic to operate. The difference between traditional software and agentic solutions, though, is that the agent’s logic is largely inferred, as opposed to being hardwired in its code. In other words, a significant portion of an agent’s behavior is derived from prompts, context, available tools, and the model’s reasoning capabilities. A reasoning LLM takes the place of a developer thinking through what the user wants and how the application should achieve it. To do that, the model needs context: what its role is, what the goal is, how data will reach it, which tools it has available, and what those tools are good for. That last part - the playbooks describing when and how to use the tools - is what skills are. The diagram below is a simplified view of the major components inside an agent.

The yellow box marks the agent's boundary; everything inside it is part of the system.

Orchestrator. If the agent were a living organism, the orchestrator would be its nervous system: it relays messages between components and keeps the whole system in communication. Several orchestrators exist on the market: Strands, CrewAI, LangGraph, N8N, and the one currently making the most headlines is OpenClaw, which we'll come back to shortly.

Tools. Sticking with the biological analogy, tools are the hands - the parts that reach beyond the agent's boundary to act on the outside world. In practice, that means code, APIs, CLI commands, and anything else that can change state outside the agent itself.

Memory. Long-term recall. Memory keeps responses consistent over time and gives the model context to reason from, it is the cerebral cortex of the agent.

Skills. Learned behaviors, in the same sense that a person who has done something before knows how to do it again. Skills are passed to the model as explicit workflows: how to call a particular tool, what to do with the output, and when to use it. The Matrix analogy fits well: instead of working out how to use a tool from first principles, the agent is handed the instructions, like Neo blinking and saying, "I know Kung Fu."

LLM. The brain, or at least the chain-of-thought engine. The model takes in the context, skills, tool descriptions, and the user's request, and produces the instructions that the orchestrator then acts on. A reasoning model is generally preferable for this role. 

The Skills Ecosystem and its Security Gap

The skills framework that underpins much of modern agentic systems’ functionality was originally introduced by Anthropic within its Claude environment before being published as an open standard in December 2025. Since then, the standard has been swiftly adopted by major players, including OpenAI, Cursor, and GitHub Copilot, and has gained even wider popularity thanks to OpenClaw. 

To perform well in specific use cases, agents need to acquire the necessary capabilities, called “skills.” The skills mechanism is similar to a software package manager, where users can browse and install plugins and extensions. In this case, these extensions contain specialized instruction manuals for the agents.

The most important part of the skill package is a Markdown file called SKILL.md that stores the instructions the agent reads at runtime. These instructions can teach the agent, for example, how to use specific tools, execute shell commands, or interact with APIs. The markdown can also include specific examples of how the skill should be used. A YAML header at the front of the file handles metadata such as name, description, required environment variables, required binaries on PATH, and supported platforms. Skill packages might also bundle other files, such as scripts and documents needed for execution. 

Similar to software packages, skills can be published to and downloaded from public repositories. One of the biggest repositories to date is ClawHub - the OpenClaw's official registry, containing over 70k skills as of June 2026. Skills are also distributed through GitHub repositories, mirror sites, and curated lists.

The skills system is simple, intuitive, and easy to use, but it comes with serious security drawbacks. Skills aren't cryptographically signed and are rarely properly vetted or reviewed; anyone with a GitHub account can publish one, and agents will happily ingest and execute whatever’s inside. It’s no surprise that malicious actors have already taken advantage of it, publishing skills that instruct OpenClaw agents to quietly download and run malware, or secretly enlist agents into crypto schemes. 

The fact that skill packages can bundle auxiliary files, including executable scripts, adds to the supply chain risks. Even if the skill itself does not contain any harmful instructions, compromised dependencies can silently introduce malicious code that executes with the same trust level as the rest of the package. Bundled files might often be overlooked by developers during audit, making it easy for vulnerabilities or backdoors to go unnoticed until they've already caused damage. Without any trust or verification model, the skills ecosystem becomes a perfect distribution channel for malware, both within the consumer and enterprise environments.

The OpenClaw Case Study: Hoodies Teaching Suits

One example of an extremely successful agentic framework underpinned by skills is OpenClaw. Built by Austrian developer Peter Steinberger, OpenClaw was first published in November 2025 and rapidly gained popularity, amassing over 370k stars on GitHub in less than half a year’s time. Why? Radical flexibility and true autonomy played a huge role. 

By design, skills and tools are meant to work in tandem: a tool does a discrete job, and a skill explains why, when, and how to use it. OpenClaw upended that paradigm by relying almost entirely on a single multipurpose tool, exec. Rather than coding up a new tool and exposing it to the agent, a skill could simply include a shell command to run, effectively removing the need to build or wire up tools. This allows for a great degree of flexibility.

Before OpenClaw, the vast majority of agents would act only when prompted, which meant the user would constantly have to push them to complete the required work. OpenClaw introduces the concept of a scheduled check (HEARTBEAT.md) that the agent can run to see which tasks it can work on while the user is away, making its actions more autonomous.

Together, these shifts made OpenClaw both remarkably productive and a powerful accelerant for the burgeoning skills marketplace. The flexibility of that single tool turned skills into the most powerful lever in the agent ecosystem. However, as is often the case with rapidly adopted emerging technologies and solutions, the security aspect of OpenClaw lags behind, leaving the agents unprotected and easily exploitable. It shouldn’t come as a surprise that cybercriminals immediately began abusing these skills to have agents secretly perform harmful actions on their behalf. Malicious skills have been found in the wild just a couple of months after OpenClaw launched, making the ecosystem a rapidly emerging new supply-chain attack surface.

OpenClaw may not be part of most enterprise environments, but the lessons from this predominantly consumer agent translate directly to frameworks more popular with businesses, such as Claude Code, Cursor, and GitHub Copilot.

How Does This Risk Apply to Enterprise?

The same attack patterns naturally translate into the AI coding tools now standard in enterprise development workflows. Claude Code, Cursor, GitHub Copilot, and similar tools all support skills, extensions, plugins, or context files that shape agent behavior at runtime. A malicious skill can instruct an agent to exfiltrate code, inject subtle vulnerabilities, or route recommendations through attacker-controlled infrastructure, all while appearing to do routine work. These tools sit inside the IDE with read access to the entire codebase, and developers tend to trust their output without much scrutiny. An enterprise that carefully audits its software dependencies but places no controls on what context files its agents consume has a significant blind spot, and one that attackers are already likely probing.

In an enterprise environment, the threats described above carry significantly more weight. Developer workstations routinely running AI coding agents are the perfect entry point for attacks that can propagate silently across the organization. An infostealer like the AMOS variant doesn't just harvest one developer's credentials; it can surface cloud keys, CI/CD tokens, and internal API secrets that open doors deep into production infrastructure. Enterprises also tend to grant agents broader permissions and access to more sensitive systems, meaning a compromised skill can have a blast radius that a consumer deployment simply wouldn't.

The more subtle threats may actually pose the greater risk in corporate settings. The crypto-swarm pattern, where agents are quietly enrolled in unauthorized work, translates directly into rogue compute consumption, potential data exposure to unknown external servers, and serious compliance headaches. The affiliate manipulation case highlights a similar governance gap: procurement and vendor decisions increasingly routed through AI agents could be quietly shaped by whoever wrote the skill, with no audit trail and no disclosure. Enterprises typically have policies governing conflicts of interest and purchasing authority, and skills that silently subvert those decisions represent a category of risk that existing security tooling is poorly positioned to catch.

Mitigations

Mitigating the risks in the agentic skills ecosystem requires defenses at several layers. First of all, skill repositories should conduct their own security audits and carefully vet all skills before publishing them. This requires more than just traditional malware scanners, as harmful instructions written in natural language can be much subtler and therefore more difficult to detect than typical malicious code. ClawHub's existing audits, for example, can catch known malware and alert on suspicious domains, but miss less obvious issues, such as an affiliate link quietly inserted into every recommendation. Skill registries should adopt a model closer to app store review, where skills are scanned and audited before publication rather than flagged reactively after reports come in. Auditing that focuses only on malicious code misses the broader category of skills that are technically clean but behaviourally compromised, and any serious skill safety framework needs to account for both.

Skill integrity should be treated the same way the software industry treats package integrity: through cryptographic signing and verified provenance. Just as modern package managers check signatures before installing a dependency, agent runtimes could require that skills are signed by a known and trusted publisher, with the signature covering the full contents of the skill package, including any bundled scripts. This would make tampering detectable and raise the cost of distributing malicious skills through mirror sites or curated lists, where provenance is currently easy to spoof. 

Companies should implement their own security scanners, as well as other traditional solutions, such as network filtering against declared domains, allow lists for shell commands, and runtime analysis of what a skill is actually doing. Stronger controls include sandboxing skills by default. Rather than allowing a skill to run with the same permissions as the developer or the agent, a sandboxed runtime constrains what the skill can actually do: limiting network access to known endpoints, restricting filesystem reads and writes to designated directories, and preventing the kind of silent outbound connections that the crypto-swarm and infostealer campaigns depended on. This doesn't require trusting the skill author to behave honestly; it shifts the security model so that a malicious SKILL.md simply cannot reach the resources it needs to cause harm, regardless of what its instructions say. Sandboxing is not a complete solution on its own, as a skill that operates entirely within its permitted scope can still manipulate agent behavior in subtle ways, but it significantly raises the cost of attack and eliminates the most straightforward classes of abuse described here.

Frameworks, such as the OWASP Top 10 for Agentic Applications and OWASP Agentic Skills Top 10 (AST10), can help businesses map the risks in an agentic environment. The Top 10 for Agentic Applications targets risks specific to autonomous systems, including prompt injection, memory poisoning, and unsafe tool execution that emerge when agents chain actions together without human oversight. AST10, on the other hand, covers malicious skills and supply-chain compromise, excessive permissions that most skills request, misleading metadata, and weak agent isolation. It also proposes a Universal Skill Format with signed publishers, content hashes, domain allowlists, and explicit risk tiers.

Takeaways

The skills mechanism is a powerful capability that is outpacing the security thinking around it. The attacks we’ve seen in the wild so far span a wide spectrum, from straightforward malware delivery to subtle behavioral manipulation, and they share a common trait: they exploit the implicit trust that agents and their operators place in skill content. That trust is currently largely unearned. 

It is also worth noting that the consumer-level nature of many of these threats does not limit their relevance to enterprises. Developers who install skills on personal machines or pull from public registries without organizational oversight introduce consumer-grade risk directly into the corporate environment. The boundary between personal and professional tool use in software development has always been porous, and agentic tools are no exception. Enterprises adopting agentic workflows, therefore, need to treat skills with the same scrutiny they apply to third-party code dependencies, which means sandboxed execution environments, cryptographic provenance checks, and audit processes that look at what a skill instructs an agent to do, not just whether it contains recognizable malicious code. 

The threat is not theoretical; malicious skills have already been found in the wild, and the attack surface will only grow as agents become more capable and more deeply embedded in enterprise workflows.

‍