Running OpenClaw safely: a practical hardening guide

Last updated: 8 June 2026

OpenClaw is the most capable personal agent you can self-host, and probably the most powerful thing you have ever installed on a server. Power is the point. This guide is about keeping it pointed in the right direction: the real risks of a self-hosted agent, and the specific hardening steps that actually reduce them.

The short version: an OpenClaw install can run shell commands, read and write files, drive a browser and act unattended, so a default single-machine setup carries real, already-documented risk. The controls that matter most are to give it a dedicated machine, restrict who can message it, allowlist commands on a deny-by-default basis, keep secrets in a vault, close all public network access, vet every community skill, and keep it patched. Treat it like a new employee with a company credit card, not a toy.

What OpenClaw can actually do

If you are reading this, you probably know the pitch: OpenClaw is a free, open-source AI agent that runs on your own machine and talks to you through WhatsApp, Telegram, Slack or whichever messaging app you already use. You send it a message; it acts. Within months of its first release it became the most-starred software project on GitHub, overtaking long-established projects such as React, and by mid-2026 it had passed 380,000 stars [1]. The idea is genuinely good, and the adoption is real.

What makes it useful is exactly what should make you pause. Its own documentation describes an agent that can, out of the box [2]:

• Execute shell commands on the machine it lives on, through built-in command-execution tools (bash and exec).
• Read and write files, including its own memory, which is stored as plain files on disk.
• Drive a browser, with everything that implies about logins and active sessions.
• Send and read messages and email on your behalf, across more than twenty messaging platforms and through Gmail integration.
• Wake itself on a schedule through a built-in cron tool and act without being prompted.
• Install community skills from the public ClawHub registry that extend all of the above.

Read that list again, but imagine it describing a new employee. You would not give that employee unrestricted production access on day one, on their personal laptop, with no supervision. That is what a default single-machine install amounts to.

The risk model, honestly

This is not hypothetical caution. Security researchers have already catalogued the ways careless OpenClaw installations go wrong, and several have real CVE numbers attached. In early 2026 a one-click remote-code-execution flaw was disclosed (CVE-2026-25253, rated 8.8 of 10): an OpenClaw instance before the patched release would read a gateway address from a URL parameter and connect to it automatically, without asking [3]. Researchers at Endor Labs then reported six further vulnerabilities, including server-side request forgery, missing authentication and path traversal [4], and an academic security analysis followed, mapping the agent's exposure to prompt injection, malicious skills and memory poisoning [5]. The patterns are not exotic. They are the same classes of failure we find when auditing AI-built software, applied to an agent that can act.

Prompt injection is the front door

The agent reads messages, emails and web pages, and treats their content as input. The trouble is that a language model cannot reliably tell the difference between the instructions you gave it and instructions hidden in the data it is reading. The UK's National Cyber Security Centre puts it plainly: prompt injection is not like SQL injection, and in some ways it is worse, because there is no clean separation between code and data to defend [6]. OWASP ranks prompt injection as the number-one risk to LLM applications, and explicitly calls out indirect prompt injection, where the malicious instruction arrives inside an external source such as a website or a file the model later reads [7].

If that sounds abstract, it has already happened to a major product. In the "EchoLeak" case, a single crafted email could silently steer Microsoft 365 Copilot into leaking internal data, with no click required from the victim (CVE-2025-32711) [8]. An agent that reads your messages and acts on them has the same exposure, by design. This is why who can talk to it is the single most important control you have.

The blast radius is the machine

OWASP calls the underlying problem excessive agency: an agent granted more capability, permission or autonomy than the task in front of it actually requires [9]. If the agent shares a machine with your other work, then everything on that machine, including SSH keys, browser sessions, documents and source code, is within reach of a bad day. The failure does not require the model to turn malicious. It can be as mundane as a poorly written community skill or one of the access-control flaws above.

The skills supply chain

Community skills are part of why OpenClaw is useful, and part of why it is dangerous. A skill is code that runs with the agent's permissions, installed from a public registry. That is a software supply chain, with all the risk the phrase implies: the academic analysis specifically flags malicious or contaminated skills as a route to compromise [5]. A skill you have not read is code you have not reviewed running against your data.

Keys and memory are assets

Your installation holds API keys that spend your money, and accumulates a memory of your life or business in plain files. Both deserve the treatment you would give credentials and backups in any production system, because that is what they are. Hardcoding secrets in config files is exactly the practice OWASP's secrets-management guidance warns against [10].

It moves fast

OpenClaw ships updates at open-source speed, and the security picture changes with it. Each of the CVEs above was fixed in a specific release, which does nothing for an installation nobody has updated. An agent that was sensibly configured in January and untouched since is not sensibly configured now.

The hardening checklist

In the order that matters. The first three eliminate whole classes of risk; do them before anything else.

Dedicate a machine. A small VPS or a spare Mac mini is enough. The agent gets its own world, and a compromise is contained to that world. This is boundary protection, the same control NIST defines for isolating systems that should not reach each other [11], and it does more for your safety than everything else combined. The NCSC's own test for agentic AI is blunt: if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment [12].

Pair senders. Configure the agent to respond only to your named accounts on each channel. Strangers should not merely be refused; they should be invisible. Because anything that can message the agent can attempt to inject instructions into it, this is your main defence against injection by message.

