OpenClaw Security Best Practices

Authoritative configuration guide: Harden your OpenClaw instance with standardized settings to prevent security risks.

1Introduction

As an AI agent framework with fully autonomous execution capabilities, OpenClaw is designed to give AI the ability to operate computers directly. However, this powerful capability comes with high security risks. According to the OpenClaw Security Architecture documentation, agents default to the same system permissions as the running user, meaning that without restrictions, AI can execute arbitrary shell commands, read/write sensitive files, or even modify system configurations.

To mitigate these risks, we must strictly follow the "Principle of Least Privilege" and "Defense in Depth" strategies. The Principle of Least Privilege requires granting AI only the minimum tool and file access necessary to complete specific tasks; Defense in Depth requires us to build defenses at multiple levels such as sandbox isolation, tool whitelisting, and network boundaries to ensure that even if one layer fails, the system as a whole remains secure. This document aims to provide an authoritative configuration guide to help administrators harden OpenClaw instances through standardized settings.

2Enable & Configure Docker Sandbox

OpenClaw's core security mechanism is Docker-based sandbox isolation. In production environments, high-risk agent tasks should never run directly on the host. According to the Docker deployment guide, OpenClaw uses a separated "Host Gateway + Docker Tools" architecture: Gateway handles messages and logic, while actual tool execution (like running code, file operations) is encapsulated in isolated Docker containers.

Mode: non-main (Default)

Enable sandbox only for non-main sessions (e.g., external users via WhatsApp/Telegram). Main user (Owner) operations in local CLI run directly on the host.

Risk

If main user operations are injected with malicious commands, the host security may be compromised.

Mode: all (Recommended)

Force all sessions (including main user) to execute inside Docker containers. This is the setting strongly recommended by the Security Hardening Guide.

Advantage

Provides the highest level of isolation, completely preventing the host from being damaged by misoperations.

2.2 Workspace Access

The workspaceAccess parameter controls container access to host mounted directories.

rw (Read-Write): Default. Allows AI to modify workspace files. Suitable for development scenarios, but data tampering must be prevented.
ro (Read-Only): Read-only access. Suitable for code review or analysis tasks, effectively preventing malicious database deletion.
none: Do not mount any host directories. Suitable for pure logic calculations or temporary tasks without persistence.

3Tool Permission Management Strategy

Sandboxing only isolates the environment, while tool permission management controls "what the AI can do". OpenClaw provides powerful tools.allow and tools.deny configuration items. According to the official tool documentation, the system has several built-in high-risk tool groups, such as group:runtime (includes exec, bash) and group:fs (includes read, write).

Blacklist Priority

tools.deny always takes precedence over tools.allow. Even if a tool is in the allowlist, it will be forcibly disabled if it also appears in the denylist.

Tool Group/Tool	Risk Level	Recommended (Default Secure)	Description
group:runtime (exec, bash)	Very High	deny	Allows execution of arbitrary shell commands. Must be disabled by default, enabled only on demand in a controlled sandbox.
group:fs (write, edit)	High	allow (with Sandbox)	File write permissions should be restricted to specific working directories within the Docker container.
group:browser	Medium	allow	Browser automation. Risks mainly lie in visiting malicious webpages or leaking cookies.
web_search	Low	allow	Retrieving public information only. Usually safe.

Configuration Example (openclaw.json):

{
  "tools": {
    "deny": ["group:runtime", "sys_shutdown"],
    "allow": ["group:fs", "group:browser", "web_search"]
  }
}

4Network & Authentication Hardening

Network-level configuration is the first line of defense against unauthorized access. OpenClaw Gateway listens on an HTTP port by default. Improper configuration may expose control interfaces to the public internet.

Network Binding & Remote Access

According to security best practices, the Gateway's bind address should be strictly set to 127.0.0.1 (Loopback). This ensures the service is visible only to the local machine.

If remote management is needed, NEVER change the bind address to 0.0.0.0. Using VPN solutions like Tailscale or WireGuard is recommended.

IM Channel Pairing Policy (DM Policy)

For channels like WhatsApp and Telegram, dmPolicy is crucial. The default policy might be open.

Force Pairing: Set policy to allowlist, requiring new users to verify via One-Time Token.
Audit Logs: Regularly check authorized users in the ~/.openclaw/credentials/ directory.

5Audit & Monitoring

Security is not a one-time configuration but a continuous process. OpenClaw provides built-in CLI tools to assist with security audits.

5.1 Using Security Audit Command

Administrators should regularly run the openclaw security audit command. This command scans for:

Sensitive tokens stored without encryption
Whether current sandbox mode is off or non-main
Whether high-risk tools are enabled in tools.allow without corresponding restrictions

openclaw security audit --deep

5.2 Regular Checklist

Log Review: Check gateway.log for connection attempts from unknown IPs or abnormal exec calls.

Container Status: Use docker ps to confirm sandbox containers are running normally and no unexpected host directories are mounted.

Policy Update: Re-evaluate the tools.deny list as new tools are installed.