The security community has described OpenClaw as “an absolute nightmare” from a risk perspective. That assessment is accurate, and understanding why requires understanding what OpenClaw actually is and how it operates — because it is not a chatbot. It is something with fundamentally different security implications.
What OpenClaw Actually Is
OpenClaw markets itself as “the AI that actually does things.” That description is technically precise and should raise immediate flags for any security practitioner. Where traditional AI tools answer questions and generate content, OpenClaw functions as a delegated operator — a long-running AI agent that receives goals, maintains context across sessions, and takes real actions in the background without requiring a human to initiate each step.
It clears inboxes, sends emails, manages calendars, books travel, and handles tasks autonomously. Users interact with it through WhatsApp, Telegram, Slack, or any chat application they already use. Setup takes approximately five minutes. No code is required. There are 177 production-ready agent templates available on day one. And unlike most AI platforms, OpenClaw runs locally — self-hosted on the user’s machine — which means it is not going through your cloud security controls or your DLP tools.
The architecture is built around a set of plain-text configuration files written in Markdown. SOUL.md defines the agent’s personality and decision-making values. TOOLS.md describes its available capabilities. SKILLS.md is its operational playbook. MEMORY.md is its persistent long-term storage. HEARTBEAT.md governs what it checks on a recurring basis. AGENTS.md controls how it orchestrates with other agents. This modular design is elegant from a developer perspective. From a security perspective, it means markdown files are now executable code — and markdown files are not subject to the same scrutiny your organization applies to actual software deployments.
The Documented Vulnerabilities
OpenClaw has accumulated a significant CVE record in a very short period. Four high-severity vulnerabilities have been publicly disclosed, along with a separate advisory describing full agent takeover through WebSocket hijacking.
CVE-2026-25253 (CVSS 8.8) is an authentication token theft vulnerability. Exploitation leads to credential theft that enables downstream access to whatever accounts and services the agent is connected to. CVE-2026-26322 (CVSS 7.6) is a server-side request forgery vulnerability in the gateway component — the same class of vulnerability that has caused significant damage in traditional web application contexts, now operating within an autonomous agent that has direct access to internal services. CVE-2026-26329 (CVSS 7.1) is a path traversal vulnerability enabling arbitrary file access. CVE-2026-24763 (CVSS 8.8) is a command injection flaw that enables remote code execution. And a separate advisory named ClawJacked describes a WebSocket hijacking technique that results in full agent takeover — meaning an attacker gains control of the agent itself and can direct it to take actions on the user’s behalf.
None of these are theoretical. They have been publicly documented, with step-by-step exploitation guides already available. One published guide describes zero-click remote code execution through a malicious link — meaning a user does not have to do anything other than receive a message for exploitation to occur.
Real-World Incidents That Have Already Occurred
Beyond the CVE record, three supply chain and operational security incidents have already been publicly reported.
ClawHub Malware: 820+ Malicious Skills
ClawHub is the skill marketplace for OpenClaw — the ecosystem where users download agent capabilities, similar to a plugin store. Security researchers found that 1 out of every 3 skills in ClawHub has at least one security flaw, including hardcoded API keys, insecure credential handling, and dangerous third-party content exposure. 1 out of every 8 skills has a critical security issue, including malware distribution, prompt injection attacks, and exposed secrets. In absolute numbers, 820 or more malicious skills have been identified, including infostealers. Users installing skills from ClawHub — which the default OpenClaw experience encourages — are frequently installing software that has not been reviewed, vetted, or secured.
6,000-Email Deletion via Prompt Injection
A prompt injection attack caused an OpenClaw agent to delete 6,000 emails from a user’s inbox. Prompt injection is the AI equivalent of a SQL injection attack: malicious instructions are embedded in content that the agent processes — a web page, an email, a document — and the agent executes those instructions as if they came from its legitimate operator. Because OpenClaw is designed to take real actions with minimal friction, prompt injection is not just a data exposure risk. It is a data destruction risk. The agent did what it was told. What it was told was not from its user.
The Cline Compromise: Silent Installation via Trusted Tooling
The AI coding assistant Cline was compromised and used to silently install OpenClaw on developer machines. This is a supply chain attack that illustrates how OpenClaw exposure can arrive through a trusted tool rather than direct user action. A developer who has never heard of OpenClaw and would never knowingly install it can end up running it because a tool they trust was used as a delivery mechanism. This has direct implications for how organizations think about their software supply chain governance — particularly for development environments where AI coding assistants are increasingly standard.
Why OpenClaw’s Default Configuration Is the Problem
A useful security framework for evaluating autonomous AI agents asks: does the agent do any combination of three things — process untrustworthy inputs, access sensitive systems or private data, or change state and communicate externally? The combination of all three in a single system represents the highest risk tier. OpenClaw, in its default configuration, does all three simultaneously.
It processes untrustworthy inputs because it reads emails, web content, documents, and messages — all of which can contain prompt injection payloads. It accesses sensitive systems and private data because connecting it to email, calendar, cloud storage, and productivity tools is the entire value proposition. And it changes state and communicates externally because sending emails, booking travel, and submitting requests on the user’s behalf is exactly what it is designed to do. Any one of these capabilities in isolation represents manageable risk. All three combined, in an agent that operates continuously in the background with delegated authority over the user’s accounts, represents a fundamentally different threat profile than anything most enterprise security programs have governed before.
The default configuration compounds this. The OpenClaw gateway runs exposed on 0.0.0.0:18789 without authentication by default. The DM policy allows all users by default. The sandbox is disabled by default. Credentials are stored in plaintext in oauth.json by default. Audit logging is not enabled by default. The pairing codes are weak by default. OpenClaw was built for ease of deployment. Security was not the design priority, and the defaults reflect that.
The Multi-Agent Risk Multiplier
OpenClaw supports agent-to-agent communication, which is one of the capabilities that differentiates it from simpler AI tools. A single OpenClaw agent can orchestrate other agents — spawning them, directing them, and delegating tasks across an agent network. Each additional agent added to that network introduces additional risk, because each one is a new point where prompt injection can occur, where credentials can be exposed, and where unauthorized actions can be taken.
What makes this particularly difficult to govern is non-determinism. Unlike traditional software that executes a defined sequence of operations, AI agents reason about what to do next based on context. That reasoning is not predictable in the way a workflow or script is predictable. An orchestrating agent might call a sub-agent in a sequence that was never anticipated by the user who configured the system. The risk is not static — it compounds with every additional agent added to the network, and it is not visible through traditional software monitoring.
What Enterprise Governance Needs to Look Like
The right posture is not a blanket ban. OpenClaw is growing too fast, and the ecosystem around it — variants, competitors, enterprise-grade versions — is accelerating. A prohibition-only approach will fail the same way Shadow IT prohibitions have always failed: users will find a way, and you will lose visibility. What is needed is a risk-based governance framework that establishes ownership, bounds the agent’s powers, builds in human checkpoints, and creates evidence trails.
Start with Discovery
Before you can govern OpenClaw, you need to know where it is. Tools like OpenClaw Detect (available at github.com/knostic/openclaw-detect) provide lightweight scripts designed for MDM deployment that check for CLI binaries, application bundles, configuration files, gateway services, and Docker artifacts. This is where governance starts — not with policy, but with visibility. You cannot write a policy for something you cannot find.
Select Low-Blast-Radius Use Cases First
If your organization decides to allow OpenClaw in any capacity, start with use cases where the consequences of agent error are limited. Tasks that do not involve sending communications, modifying data, or accessing sensitive systems. This principle — start with the smallest access that still works, then widen it as you gain confidence — applies directly to how agent capabilities should be scoped. Every tool permission granted to an agent should be deliberate. Every data class the agent can touch should be explicitly approved. Every channel through which the agent can communicate should be defined in advance.
Require Human Checkpoints for High-Stakes Actions
Autonomous action is the value proposition of OpenClaw, but it is also where the risk concentrates. Actions that send communications externally, modify or delete data, or involve financial transactions should require explicit human approval before execution. This requires configuration — it will not happen by default — but it is the most direct control available to limit the blast radius of agent compromise or prompt injection.
Instrument for Monitoring
OpenClaw Telemetry (github.com/knostic/openclaw-telemetry) captures every tool call, LLM request, and agent session with tamper-proof hash chains and SIEM forwarding capability. This telemetry is not optional governance infrastructure — it is the only way to have meaningful visibility into what agents are doing in your environment. Without it, agent activity is a blind spot. With it, you can build detection logic, review anomalies, and have an evidence record that supports incident response if something goes wrong.
Deploy Runtime Protection
OpenClaw Shield (github.com/knostic/openclaw-shield) provides runtime guardrails that prevent agents from leaking secrets, exposing PII, or executing destructive commands. This is a compensating control that operates at the agent layer, blocking actions that violate defined policies before they can execute. It does not replace governance, but it provides a meaningful safety net particularly during the period when agent deployment is outpacing your ability to fully review and approve every configuration.
The Trajectory Problem
OpenClaw is a signal, not just a product. It represents the leading edge of a broader shift in how AI is being deployed — from chatbots that answer questions to persistent operators that run continuously in the background, maintaining memory, executing on goals, and coordinating across agent networks. The security challenges OpenClaw presents today will not diminish as the technology matures. They will become more complex as agent capabilities expand, as agent-to-agent communication becomes standard, and as the number of agents per user and per enterprise multiplies.
The organizations that are working through OpenClaw governance now — building the discovery tools, the telemetry infrastructure, the runtime protection, and the governance frameworks — are building institutional capability that will transfer to whatever comes next. The ones treating it as a one-off Shadow AI problem to be managed through a policy memo are going to find themselves starting from scratch, repeatedly, as the threat surface evolves faster than the policy cycle can keep up.
Agentic AI is not just more automation. It is automation with delegated authority, persistent memory, and the ability to act without a human in the loop. That combination requires security governance that does not yet exist in most organizations. OpenClaw is the pressure test arriving before the governance framework is ready.