OpenClaw skills show how AI extensions become malware channels

At a glance

What this is: This research shows that OpenClaw skills can turn an AI extension ecosystem into a malware delivery channel with host-level execution authority and weak guardrails.

Why it matters: It matters because IAM, NHI, and agentic AI governance all have to treat marketplace-installed skills as executable identities with credential and network reach, not just add-ons.

By the numbers:

• We audited 4,310 OpenClaw skills and analyzed 221 in depth.
• 44 skills were tied to a confirmed malware campaign, ClawHavoc, with 12,559+ downloads.
• 70.1% showed OAuth over-provisioning.
• 43.4% contained command injection patterns.

👉 Read Lakera's research on the OpenClaw agent skill malware channel

Context

OpenClaw skills are packaged capability extensions that can execute with the host environment's permissions, which makes them closer to software distribution than to simple prompts. The governance gap is straightforward: once third-party code can access credentials, shells, files, and network endpoints, the marketplace itself becomes part of the attack surface.

This is an agentic AI identity problem as much as a malware problem. The article shows what happens when execution authority is granted implicitly and review is weak, because the identity performing the action is not a human user but a skill with local privileges and broad access.

The starting position here is atypical in scale but typical in architecture. Many organisations are already adopting modular agent extensions before they have a control model for provenance, isolation, and privilege scoping.

Key questions

Q: How should security teams govern AI skills that can execute code locally?

A: Security teams should govern them like executable software with delegated authority. That means provenance checks, code review, minimal permissions, and runtime isolation are mandatory before installation in sensitive environments. If a skill can read files, use environment variables, or call out to the network, it needs identity-style controls, not just a marketplace listing review.

Q: Why do marketplace-installed AI extensions create such a large blast radius?

A: They inherit the permissions of the host environment, so one compromised extension can reach tokens, files, and network endpoints that were never meant to be shared. The blast radius grows when OAuth scopes are broad and when users trust labels instead of code behaviour. That combination turns one skill into many downstream compromises.

Q: What breaks when AI skills are allowed to run without sandboxing?

A: Without sandboxing, a skill is no longer a bounded feature. It becomes local code with access to the shell, filesystem, credentials, and outbound connectivity, which makes malware delivery and secret theft materially easier. The control failure is not just technical isolation, but the assumption that an extension can be trusted after install.

Q: Who is accountable when a malicious AI skill steals credentials?

A: Accountability is shared across the platform operator, the publisher, and the organisation that approved the skill for use. The operator is responsible for marketplace controls and execution boundaries, the publisher for code provenance, and the enterprise for permissioning and deployment decisions. The best governance model assigns ownership before compromise occurs.

Technical breakdown

Why agent skills behave like executable software

OpenClaw skills are not passive configuration. They are instructions and code that run locally, which means a skill can inherit the runtime authority of the host environment. In practical terms, that can include shell execution, file access, environment variables, and outbound network traffic. This is why the security boundary is not the skill description or marketplace category, but the execution context itself. Once a skill can reach secrets and networks, the extension layer becomes part of the identity and access model.

Practical implication: treat every installed skill as executable software that needs provenance, scope review, and isolation.

How malware hides inside a skills marketplace

The article's core abuse pattern is supply-chain style delivery. A benign-looking skill can encode a payload, decode it at runtime, and hand control to a shell, then fetch a second-stage component from attacker infrastructure. Typosquatting and category mimicry work because users trust naming and marketplace placement more than code inspection. That trust assumption is the weak point. If the platform does not verify what executes, the marketplace can distribute malware at scale without needing a direct phishing or exploit chain.

Practical implication: add publication review and cryptographic signing before marketplace distribution is trusted.

Why over-provisioned OAuth scopes increase blast radius

A skill that asks for broader OAuth permissions than its function needs creates a larger compromise surface even if it is not malicious. The article shows that scope inflation is common, which means a single compromised skill can inherit repository, cloud, or token access beyond its task. That is an identity governance issue, not just an appsec issue. Least privilege only works if the permissions granted to a skill are aligned to the smallest real workload it must perform.

Practical implication: tie every skill to a minimal permission set and reject broad OAuth grants by default.

Threat narrative

Attacker objective: The attacker aims to turn trusted AI extensions into a repeatable channel for credential theft, remote code execution, and downstream data exfiltration.

1. Entry occurs when users install a benign-looking skill from the marketplace, often after relying on naming, category placement, or perceived utility rather than source review.
2. Escalation happens when the skill executes locally with full host privileges, decodes an embedded payload, and reaches environment variables, filesystem objects, or shell execution.
3. Impact follows when the payload downloads a second stage, scans for tokens and credentials, and exfiltrates data to attacker-controlled infrastructure.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI skill marketplaces create an identity boundary, not just a software boundary: Once a third-party skill can execute with host privileges, the marketplace is granting operational authority, not merely functionality. That changes how security teams should think about trust, provenance, and delegated execution. The implication is that extension ecosystems need identity-style controls before they are treated as routine software distribution channels.

