Malicious Agent Skills: Hidden Payloads and Shadow Features (OWASP AST01)
What happened
Malicious agent skills are legitimate-appearing skills, published to agent marketplaces, that carry hidden malicious payloads. This is the top entry in the OWASP Agentic Skills Top 10 - AST01 Malicious Skills. The severity comes from the execution model: agent skills are reusable capability packages (markdown instructions plus code) that load into an AI agent and run with the agent's full permissions across platforms like OpenClaw, Claude Code, Cursor, and VS Code. A skill that gets installed inherits everything the agent can reach, which is why a single poisoned package can escalate into full compromise of the agent's environment.
What makes this class distinctive is that the attacks are not single-layer. Reporting states that 100% of malicious skills combined both attack vectors: a code-layer attack using shell scripts and Python calls to execute actions directly, and a natural-language instruction attack embedded in the skill's markdown documentation to steer the agent through prose it treats as trusted context. Blocking one layer alone does not neutralize the skill. The instruction-layer half is the same mechanism we cover in indirect prompt injection explained - adversarial instructions arriving as data the model reads and follows.
The attack methods
Across analyzed campaigns, malicious skills leaned on a consistent set of techniques to get installed, hide their behavior, persist, and phone home.
| Method | Description |
|---|---|
| Typosquatting | Publishing a skill under a name that closely mimics a trusted one - for example gogle-workspace versus google-workspace - so a user installs the impostor by mistake. |
| Social engineering via fake prerequisites | Presenting fabricated setup steps or prerequisites that trick the user into granting access, installing extra components, or disabling safeguards. |
| Persistence via identity-file modification | Modifying agent identity files such as SOUL.md and MEMORY.md so the malicious behavior survives across sessions and is re-established even after a restart. |
| Identity cloning and impersonation | Cloning or impersonating a trusted identity so the skill's actions appear to originate from a legitimate source. |
| WebSocket hijacking for command-and-control | Opening or hijacking a WebSocket channel to establish command-and-control, letting an attacker issue instructions to the agent after install. |
Typosquatting and fake prerequisites get the skill onto the endpoint; identity-file modification and identity cloning keep it there and disguise it; WebSocket hijacking turns the installed skill into a controllable foothold. Each technique is individually familiar from other supply-chain contexts, but combined inside a package that runs with the agent's full authority they compound quickly.
The evidence: ClawHavoc and the USENIX 2026 study
The real-world scale is documented. The ClawHavoc campaign, in January 2026, deployed 1,184 malicious skills across 12 publisher accounts - an industrialized effort rather than a handful of one-off bad packages. ClawHavoc had two faces. This advisory covers the malicious-skills supply angle: the poisoned packages themselves and how they were built. The companion advisory on the OpenClaw security crisis and exposed agents covers the other face - the running, exposed agents and infrastructure that resulted from the campaign. Read together they describe both the supply side and the exposure side of the same event.
The measurement comes from a USENIX Security 2026 study that analyzed 98,380 skills and confirmed 157 malicious skills carrying 632 total vulnerabilities. The most important finding for defenders is that 73.2% of the malicious skills implemented shadow features - functionality hidden from the user. In other words, the majority of malicious skills did something beyond their advertised behavior. A skill that presents as a formatting helper may quietly modify identity files, clone an identity, or open a control channel. That gap between visible function and hidden behavior is precisely what makes a one-time marketplace inspection unreliable.
Why marketplace approval is not enough
The instinct is to trust the marketplace: if a skill is listed and approved, it must be safe. Malicious skills are engineered to defeat that instinct. They typosquat trusted names so the wrong one gets installed. They use fake prerequisites to socially engineer the user past safeguards. And with shadow features present in nearly three-quarters of confirmed malicious skills, the behavior that matters is deliberately not the behavior on display at review time.
Approval is a point-in-time gate. The harmful behavior frequently manifests at runtime, after install, or through a control channel opened later. This is the same structural blindness that makes the sibling SkillJacking dependency-takeover attack so effective: the danger lives outside the moment of review. Covering it requires continuous inventory, continuous vetting, and enforcement at execution time. For the fundamentals of what skills are and why they carry the agent's full authority, see the agent skills security primer and the OWASP Agentic Skills Top 10 guide.
How Anomity surfaces and governs it
Anomity discovers skills as one of the eight AI artifact types its lightweight, unprivileged Endpoint Sensor inventories on every managed endpoint - alongside AI agents, MCP servers, extensions, plugins, secrets, hooks, and CLIs. That means you know every skill actually installed across the fleet, rather than trusting a marketplace label or an approval that happened months ago. Anomity sends metadata only over HTTPS - never source code, never prompts - with secrets redacted on the endpoint, so inventorying skills does not itself become a data-exposure risk.
Two capabilities map directly to the techniques above. First, because Anomity tracks every added, removed, and modified artifact in a queryable 90-day audit trail, the persistence technique of modifying identity files such as SOUL.md and MEMORY.md becomes an observable, timestamped event rather than a silent change. Second, on agents that expose a hook, Anomity applies runtime governance - returning allow, deny, or log on each tool call before it runs. A shadow feature that tries to execute a shell script, make a Python call, or open an outbound WebSocket for command-and-control is evaluated against policy first, so the hidden half of a malicious skill hits a decision point before it acts. Violations route to your SIEM, Slack, email, and Jira through continuous policy evaluation.
You can't govern what you can't see.The Anomity principle
What to check across your fleet
- Inventory every installed skill on every endpoint and reconcile it against what was actually approved - assume the marketplace label is not proof of safety.
- Watch for typosquatted names that closely mimic trusted skills, and confirm the exact publisher of each installed skill.
- Monitor agent identity files such as
SOUL.mdandMEMORY.mdfor unexpected modification, a common persistence technique. - Treat any skill with behavior beyond its advertised function as a shadow-feature candidate; 73.2% of confirmed malicious skills hid functionality from the user.
- Apply runtime governance so shell execution, Python calls, and outbound WebSocket connections from a skill are evaluated against policy before they run.
- Make vetting continuous rather than a one-time approval gate, since the harmful behavior often only appears after install.
Malicious skills are the top of the OWASP Agentic Skills Top 10 for a reason: they run with the agent's full authority and hide most of what they do. This advisory is part of our Agent Skills Security coverage. To see which skills across your fleet carry shadow features and what runtime governance would deny, book a 30-minute demo.
Frequently asked questions
What is a malicious agent skill?
It is a skill published to an agent marketplace that looks legitimate but carries a hidden payload. Because skills load into an AI agent and run with the agent's full permissions, a malicious skill inherits everything the agent can do. OWASP tracks this as AST01 Malicious Skills, the top entry in the OWASP Agentic Skills Top 10.
How do malicious skills combine two attack layers?
Reporting states that 100% of malicious skills combined both a code-layer attack and a natural-language instruction attack. The code layer uses shell scripts and Python calls to execute actions directly, while the instruction layer embeds adversarial directions inside the skill's markdown documentation so the agent is steered by prose it reads as trusted context. Combining the two means blocking one layer alone does not neutralize the skill.
What is the ClawHavoc campaign?
ClawHavoc was a malicious-skill campaign in January 2026 that deployed 1,184 malicious skills across 12 publisher accounts. This advisory covers the malicious-skills supply angle - the poisoned packages themselves. The separate advisory on the OpenClaw security crisis and exposed agents covers the other side of ClawHavoc: the running, exposed agents and infrastructure that resulted.
What did the USENIX Security 2026 study find?
The study analyzed 98,380 skills and confirmed 157 malicious skills carrying 632 total vulnerabilities. Notably, 73.2% of the malicious skills implemented shadow features - functionality hidden from the user. That means the majority of malicious skills did something beyond what the user could see, which is exactly what makes point-in-time inspection unreliable.
What are shadow features?
Shadow features are capabilities a skill executes that are hidden from the user, distinct from the advertised function the skill appears to perform. A skill might present as a formatting helper while quietly modifying identity files, cloning an identity, or opening a command-and-control channel. Because 73.2% of malicious skills in the USENIX study used them, assume the visible behavior of a skill is not the whole story.
How does Anomity help with malicious skills?
Anomity discovers skills as one of the eight AI artifact types its Endpoint Sensor inventories, so you know every skill installed across the fleet rather than trusting a marketplace label. It watches for persistence techniques like modification of identity files such as SOUL.md and MEMORY.md, and records every added, removed, and modified artifact in a queryable 90-day audit trail. On agents that expose a hook, it allows, denies, or logs each tool call before it runs, so a shadow feature attempting shell execution or an outbound WebSocket is evaluated against policy first.
Isn't marketplace approval enough to catch these?
No. Malicious skills are built to pass inspection - they typosquat trusted names, use fake prerequisites for social engineering, and hide the majority of their behavior as shadow features. Approval is a one-time gate, but the harmful behavior often only manifests at runtime or after install. Continuous inventory, vetting, and runtime governance are required to cover the gap.
