OpenClaw Security Risks: Prompt Injection, Malicious Skills and Enterprise Admin Controls

This is an opinion piece, not an incident report. Perry doesn't document a specific breach, and the "meteoric rise" and "no-click attacks" in his framing are his claims rather than measured findings. The underlying risk model holds up well, though. OpenClaw's own documentation, Palo Alto Networks' Unit 42 and Microsoft's Defender team all back it.

Why one assistant becomes a privileged control point​

Perry's central point is aggregation. Organizations have historically secured email, finance tools, chat and endpoints separately. One assistant that can touch all of them collapses those boundaries. If an attacker can steer it, the damage reaches well beyond the assistant.

The assistant's behavior is also driven by natural-language instructions and context, not a fixed workflow. That is why Perry lists prompt injection, malicious skills and no-click attacks as the key threats. His conclusion is that the consequences land on the organization, not the assistant. If an agent sends a damaging email or exposes credentials, the business bears the legal, financial and operational cost.

Microsoft's Defender Security Research Team reached a similar position in February 2026. It said the key security point is that the agent inherits the trust, and the risk, of the machine and the identities it can use. The team's blunt verdict was that OpenClaw is not appropriate to run on a standard personal or enterprise workstation. Microsoft Defender recommends using it only in isolated environments with no access to non-dedicated credentials or data that must not leak.

Prompt injection: the content is the attack surface​

Perry's point is that an attacker can hide instructions in an email, webpage or document the assistant reads. OpenClaw's documentation says the same thing. It says prompt injection doesn't require public direct messages: even if only you can message the bot, any untrusted content it reads can carry adversarial instructions. That covers web search and fetch results, browser pages, emails, documents, attachments, and pasted logs or code. The content is a threat surface, not just the sender.

The documentation describes mitigations, not guarantees. It recommends several controls:

• Keep inbound direct messages locked down with pairing or allowlists.
• Limit group context with mention gating and contextVisibility.
• Restrict high-risk tools (exec, browser, web_fetch, web_search) to trusted agents or explicit allowlists.
• Run sensitive tool execution in a sandbox, and keep secrets out of the filesystem the agent can reach.
• If you allowlist interpreters such as python or node, enable tools.exec.strictInlineEval, so inline eval forms still need explicit approval.

Sandboxing is opt-in, which is the detail admins are most likely to miss. With sandbox mode off, the implicit host=auto setting resolves to the Gateway host. Selecting host=sandbox explicitly doesn't create a sandbox if no runtime is available.

The documentation also suggests a "reader" agent: a read-only or tool-disabled agent that summarizes untrusted content before a more privileged agent sees it. It is candid about the limit. The summary remains untrusted, and a privileged recipient can still act on an injected request. Likewise, Gmail's per-message session isolation separates conversation context but doesn't strip the target agent's tool or workspace permissions. Session separation and agent handoffs are not containment on their own.

The documentation also says model choice matters, but only as a first layer. Hard enforcement through tool policy, exec approvals, sandboxing and channel allowlists is meant for anything whose potential damage you wouldn't accept.

Skills: an AI-flavored supply chain​

Perry calls malicious skills a supply chain risk where harmful logic may be expressed as instructions rather than conventional code. Unit 42's June 2026 research gives that concern some evidence.

Unit 42 analyzed ClawHub, OpenClaw's skill marketplace, between February and May 2026 and found five malicious skills that screening hadn't blocked. It reported all five. OpenClaw banned the accounts and deleted the skills. The five fell into three groups:

• Infostealers: two skills delivered macOS infostealers.
• Evasion: one skill used an inflated file size to get past scanner thresholds.
• Agentic financial schemes: two skills used what Unit 42 calls runtime agentic affiliate injection and agentic front-running.

That research followed earlier campaigns. Unit 42 notes that early findings in February 2026 led ClawHub to integrate VirusTotal and ClawScan, and that a partnership with NVIDIA was announced on June 1. Unit 42 says each of the five skills passed the detection tools of the time. The lesson is that marketplace screening reduces risk without eliminating it.