Agent skills expose an identity blast radius problem: When a single extension can reach tokens, files, and network paths, compromise is no longer limited to the skill itself. The attack surface expands through inherited authority, especially where OAuth scopes and environment variables are over-broad. Practitioners should recognise that blast radius is being set by execution rights, not by the advertised use case.

Marketplace trust is collapsing faster than review models can keep up: Users install skills based on labels, popularity, and convenience, but the article shows that those signals do not distinguish useful code from malicious code. That assumption was designed for curated app stores and lightweight add-ons. It fails when the actor is an executable AI skill that can fetch, decode, and run payloads at runtime. The implication is that provenance and sandboxing now matter more than marketplace optics.

OpenClaw skills are a supply-chain layer for AI agents: The combination of distribution, credential reach, and local execution makes these skills behave like software supply-chain dependencies rather than simple assistant features. That is why insecure design at the marketplace level propagates across many installations at once. For governance teams, the lesson is to stop separating AI extension risk from identity risk.

Governance has to move from install-time trust to runtime containment: The article's findings show that static approval is insufficient when a skill can execute arbitrary commands after installation. Security teams need to treat post-installation behaviour as the main control point, because the malicious action happens after the user has already trusted the package. The practical conclusion is that runtime inspection becomes part of identity governance for agent ecosystems.

From our research:

• 44 skills were tied to a confirmed malware campaign, ClawHavoc, with 12,559+ downloads, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• For a broader lifecycle lens on delegated access and containment, see NHI Lifecycle Management Guide and align skill onboarding, review, and offboarding to the same control discipline.

What this signals

Agent extension governance is now an identity problem with supply-chain characteristics: teams should expect future controls to focus less on whether an AI skill is useful and more on whether it can be proven, scoped, isolated, and revoked. That shift mirrors the move from trusting APIs to governing workload identities, and it should change how platform owners approve agent ecosystems.

With 70.1% of skills showing OAuth over-provisioning in the audit, broad grants are not an edge case, they are the operating model. For practitioners, that means permission review has to move upstream into marketplace intake and downstream into continuous monitoring for scope creep and unexpected network behaviour.

The strongest signal in this research is not that malware exists in AI skills, but that the marketplace structure lets malicious and merely careless code look operationally similar. Security teams should prepare for extension ecosystems to be measured against provenance, runtime containment, and token exposure controls, not just functional usefulness.

For practitioners

• Treat skills as executable software Require provenance checks, code review, and host isolation before any skill is installed in a production-connected environment.
• Enforce minimal OAuth scopes Refuse broad repository, cloud, or token permissions unless the skill cannot function without them, and revalidate scopes during every upgrade.
• Block unsafe shell execution patterns Detect and reject skills that decode payloads at runtime, construct dynamic shell commands, or fetch remote second-stage code.
• Monitor outbound traffic and secret access Alert on unusual network destinations, bulk environment variable reads, and attempts to access credentials from skill execution contexts.
• Isolate marketplace-installed extensions Run high-risk skills in sandboxes or non-sensitive environments until their behaviour has been validated against the intended task scope.

Key takeaways

• AI skill marketplaces can become malware channels when executable extensions inherit host-level privileges without meaningful review or sandboxing.
• The audit found confirmed malware, widespread OAuth over-provisioning, and command injection patterns, which together show a systemic governance problem rather than isolated bad code.
• Practitioners should treat AI skills as software supply-chain dependencies and enforce provenance, minimal scopes, and runtime isolation before deployment.

Key terms

• Agent Skill: A packaged extension that adds capabilities to an AI agent through instructions, configuration, or code. In practice, a skill can execute with the host environment's authority, which means it must be governed like software with explicit permissions, provenance, and runtime boundaries, not like a harmless prompt template.
• OAuth Over-Provisioning: Granting an integration more OAuth access than it needs to perform its task. For AI skills and machine identities, over-provisioning increases blast radius because a compromise can inherit broad repository, cloud, or token permissions that were never required for the intended workflow.
• Marketplace Trust Boundary: The point at which a user or organisation decides that code or capability from a marketplace is acceptable to run. For AI extensions, that boundary is weak if the platform does not verify provenance, constrain execution, and surface what data or credentials the skill can reach.
• Runtime Containment: Controls that limit what a running component can do after installation or approval. For autonomous or semi-autonomous extensions, runtime containment includes sandboxing, network restrictions, secret access limits, and monitoring that detects behaviour outside the approved task scope.

What's in the full article

Lakera's full research covers the operational detail this post intentionally leaves for the source:

• The full skill-by-skill audit breakdown across 4,310 published OpenClaw skills, including risk classification patterns.
• Examples of the observed payload execution flow, including Base64 decoding, shell piping, and second-stage delivery.
• Details on the ClawHavoc-linked typosquatting patterns and the named skills tied to confirmed malware delivery.
• The public dashboard methodology used to score and classify the 221 skills reviewed in depth.

👉 Lakera's full post covers the ClawHavoc-linked skills, execution patterns, and ecosystem-wide weaknesses.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.