Hardening OpenClaw Security

OpenClaw’s strength is its ability to act. That same capability makes security essential. An agent that can read files, call APIs, or execute tools becomes a liability if it is exposed or granted more access than intended.

Most OpenClaw security failures to date have not involved sophisticated exploits. They have come from exposed gateways, overly permissive defaults, and environments that were never meant to run an autonomous agent. The following focuses on reducing those risks in a practical, verifiable way across common OpenClaw setups.

Decide Where OpenClaw Runs (All Users)

Before touching configuration, decide where OpenClaw lives.

Avoid running OpenClaw directly on a primary work or personal machine that contains sensitive data.

Good options include:

• A small Linux VPS
• A dedicated spare machine
• A virtual machine within your PC

Isolation limits the damage if something goes wrong.

Keep the OpenClaw Gateway Private (All Users)

OpenClaw exposes a local gateway for control and interaction. This gateway should never be publicly accessible.

To change this, you’ll edit OpenClaw’s gateway configuration file, usually located at:

~/.openclaw/gateway.yaml

Open this file in a text editor and ensure it contains settings like the following:

gateway:
host: "127.0.0.1"
port: 18789
controlUi:
dangerouslyDisableDeviceAuth: false

mdns:
enabled: false

These settings ensure the gateway listens only on the local machine, keeps authentication enabled, and avoids broadcasting its presence on the local network.

Verify the Gateway Is Not Exposed (All Users)

After editing the configuration, confirm the gateway is not listening on a public interface.

Run this command in your terminal:

ss -tlnp | grep 18789

This command lists listening network ports. A secure setup shows the gateway bound to 127.0.0.1. If you see 0.0.0.0, the gateway is exposed and must be fixed before continuing.

Restrict Network Access

If OpenClaw runs on Linux or a VPS, a firewall adds another layer of protection.

These commands configure a basic firewall that blocks inbound connections by default while allowing outbound traffic:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

This does not expose the OpenClaw gateway. For remote access, use a secure tunnel (such as SSH port forwarding or a private VPN) instead of opening ports to the internet.

Run OpenClaw Under a Dedicated User (Linux)

On Linux systems, OpenClaw should not run as root.

Create a dedicated user:

sudo adduser openclaw

Running OpenClaw under a limited user account reduces the impact of a compromise by restricting what the agent can access at the system level.

Check and Lock Down File Permissions (All Users)

OpenClaw stores configuration and credentials locally. These files should be readable only by the OpenClaw user.

First, inspect current permissions:

ls -la ~/.openclaw

Then apply restrictive permissions:

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/.yaml 2>/dev/null || true chmod 600 ~/.openclaw/.json 2>/dev/null || true
chmod -R 600 ~/.openclaw/credentials 2>/dev/null || true

Afterward, re-run ls -la ~/.openclaw to confirm sensitive files are not world-readable.

Limit What the Agent Is Allowed to Do (All Users)

If OpenClaw can execute tools or commands, restrict them explicitly.

An allowlist-based configuration ensures the agent can only perform actions you’ve approved. Example pattern:

tools:
shell:
enabled: true
allowlist:
- "ls"
- "cat"
- "grep"

filesystem:
enabled: true
allowedPaths:
- "/home/openclaw/workspace"
deniedPaths:
- "/home/openclaw/.ssh"
- "/etc"

Anything not listed cannot run. This significantly reduces the risk of accidental or malicious actions.

Treat Skills as Executable Software (All Users)

Skills are code. Before installing any third-party skill:

Read the source

Look for network calls or filesystem access

Avoid skills that auto-download or auto-update code

A simple scan after downloading a skill can catch obvious red flags:

grep -R "exec(" -n .
grep -R "eval(" -n .
grep -R "curl " -n .
grep -R "wget " -n .

This doesn’t guarantee safety, but it filters out many unsafe skills early.

Add Regular Verification Checks (All Users)

Misconfigurations often creep in over time. Periodically verify that critical settings haven’t changed.

At minimum, re-check:

• The gateway is bound to 127.0.0.1
• Authentication is enabled
• File permissions are still restrictive

Automating these checks weekly helps catch problems before they become incidents.

Be Deliberate About Connected Accounts (All Users)

Even with hardening, OpenClaw should only interact with low-risk accounts.

Avoid connecting:

• Primary email
• Financial services
• Work or corporate accounts
• Password managers
• Anything you cannot easily replace

Use dedicated or test accounts whenever possible. This limits the real-world impact of mistakes or compromises.

OpenClaw is powerful because it bridges reasoning and action. That power does not come with strong safety rails by default. Careful configuration, limited permissions, and regular verification are what keep experimentation from turning into exposure.

Hardening is not about eliminating all risk but about reducing the blast radius enough that your environment remains a useful tool instead of a liability.