How to safely experiment with OpenClaw

OpenClaw is one of the fastest-growing open-source projects in history, and it's easy to see why. Connect it to your messaging apps, give it access to your email and calendar, and you have an AI agent that actually does things around the clock instead of just answering questions. For IT managers, operations leads, and developers exploring automation, that's a compelling pitch.

The catch is that OpenClaw's power comes directly from the permissions you give it. Set it up carelessly, and you're handing an AI agent root access to your machine, your credentials, and potentially your company's data. With the right approach, though, you can explore what it can do without taking on unnecessary risk.

How does OpenClaw work?

OpenClaw is a self-hosted agent runtime that acts as a personal AI assistant running on your own machine. It's a long-running Node.js service that connects chat platforms like WhatsApp and Discord to an AI agent capable of executing real-world tasks. You interact with it through messaging apps you already use, and it acts on your behalf: browsing the web, managing files, running scripts, and calling external APIs.

The agent is model-agnostic. You can connect it to Claude, GPT, DeepSeek, or a locally hosted model using your own API keys. Its capabilities come from "skills," which are extensions that let the agent interact with browsers, file systems, messaging apps, and productivity tools. Some installations ship with over 100 prebuilt skills, and developers can add their own.

The architecture is deliberately simple. Persistent memory is stored as Markdown files on disk, so you can view and edit the agent's notes directly. It also runs on a schedule. It can check your inbox each morning, flag anything urgent, and keep working on longer tasks while you're away.

Is it safe to use OpenClaw?

In its default state, no.

OpenClaw requires access to email accounts, calendars, messaging platforms, and system-level commands, which creates a wide attack surface. A Kaspersky security audit from early 2026 identified 512 vulnerabilities, eight of them critical. Researchers around the same time found nearly a thousand publicly accessible OpenClaw installations running with no authentication at all.

The most persistent risk is prompt injection. Every email, message, and webpage your agent reads is a potential attack vector. A malicious actor can embed instructions inside content the agent processes, tricking it into leaking credentials or executing commands you never authorized. This isn't a fringe concern; it's architecturally baked in, and the project's own creator has acknowledged it as an unsolved problem.

The skills marketplace adds another layer of risk. Bitdefender found that around 20% of ClawHub skills were malicious. Installing a skill is essentially installing privileged code, and unverified skills have been linked to credential theft and data exfiltration. A critical vulnerability from early 2026, CVE-2026-25253, enabled one-click remote code execution via WebSocket token theft, and researchers found over 17,500 internet-exposed instances affected before it was patched.

Even with individual vulnerabilities addressed, the underlying architecture keeps the risk real. Broad permissions, external content ingestion, and a public skills marketplace are features, not bugs, and they require ongoing attention rather than a one-time fix.

Yet none of this puts OpenClaw out of reach. We've seen developers run it securely using isolated environments, scoped credentials, and active monitoring. The way you deploy it is what determines whether experimenting with OpenClaw is a manageable risk or an open door.

How to use OpenClaw safely

Running OpenClaw on your primary laptop with full system access is a very different proposition from running it in a sandboxed container on a dedicated machine with tightly scoped credentials. The deployment choices you make upfront shape almost every other risk factor, so it's worth getting those right before you do anything else.

Choosing a deployment environment

Your first decision is where OpenClaw actually runs. Each option offers a different tradeoff between convenience and isolation.

Dedicated hardware

If you want to experiment on physical hardware, use a spare machine, not your primary laptop or a work device. A dedicated Mac Mini or Raspberry Pi keeps the agent off machines that hold sensitive data and makes it straightforward to wipe and rebuild if something goes wrong.

Docker containers

Docker is a good option for developers who want isolated, reproducible setups. Configure it to run OpenClaw as a non-root user, use a read-only root filesystem, drop all Linux capabilities, and bind the gateway port to 127.0.0.1 so it's only accessible from the host or over an SSH tunnel. Mount only the directories the agent actually needs.

VPS hosting

VPS servers add network isolation that's hard to replicate on a local machine. Hostinger's Docker-based OpenClaw deployment automatically assigns a random port and enables gateway authentication. DigitalOcean offers a similar hardened image that removes two common configuration mistakes. Both are reasonable starting points, but they still need the additional hardening steps below.

Locking down network access

Keep the gateway off the public internet. Bind it to localhost or a private network, use a firewall, and access it remotely over a VPN like Tailscale. OpenClaw's gateway runs on port 18789 by default, and leaving that exposed is one of the most common misconfigurations we've seen documented in the wild.

If you're running OpenClaw in Docker, note that Docker has its own forwarding chains that bypass standard host firewall rules. Route your rules through the DOCKER-USER chain to ensure they apply. On shared networks, also consider disabling mDNS broadcasting: the gateway advertises its presence with TXT records that can expose filesystem paths and hostname details to anyone else on the network.

Credentials and permissions

Never connect OpenClaw to your primary accounts. Create dedicated accounts for any messaging apps or services you link to it, use separate API keys per service, and set spending limits where your provider allows. Store credentials in environment variables rather than plain-text config files, and restrict file permissions so sensitive files are only readable by the OpenClaw process owner.

Apply the same restraint to skills. Only enable what OpenClaw genuinely needs for the task at hand, and review the source code of any ClawHub skill before installing it. Given that roughly one in five skills in the marketplace has been found to be malicious, treating it as untrusted by default is the safer starting position.

Sandbox mode and tool policy

Enable sandbox mode.

Without it, commands execute with far fewer restrictions, which significantly widens what a successful prompt injection could do. If you're using Docker, also disable external network access for sandboxed tasks unless you have a specific reason to allow it.

On top of sandboxing, configure a restrictive tool policy. Block dangerous commands by default, use allowlists rather than denylists where possible, and for anything that touches production systems or sensitive data, require explicit human approval before the agent acts.

Ongoing oversight

Safe deployment isn't a one-time setup. Enable session and action logging from the start, so you have a record of what the agent executes, when, and why. Review logs regularly, particularly in the early stages when you're still getting a feel for what normal behavior looks like.

Keep OpenClaw updated, watch the project's security advisories, and run an OpenClaw security audit after any configuration change or change to your network setup. If the logs show something unexpected, take it seriously. The agent has access to your credentials and files, and catching anomalies early is much easier than investigating after the fact.