Allowlist commands. Deny by default. This is the principle of least privilege, which NIST defines as allowing only the access necessary to accomplish the task [11], and which the NCSC restates for agents as giving them the minimum access they need, for the shortest time required [12]. If the agent's job is calendars and email, it does not need to install software or change the network configuration. Add permissions when a real task needs them, not in advance.

Vault the keys. Secrets belong in a dedicated secret store or, at the least, in environment configuration, never hardcoded in plain config files [10]. Set spending limits at the provider so a runaway or hijacked agent cannot empty the account, and keep a nightly backup of the memory files that you have actually tested restoring. The memory is the value of a long-running agent; losing it resets the relationship to zero.

Close the network. No public ports, no exposed gateway, no admin interface reachable from the internet. The one-click RCE above existed precisely because an instance would talk to a network endpoint it should never have trusted [3]. If you do not need remote access, do not expose it; if you do, put it behind a VPN, not a port forward.

Vet every skill. Read a skill before it can read you. Treat the ClawHub registry the way you would treat any package registry feeding production: pin what you install, review what it does, and prefer a smaller set of skills you understand over a large set you do not [5].

A useful test for any setting: would this be acceptable for a new employee with a company credit card? If the answer is no, it is not acceptable for an agent either.

Staying safe is operations, not setup

The uncomfortable truth about self-hosting an agent is that the installation is the easy weekend; the safety lives in the routine that follows. The NCSC's guidance is to deploy agentic AI incrementally, starting with tightly bounded tasks, and to keep its actions monitored and contained [12]. Three habits cover most of it:

1. A weekly look at the logs. Not forensics; ten minutes asking "did it do anything I did not expect?". Escalations and refused commands are the interesting lines.
2. A standing update window. The project moves quickly and so do the people probing it. Updates applied on a schedule, with the release notes actually read, are how the CVEs above stay fixed rather than merely fixable.
3. A periodic review of skills and permissions. Capability creep is real: permissions granted for one task in March are still there in June. Prune what is no longer earning its risk.

Frequently asked questions

Is OpenClaw safe to self-host?

Yes, if you harden it deliberately. The default single-machine install is not safe by itself: OpenClaw can run commands, act unattended and has had real remote-code-execution and prompt-injection vulnerabilities disclosed [3][5]. Hardened properly, with isolation, sender pairing, command allowlisting, locked-down secrets and a patching routine, it is a controlled tool. The risk comes from running it with default trust, not from the project itself.

What is the single most important control?

Restricting who can talk to it, closely followed by giving it a dedicated machine. Because prompt injection arrives through the messages and content the agent reads [7], limiting the agent to your own named accounts removes the most common attack path, and isolating it on its own machine contains the damage if anything does go wrong [11].

Do I need to be a security expert to run it?

No, but you do need to treat it as a standing commitment rather than a weekend project. The hardening checklist here is achievable by a competent technical person. The part that catches people out is the ongoing operations, the weekly log review and the update window, which is where most of the real-world risk actually lives.

Run it yourself, or have it run

If you enjoy this kind of work, the checklist above is entirely doable yourself, and we would genuinely encourage it; an agent you understand is safer than one you do not. The honest caveat is that it is a standing commitment, not a weekend project, and the cost of skipping the boring parts arrives all at once rather than gradually.

If you would rather own the agent without owning the operations, that is the service we sell: installation, hardening and ongoing management of OpenClaw, on your server or on UK-based hosting we manage, with everything in this guide done properly and kept that way. We also install and migrate to Hermes Agent, if that is where you are heading.

OpenClaw is an independent open-source project; Zegaware is not affiliated with or endorsed by it.

Sources

1. Star History, "OpenClaw Surpasses React to Become the Most-Starred Software Project on GitHub", 2026. https://www.star-history.com/blog/openclaw-surpasses-react-most-starred-software
2. OpenClaw documentation, Tools and Automation. https://docs.openclaw.ai/tools
3. MITRE CVE record, CVE-2026-25253 (OpenClaw one-click remote code execution, CVSS 8.8), published 1 February 2026. https://www.cve.org/CVERecord?id=CVE-2026-25253
4. Infosecurity Magazine, "Researchers Discover Six New OpenClaw Vulnerabilities" (Endor Labs), 19 February 2026. https://www.infosecurity-magazine.com/news/researchers-six-new-openclaw/
5. "Taming OpenClaw: Security Analysis and Mitigation of Autonomous LLM Agent Threats", arXiv:2603.11619, March 2026. https://arxiv.org/abs/2603.11619
6. National Cyber Security Centre, "Prompt injection is not SQL injection (it may be worse)". https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
7. OWASP, "LLM01:2025 Prompt Injection", Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
8. NIST National Vulnerability Database, CVE-2025-32711 ("EchoLeak", zero-click indirect prompt injection in Microsoft 365 Copilot). https://nvd.nist.gov/vuln/detail/cve-2025-32711
9. OWASP, "LLM06:2025 Excessive Agency", Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
10. OWASP, Secrets Management Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
11. NIST SP 800-53 Rev. 5, Security and Privacy Controls (AC-6 Least Privilege; SC-7 Boundary Protection). https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
12. National Cyber Security Centre, "Thinking carefully before adopting agentic AI", 15 May 2026. https://www.ncsc.gov.uk/blogs/thinking-carefully-before-adopting-agentic-ai