OpenClaw Security: Risks, Issues, and How to Secure OpenClaw at Work
OpenClaw runs on your machine with your permissions and, in its own documentation, describes itself as not secure by default. Censys found more than 21,000 instances exposed to the open internet in a single week.
Direct answer
OpenClaw security is the problem of running a self-hosted autonomous agent that has your shell, your files, your browser, and your messaging accounts, on a machine that also holds company data. The OpenClaw documentation is unusually direct about it: the gateway on port 18789 has no authentication by default, the agent runs with your user permissions and "can read/write any file, execute any command," and the docs state plainly that OpenClaw is "not secure by default." Three things then happened in the wild. Censys identified 21,639 publicly exposed instances as of January 31, 2026. CVE-2026-25253, rated CVSS 8.8, let a crafted link hand a victim gateway token to an attacker in versions before 2026.1.29. And the ClawHub skill marketplace was flooded with malicious packages: Koi Security found 341 malicious skills in an audit of 2,857, most of them delivering an infostealer. For an individual, the fix is hardening. For a company, the honest answer is that OpenClaw on an employee laptop is an endpoint and identity problem first, and a runtime policy problem second. This page covers both, and says clearly which parts a gateway like ours does not solve.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
Nobody filed a ticket. An engineer read a thread, installed an agent that answers on WhatsApp, gave it an API key and a shell, and pointed it at the repo to save time on chores. It works, and it is useful, which is why it spreads. Six weeks later the security team is asked which systems it touched, under whose identity, and whether the skill it installed last month was one of the poisoned ones. There is no log that answers any of those questions.
How Agentshield handles it
Be honest about the split. The exposure risks in OpenClaw are host and network problems: do not expose port 18789, require gateway authentication, run it as a non-root user in a container, and keep it patched past 2026.1.29. No policy gateway substitutes for that. What a control point does add is everything that starts once the agent behaves normally. OpenClaw is model-agnostic and speaks MCP, so its model calls and tool calls can be routed through a layer that inspects untrusted content before the agent acts on it, checks each tool call against a scope attached to that agent rather than to whatever key it holds, holds destructive actions for a human, and writes an append-only record of what was requested and what was denied. For agents your own team builds, that layer is the whole control. For an unmanaged third-party agent, it is the part that gives you evidence and a boundary at the systems you do run.
The controls
The controls that secure the agents your company builds and runs, and gives you a record of what an unmanaged agent like OpenClaw touched.
What is OpenClaw, and why is it a security problem?
OpenClaw is a free, open-source, self-hosted AI agent that runs locally and connects a model of your choice, Claude, GPT, Gemini, Grok, DeepSeek or a local model, to the things on your machine. Its community documentation describes integrations with more than 50 messaging channels including WhatsApp, Telegram, Slack, Signal and iMessage, more than 32,600 MCP servers, browser automation, email, and shell access. The project was previously named Clawdbot and then Moltbot, and it rebranded again in early 2026, which is worth knowing because older advisories use the older names.
The security problem is not a bug. It is the design, stated openly. An agent that is useful for chores has to be able to read your files, run commands, and speak as you in the apps you already use. The OpenClaw docs put the consequence in one line: it runs with your user permissions and "can read/write any file, execute any command." The same documentation says the software is "not secure by default" and warns: "Do not run OpenClaw as root. Do not expose the gateway to the internet without authentication."
That is a fair warning and a lot of people did not read it. What turns a local agent into an incident is the combination of three ordinary decisions: the gateway listens on a port, the port ends up reachable, and the credentials it holds are the real ones. Add a marketplace of community-contributed skills that can run code, and you have a supply chain attached to a machine with shell access.
None of this is unique to OpenClaw. It is the general shape of agent risk arriving early and in public, which is exactly why it is worth studying. The same failure modes show up in agents your own team builds, where they are your responsibility rather than a maintainer's. That general case is covered on AI runtime security.
OpenClaw security risks: what actually happened in 2026
These are documented events with named sources and dates, not projections. Where researchers disagree on counts, both figures are shown, because the disagreement is itself informative about how hard this is to measure.
| Incident | What was found | Source and date |
|---|---|---|
| Mass gateway exposure | 21,639 OpenClaw instances publicly reachable on TCP/18789. Censys wrote that although OpenClaw "is designed to run locally on TCP/18789 or be accessed through protective mechanisms like SSH or Cloudflare Tunnel," it identified more than 21,000 exposed instances. The United States held the largest concentration, then China, then Singapore | Censys, as of January 31, 2026 |
| Token exfiltration, full gateway compromise | CVE-2026-25253, CVSS 8.8 High, CWE-669. Versions before 2026.1.29 take a gatewayUrl value from a query string and open a WebSocket connection to it without prompting, sending a token. A crafted link is enough. Fixed in 2026.1.29 | NVD and MITRE |
| ClawHavoc skill poisoning | An audit of 2,857 ClawHub skills found 341 malicious. 335 of them used fake prerequisites to install the Atomic Stealer (AMOS) infostealer on macOS, harvesting exchange API keys, wallet keys, SSH credentials and browser passwords | Koi Security, February 2026 |
| Marketplace totals | Antiy CERT counts at least 1,184 malicious skills historically published to ClawHub, with a single author ID responsible for 677 of them | Antiy Labs |
| Evasion of marketplace scanning | Unit 42 found five malicious skills still unblocked between February and May 2026. One padded a file with 22 MB of characters to exceed content-analysis limits and bypass both ClawScan and VirusTotal. Others injected affiliate redirects at runtime or coordinated agents into crypto front-running | Palo Alto Unit 42, June 23, 2026 |
The root cause of the marketplace problem is worth stating plainly, because it is the part most likely to repeat elsewhere. At the time of the ClawHavoc campaign, publishing a skill to ClawHub required a GitHub account at least one week old. There was no automated static analysis, no code review, and no signing requirement. That is the same trust gap that makes an MCP tool description worth treating as hostile input, which is covered on MCP server security.
Read together, the five rows split cleanly into two categories: three are deployment and patching failures, and two are supply chain failures. Neither category is solved by prompt filtering, and it is worth being suspicious of any vendor who tells you otherwise.
OpenClaw security issues by default setting
Most of what gets reported as an OpenClaw vulnerability is a default doing exactly what it says it does. This table maps each default to the exposure it creates and the change that closes it.
| Default | Why it exists | Exposure it creates | What to change |
|---|---|---|---|
| Gateway on port 18789 with no authentication | Local-only convenience during setup | Anyone who can reach the port controls the agent, its credentials and its tools | Set a gateway token or put reverse proxy auth in front. Bind to localhost. Reach it over SSH, a VPN or a private tunnel, never a public interface |
| Runs as your user | It needs your files and your tools to be useful | Full read and write on everything you can touch, including SSH keys, cloud credential files and browser profiles | Run as a dedicated non-root service account in a container, with only the directories it needs mounted, and credential files excluded |
| Execution approval configurable to auto | Approving every shell command is tedious | Set to auto, any instruction that reaches the model can become a command. Injected text counts as an instruction | Keep it on ask for anything that writes, sends, pays or deletes. Use deny plus a narrow allowlist for unattended runs |
| Credentials held in local config | The agent needs keys to call models and services | Reports of plaintext credential storage, and TLS disabled on some installs, meant a single host compromise yielded every key | Keep keys out of the agent process. Use short-lived credentials injected by a proxy, so a stolen config file is not a stolen key |
| Open skill marketplace | Community extensions are the reason it does so much | Installing a skill is running someone else's code with your permissions, and screening has demonstrably been bypassed | Allowlist specific skills, pin them by version and hash, review the code, and re-check after updates rather than only at install |
The pattern across every row is the same one that shows up in agents teams build themselves: the agent holds a durable, broadly scoped credential and decides for itself when to use it. Narrowing that is the subject of AI agent access control, and giving each agent its own identity rather than a shared key is covered on AI agent identity.
How to secure OpenClaw: a hardening checklist
In rough order of how much risk each step removes per unit of effort. The first four are not optional if the machine touches anything that matters.
- Update past 2026.1.29. That release fixes CVE-2026-25253, the query-string gateway URL flaw that turns a single crafted link into full gateway compromise. Check your version before anything else.
- Take the gateway off the internet. Bind to localhost, and reach it through SSH, a VPN or a private tunnel. If it must listen, require a gateway token and put authentication in front. The 21,639 exposed instances Censys found were, overwhelmingly, this one mistake.
- Stop running it as your login user, and never as root. Put it in a container as a dedicated non-root account. Mount only the directories the agent genuinely needs. Explicitly exclude SSH keys, cloud credential directories and browser profiles, which are the exact targets the AMOS infostealer skills went after.
- Get the keys out of the process. An agent that holds a long-lived API key loses that key whenever the host is compromised. Front the credentials with a proxy that injects short-lived tokens, so the blast radius is a session rather than an account.
- Treat skills as third-party code, because that is what they are. Allowlist the specific skills you need, pin versions, read what they do, and re-verify after updates. Unit 42 documented skills that passed screening and skills that changed behavior after install, so approval at install time is not approval forever.
- Keep execution approval on ask for anything irreversible. Auto-approve is where a prompt injection stops being a curiosity. If a run has to be unattended, use deny with a narrow allowlist rather than auto. The reasoning is on human in the loop AI agents.
- Assume anything the agent reads is hostile. A WhatsApp message, a web page it browses, an email, a calendar invite, or a tool description from an MCP server are all instruction channels. That is the definition of indirect prompt injection, and it is covered on prompt injection detection.
- Log what it did somewhere the agent cannot edit. Local logs on a compromised host are not evidence. An append-only record held outside the machine is the difference between an incident you can scope and one you can only guess at. See agent audit trail.
Steps one through five are host and supply chain hygiene, and you do them whether or not you buy anything. Steps six through eight are runtime policy, and they are the same steps you would apply to an agent your own team wrote.
OpenClaw at work: the unmanaged agent problem
The corporate version of this is not really about OpenClaw. It is about an employee installing a capable autonomous agent on a machine that has a session cookie for your CRM, a checked-out repository, and a mail client that is already logged in. The agent is not malicious and neither is the employee. The problem is that the agent acts with a human's credentials and leaves a record that looks like that human working.
Three questions decide how much this matters to you, and they are worth answering before writing a policy:
- Whose machine is it? On a managed corporate device you have real options: device management, application allowlisting, endpoint detection, and network egress control. On a personal laptop that syncs company data, you have almost none, and the honest control is the data boundary rather than the agent.
- What identity does it use? If the agent authenticates as the employee, everything it does inherits their access and their audit trail. Giving non-human actors their own identity is the structural fix, and it is why non-human identity became a category.
- Can you tell it apart from a person? 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 related CSA study of 445 respondents found 82 percent have unknown AI agents in their environments.
A blanket ban is the common first reaction, and it mostly produces the same agent running on an unmanaged device where you can see even less. The more durable approach is to name a sanctioned path for the work people are trying to do, restrict the unmanaged one at the systems you control, and make sure the sanctioned path is actually pleasant to use. The discovery half of the problem is covered on AI agent monitoring.
What a runtime control point does and does not fix
We sell a gateway, so this table is the one to read skeptically. It is written to be accurate rather than flattering, and the right-hand column is the point of it.
| OpenClaw risk | Does a policy gateway help? | What actually fixes it |
|---|---|---|
| Gateway port exposed to the internet | No | Network configuration. Bind to localhost, require auth, use SSH or a private tunnel. Nothing at the policy layer substitutes for this |
| CVE-2026-25253 token exfiltration | No | Patch to 2026.1.29 or later. Vulnerability management, not runtime policy |
| Malicious skill installing an infostealer | Partly. Outbound tool and network calls to attacker infrastructure can be blocked and logged | Skill allowlisting, version and hash pinning, code review, plus endpoint detection on the host. The malware runs on the machine, not through us |
| Agent runs as your user with full file access | Partly. Tool calls that route through the control point are scoped and logged | Containerization and least-privilege OS accounts. A local shell command never reaches a network gateway. See AI agent sandboxing |
| Prompt injection through a message, page or tool result | Yes. This is the case we are built for: inspect untrusted content before the agent acts on it | Content inspection at the point of action, plus approval gates on irreversible tools |
| No record of what the agent touched | Yes. An append-only record of requested and denied calls, held off the host | An audit trail the agent cannot edit, which is the only artifact that survives host compromise |
Two rows are a clear no, two are partial, two are yes. If you are evaluating anyone in this market, that ratio is a useful thing to ask for. The vendors worth your time will tell you where they stop. A broader comparison of who does what is in our writeup of AI agent security companies.
The larger point is that OpenClaw made an ordinary problem visible early. The agents your own teams are shipping this quarter have the same shape: broad credentials, untrusted input, autonomous tool calls, and no independent record. The difference is that those are yours to control, and control is easier to add before the agent is load-bearing. If you are building on a framework rather than installing one, start with Claude agent security, OpenAI agent security, or LangChain security.
FAQ
Common questions about openclaw security.
Is OpenClaw safe?
Not by default, and its own documentation says so. OpenClaw runs with your user permissions, can read or write any file and execute any command, and ships a gateway on port 18789 with no authentication. It can be made reasonably safe on a dedicated, containerized, patched, non-exposed host. On a laptop holding company credentials, it is a meaningful risk.
Is OpenClaw a security risk?
Yes, in the specific sense that it concentrates high-value access in one process. It holds model API keys, messaging account sessions, shell access and file access at once. Censys found 21,639 instances publicly exposed as of January 31, 2026, which shows how often the local-only assumption fails in practice.
What are the security issues with OpenClaw?
Four categories. Gateway exposure, where port 18789 is reachable without authentication. Patchable vulnerabilities, notably CVE-2026-25253 at CVSS 8.8. Supply chain risk from ClawHub skills, where Koi Security found 341 malicious skills in an audit of 2,857. And the design itself, since the agent runs with your permissions and treats incoming content as instructions.
How do I secure OpenClaw?
Update past 2026.1.29 first, then take the gateway off any public interface and require a token. Run it in a container as a non-root account with only the directories it needs, excluding SSH keys and credential files. Allowlist and pin skills, keep execution approval on ask for irreversible actions, and log its activity somewhere it cannot edit.
How do I secure the OpenClaw gateway?
Bind it to localhost rather than a public interface, and set a gateway token or put reverse proxy authentication in front. Reach it through SSH, a VPN or a private tunnel. The documentation is explicit: do not expose the gateway to the internet without authentication. Also confirm TLS is enabled so the token is not sent in the clear.
Are OpenClaw skills safe to install?
Treat every skill as third-party code running with your permissions. At the time of the ClawHavoc campaign, publishing to ClawHub required only a GitHub account a week old, with no static analysis, code review or signing. Unit 42 later found skills that evaded scanning and skills that changed behavior after installation, so vetting once is not enough.
Is OpenClaw secure now?
The specific flaws are fixed and screening improved, but the design has not changed, and it is not meant to. An agent with shell, file, browser and messaging access is inherently high-value. Judge your own deployment on four things: version, gateway exposure, the account it runs as, and which skills are installed.
Should we allow OpenClaw at work?
Decide by machine, not by opinion. On managed devices you can permit a hardened, containerized install with device management, egress control and endpoint detection behind it. On unmanaged personal devices holding company data, restrict the data rather than the tool, because you cannot enforce anything on the host. Blanket bans mostly move it somewhere you cannot see.
What is CVE-2026-25253?
A high-severity OpenClaw vulnerability, CVSS 8.8, in versions before 2026.1.29. The client takes a gatewayUrl value from a query string and automatically opens a WebSocket connection to it without prompting, sending a token. A victim following a crafted link hands over their gateway token, which means full gateway compromise. Updating fixes it.
Does Agentshield secure OpenClaw?
Partly, and the honest split matters. We do not fix an exposed port, an unpatched version, or malware running on the host, and no policy layer does. We do inspect untrusted content before an agent acts on it, scope and log tool calls that route through the control point, and hold irreversible actions for a human. For agents your own team builds, that is the full control layer.
More use cases