Unit 42 also explains why this differs from npm or PyPI. A skill can use natural-language instructions to exploit the agent's operational context, including files, shells and credential managers, without a conventional exploit. The distinction matters: Unit 42 found malicious skills, which doesn't mean every skill is malicious or that these five compromised users. Early campaign figures cited in the research came from other firms (Bitdefender, Koi Security, Trend Micro) and are worth attributing as such.

OpenClaw's own permissions documentation treats extensions as high-trust. Plugins run in-process with the Gateway and should be treated as trusted code. It recommends:

• Installing only from trusted sources.
• Using explicit plugins.allow allowlists.
• Pinning exact versions and inspecting unpacked code before enabling.
• Using security.installPolicy, which lets operators run a local command that returns allow, warn or block for skill and plugin installs, including ClawHub skills.

The same documentation says OpenClaw doesn't run built-in local dangerous-code blocking during install or update. Operators have to supply that policy themselves, with openclaw security audit --deep for diagnostic scanning.

Permissions are configuration, not a constant​

Perry's examples of funds transfers, deleted data and changed production systems are possible outcomes. They are not defaults. The documentation shows how much depends on deployment choices.

Take paired macOS nodes. If a Mac node is paired, the Gateway can invoke system.run on it, which is remote code execution on that Mac. Pairing establishes identity and trust. It is not per-command approval. To disable it, set the security policy to deny and remove the pairing.

Cross-provider messaging works the same way. Agents with message-tool access can send across conversations and channel providers by default. The tools.message.crossContext.allowAcrossProviders setting defaults to true, so it has to be switched off deliberately if you want that boundary.

For any agent handling untrusted content, the documentation suggests denying the gateway, cron, sessions_spawn and sessions_send tools by default. It also describes per-agent profiles: full access, read-only, or no filesystem and shell access. Auditing a deployment means checking which profile each agent actually runs under, not what the product can theoretically do.

What admins should do​

Perry's playbook is sensible, and the documentation supplies specifics to go with it.

1. Find it. Use endpoint telemetry, process monitoring, network logs and identity data to see who has installed or used OpenClaw. Perry cautions that detection rules based on ports and domains are a starting point, since configurations change. One security-industry report, from Bitdefender and cited by CyberDesserts, says employees are installing it on corporate devices with single-line commands and no SOC visibility.
2. Block until reviewed. In higher-risk environments, blocking unapproved AI tools and known OpenClaw domains or repositories may be justified until policy and monitoring exist.
3. Enforce least privilege. Don't grant email, file, finance or system access just because an integration exists. Require extra approval for external messages, funds transfers, deletions and production changes.
4. Isolate the runtime. Following Microsoft's guidance, use dedicated virtual machines or separate systems with dedicated, scoped credentials, not a daily-driver workstation.
5. Harden the Gateway. OpenClaw's repository guidance says to keep the Gateway web interface bound to loopback, not 0.0.0.0 or a public reverse proxy. For remote access it points to an SSH tunnel or Tailscale. It also recommends openclaw security audit --deep, and for containers a non-root user, a read-only filesystem where practical and --cap-drop=ALL.
6. Train people. Employees should know which AI tools are approved, what is prohibited, and whom to ask.

The bottom line​

Perry's headline, that agents create a new privileged access problem, is better supported than his supporting rhetoric. The evidence doesn't show an incident affecting all users. It does show a tool whose own documentation treats untrusted content, plugins and paired nodes as serious trust boundaries. It also shows a marketplace where malicious skills slipped through screening, and Microsoft telling enterprises to keep it off standard workstations.

For Windows and enterprise admins, the practical question is not whether OpenClaw is safe in the abstract. Ask which identities it holds, which tools it can call, and whether anyone reviewed the configuration before it went live. An assistant with a full set of credentials and no approval gates is, in effect, an unmanaged service account that takes instructions from whatever it reads.