Is OpenClaw Safe? Security Risks, ClawHub Skills, and Whether to Allow It at Work

OpenClaw is not safe by default, and the project says so in its own documentation. It runs with your user permissions, it can read or write any file and execute any command, and its gateway listens on port 18789 with no authentication until you configure some. On a dedicated, patched, containerized host that is off the public internet, it can be run responsibly. On a laptop that holds your company's source code, a logged-in mail client and a live CRM session, it is a real risk, and the incidents of early 2026 are the evidence.

That is the short answer. The longer one is more useful, because "ban it" is the reaction most security teams have first and it tends to produce the worst outcome: the same agent, running on a personal device, where you can see nothing at all.

What OpenClaw actually is

OpenClaw is a free, open-source, self-hosted AI agent that runs on your own machine. It connects a model you choose, Claude, GPT, Gemini, Grok, DeepSeek or something local, to your files, your shell, a browser, your email and the messaging apps you already use. Its community documentation lists more than 50 messaging channels including WhatsApp, Telegram, Slack and Signal, plus access to a very large ecosystem of MCP servers and a marketplace of community-written skills. It was called Clawdbot, then Moltbot, before the current name, which matters when you are reading older advisories.

The reason it spread so fast is that it is genuinely useful. It also means that in one process you have concentrated model API keys, messaging account sessions, shell access and file access. That concentration is the whole security story.

Is OpenClaw a security risk? What the 2026 incidents showed

Three things happened, and they belong in different buckets, which is the part most write-ups blur.

Mass exposure. Censys identified 21,639 publicly reachable OpenClaw instances as of January 31, 2026, noting that the software "is designed to run locally on TCP/18789 or be accessed through protective mechanisms like SSH or Cloudflare Tunnel." The United States held the largest concentration. This is a deployment failure, not a code failure: people put a local-only service on a public interface.

A patchable vulnerability. CVE-2026-25253, rated CVSS 8.8, affected versions before 2026.1.29. The client took a gatewayUrl value from a query string and automatically opened a WebSocket connection to it without prompting, sending a token. Following a crafted link was enough to hand an attacker your gateway token. It is fixed, and the fix is an update.

A poisoned marketplace. This is the interesting one. Koi Security audited 2,857 ClawHub skills and found 341 malicious, 335 of which used fake prerequisites to install the Atomic Stealer infostealer on macOS, harvesting SSH credentials, browser passwords and wallet keys. Antiy CERT counts at least 1,184 malicious skills published historically, with one author account responsible for 677. Palo Alto's Unit 42 later found five that were still unblocked between February and May 2026, including one padded with 22 MB of junk characters specifically to exceed content-scanning limits and slip past both ClawScan and VirusTotal.

The root cause of the marketplace problem is the part worth remembering, because it will repeat elsewhere. At the time of that campaign, publishing a skill required a GitHub account at least one week old. No static analysis, no code review, no signing. Installing a skill was running a stranger's code with your permissions, and the screening between you and that stranger was a date check.

Does OpenClaw have security issues, or is this just how agents work?

Mostly the latter, and that is the uncomfortable part. Strip away the specific CVE and the specific marketplace, and what remains is the shape of every autonomous agent: broad standing credentials, untrusted input arriving through content the agent reads, tool calls decided by a model, and no independent record of what happened. An agent your own team is shipping this quarter has the same properties. It just has not been scanned by Censys.

The mechanism that makes it dangerous is indirect prompt injection. A WhatsApp message, a web page the agent browses, an email, a calendar invite, a tool description served by someone else's MCP server: all of these are text that reaches the model, and any of them can carry an instruction. If execution approval is set to auto, that instruction becomes a shell command. This is not a hypothetical class of bug, it is the default failure mode of the design.

How to secure OpenClaw if you are going to run it

In order of risk removed per unit of effort:

1. Update past 2026.1.29. Check the version before you do anything else.
2. Take the gateway off the internet. Bind to localhost, require a gateway token, and reach it over SSH, a VPN or a private tunnel. This single step is what those 21,639 exposed instances got wrong.
3. Do not run it as your login user, and never as root. Containerize it under a dedicated non-root account, mount only what it needs, and explicitly exclude SSH keys, cloud credential directories and browser profiles. Those are exactly what the infostealer skills went looking for.
4. Keep long-lived keys out of the process. Inject short-lived credentials through a proxy so a compromised host costs you a session, not an account.
5. Allowlist and pin skills. Review what they do, pin versions, and re-check after updates. Unit 42 documented skills that changed behavior after installation, so approval at install time is not approval forever.
6. Keep execution approval on ask for anything irreversible. Auto-approve is where injected text turns into action.

Steps one through four are host hygiene and cost nothing but attention. If they feel like too much work for the value you are getting, that is a real signal. A lot of what people run OpenClaw for is narrow and repetitive, like collecting information off a set of websites every morning, and for that specific job a dedicated web scraper you describe in plain English gets the data without putting a shell agent on a machine that holds your credentials. Matching the tool to the job is a security control in its own right.

Should you allow OpenClaw at work?

Decide by machine, not by policy statement.

On managed corporate devices, you have real leverage: device management, application allowlisting, endpoint detection and network egress control. Here a permit-with-conditions policy is defensible. Require a current version, a containerized non-root install, no exposed gateway, and an approved skill list. Then verify it rather than trusting the attestation.

On unmanaged personal devices that hold company data, you have almost no leverage over the host, so control the data instead. Tighten what those devices can reach, shorten session lifetimes, and require your sensitive systems to be accessed from managed endpoints. Writing a rule you cannot enforce just moves the activity out of view.

The question underneath both cases is whether you could even tell. In research the Cloud Security Alliance ran with Aembit in January 2026, covering 228 IT and security professionals, 68 percent said they cannot distinguish AI agent activity from human activity in their logs. A separate CSA study of 445 respondents found 82 percent have unknown AI agents in their environments already. An agent authenticating as an employee inherits that employee's access and their audit trail, which is why giving non-human actors their own identity keeps coming up as the structural fix.

The honest limits of any security product here

We sell a runtime control layer for AI agents, so it is worth being precise about what that does not do. It does not close an exposed port. It does not patch an unpatched version. It does not stop malware that a poisoned skill already executed on the host, because that code runs locally and never passes through a network policy layer. Anyone telling you otherwise is selling you a story.

What a control point does cover is the part that starts once the agent is behaving normally: inspecting untrusted content before the agent acts on it, checking each tool call against a scope attached to that agent rather than to whatever credential it happens to hold, holding irreversible actions for a human even in unattended runs, and writing an append-only record off the host that a compromised machine cannot edit. For an unmanaged third-party agent, that gives you a boundary at your systems and evidence afterward. For agents your own team builds, it is the whole control layer.

OpenClaw's real contribution to this field may be that it made an ordinary problem visible early and in public. The full breakdown of the risks, the defaults behind them, and the hardening steps is on our OpenClaw security page, and the general version of the problem is covered on AI runtime security.