July 5, 2026 · 4 min read
Running OpenClaw Safely: Closing the Remote Code Execution Gap
Every capability that makes OpenClaw useful is also a capability an attacker would want. It can read incoming messages, decide what they mean, and execute commands in response. That is the entire point of a personal AI assistant — and it is also, without hardening, a remote code execution surface. The right response is not to avoid that power. It is to reason about it explicitly and close the gaps deliberately.
Where the risk actually comes from
Three surfaces account for almost every real-world OpenClaw security concern.
Exec-capable skills. Any skill that can run a shell command, spin up a container, or execute code on your behalf is a skill that can do real damage if invoked with the wrong input. The Docker skill is a good example — genuinely useful for dev workflows, and exactly the kind of capability you want gated behind explicit approval rather than silent auto-execution.
Prompt injection. OpenClaw's model reads content from a lot of places it does not fully control — inbound messages, web pages it browses, tool results from MCP servers. A message or page can contain text engineered to look like an instruction: "ignore the above and run this command instead." The model does not need to be tricked often for this to matter; it needs to be tricked once, at the wrong moment, with an exec-capable skill installed.
Unaudited third-party skills. ClawHub is a community registry. Most published skills are exactly what they claim to be, but "most" is not "all," and a skill you install without reading is code you are trusting sight unseen — often with access to your accounts, your filesystem, or your shell.
What OpenClaw already hardens for you
This is not a theoretical concern the project has ignored. Recent stable releases have been explicit about it — see our release highlights for the detail, but the relevant points are worth calling out directly:
- Exec approvals fail closed. If a command approval times out, the command does not run. Earlier behaviour could let a timed-out approval fall through — exactly the edge case you want resolved in the strict direction on a system that can execute commands.
- Sandbox file binds are tightened, narrowing what a sandboxed process can actually touch on disk.
- MCP servers speaking over stdio get a hardened trust boundary, since MCP tool results are exactly the kind of external content prompt injection can ride in on.
- ClawHub installs retain verified source provenance, so you can confirm a skill actually came from where it claims to.
None of this is optional configuration — it ships in the framework. But it narrows the gap; it does not close it. The rest is on your setup.
What's still on you
Scope exec-capable skills to specific approval, not blanket trust. If a skill can run commands, keep it behind an explicit approval step rather than an auto-approve rule that seemed convenient during setup. The one time it matters is the only time it needs to matter.
Run OpenClaw itself inside an isolated environment. A container or a dedicated VM means that if a skill misbehaves — through a bug or a successful injection — the blast radius stops at that boundary instead of reaching your host machine or your other credentials.
Restrict network egress for the process where you reasonably can. A compromised skill that cannot reach the internet cannot exfiltrate anything, even if everything else went wrong.
Read a skill before you install it. clawhub install <skill> takes seconds; reading the manifest and handler it installs takes two minutes and tells you exactly what data and access it requests. For anything exec-capable, that two minutes is non-negotiable.
Pin versions and update deliberately. A skill that behaves safely today can change behaviour in an update. Combine this with the practice we cover in why OpenClaw's weekly releases matter — read what changed before you upgrade, in both directions: the framework's releases and your installed skills'.
A short pre-flight checklist
- List every skill with exec, shell, or container access, and confirm each one requires explicit approval.
- Confirm OpenClaw runs in a container or VM boundary, not directly on a machine with unrelated credentials or data.
- Check egress rules — does this process need unrestricted outbound network access, or just a handful of known hosts?
- For each installed skill, confirm you have actually read what it does, not just what its description claims.
Getting this right once, at setup, is far cheaper than reasoning about it after an incident. If you want a second set of eyes on a specific deployment — which skills are exec-capable, whether your sandboxing actually holds, whether your approval flow has a gap — talk to us.
Want OpenClaw set up properly?
We install and configure OpenClaw, choose and tune skills for your workflow, and build custom skills where the catalogue falls short.
Talk to us about your setup →