OpenClaw Security Best Practices

Run on isolated hardware

Never run OpenClaw on your primary machine. Use a VPS, spare laptop, or Raspberry Pi. If the agent is compromised, the attacker only gets access to that isolated environment — not your workstation with SSH keys and browser sessions.

Bind gateway to localhost

The single most important configuration. Never bind to 0.0.0.0. Exposed gateways are found by scanners within hours.

Use Tailscale or SSH tunnels for remote access

Never open port 18789 in your firewall. Instead, use encrypted tunnels:

Lock down file permissions

Credential files must be readable only by the OpenClaw user. This is basic but constantly skipped.

Enable gateway auth and disable mDNS

Keep device authentication enabled so misrouted requests can't take over your instance. Disable mDNS to stop broadcasting your installation on the local network.

Set DM policy to pairing or allowlist

Prevent strangers from sending commands to your bot. Never use "dmPolicy": "open" with "allowFrom": ["*"].

Run the built-in security audit

OpenClaw checks for common misconfigurations. Run this after setup and every few weeks.

Use tool allowlists, not denylists

Denylists fail because attackers find alternatives. With an allowlist, if a command isn't listed, it cannot run.

Restrict filesystem access

Scope the agent to specific directories. A prompt injection that steals SSH keys starts with the agent being able to read ~/.ssh.

Harden your channels

Each messaging platform has its own attack surface:

• •WhatsApp: Use DM pairing or allowlist with specific phone numbers. Use a dedicated number.
• •Discord: Require mentions in guilds. Disable DMs. Limit to specific channels.
• •Telegram: Use the official Bot API. Keep DMs pairing-only.

Encrypt credentials at rest

Default plaintext storage makes credentials easy targets. Use age or pass to encrypt sensitive config files.

Lock down MCP servers

Each MCP server is code running with your agent's permissions. Use explicit allowlists, pin versions, and disable risky servers like filesystem, shell, and ssh.

• •Never use "enableAllProjectMcpServers": true
• •Always version pin: "version": "0.3.0" (not "latest")
• •Set "autoUpdate": false

Monitor weekly, maintain monthly

Set up automated checks for exposed ports, disabled auth, prompt injection patterns in session logs, and unusual API usage spikes. Monthly, review session logs, update software, audit installed skills, and rotate your gateway token.

Container isolation

Run OpenClaw inside Docker or rootless Podman with no-new-privileges, cap-drop: ALL, and a read-only filesystem. Containers won't prevent everything, but they make a lot of attacks harder and recovery simpler. Never mount /var/run/docker.sock or your entire home directory into the container.

Credential brokering

Place a LiteLLM proxy between OpenClaw and your model providers. OpenClaw never sees real API keys — LiteLLM injects them. This also gives you rate limiting, cost controls, and centralized request logging.

Network egress filtering

Deploy a Squid proxy with a strict domain allowlist. Deny all outbound traffic by default and only allow domains you explicitly need (npm registry, GitHub, your messaging provider). Blocked domains get logged so you can audit exfiltration attempts.

Separate agents by risk profile

Don't give one agent all privileges. Create separate agents scoped to their role:

• •File agent: filesystem access, no shell, no internet
• •Dev agent: shell allowlisted, no credentials
• •Research agent: web access via proxy, no file writes

Review skills before installing

Research has found that 26% of agent skills contain vulnerabilities. The ClawdHub skill registry has no moderation process. Download, extract, and read the source code before installing any skill. Search for eval(, exec(, unexpected fetch( calls, and credential access beyond what's documented.

Have an incident response plan

Write down what to do when (not if) something goes wrong. Your first 5 minutes should be: stop OpenClaw, block all network traffic, preserve logs. Then rotate every credential, check provider dashboards for spikes, and review session logs. If you suspect host compromise, rebuild from scratch — don't try to clean it.