Secure OpenClaw with Command Allowlists and Tailscale

This playbook turns community hardening advice into a reproducible baseline: reduce command surface, avoid dangerous defaults, and isolate gateway access to a private network.

1-Minute Hardening Baseline

Apply this first, then tune per environment.

Security Baseline

# 1) Restrict command execution scope
# Keep only what your workflow actually needs.

# 2) Disable non-essential network fetch in agent paths
# (if your tasks do not require arbitrary remote fetches)

# 3) Run gateway behind a private network path (e.g. Tailscale)

# 4) Restart and verify
openclaw gateway restart
openclaw doctor

Why This Matters

Most avoidable incidents come from over-permissive execution or exposing gateway endpoints to broader networks than needed. Least-privilege defaults lower blast radius when prompts, skills, or dependencies misbehave.

Step 1: Minimize Command Surface

Treat shell execution as privileged. If a workflow does not need a binary, do not allow it by default. Start narrow and add only proven-needed commands.

Step 2: Limit Remote Fetch Paths

If your agent flow is local-only or uses vetted APIs, disable broad fetch behavior in runtime paths to reduce prompt-driven data exfiltration risks.

Step 3: Put Gateway on a Private Network

Prefer private connectivity (Tailscale/private tunnel) over open network exposure. This keeps the control plane reachable only by approved peers.

Do not copy unknown “security snippets” blindly. Validate against your current OpenClaw version and official docs before applying to production.

Validation Checklist

Gateway is reachable only from trusted network peers.

Unneeded shell commands are not broadly enabled.

Non-essential remote fetch paths are disabled.

Post-change sanity check passes: openclaw doctor.

Generate a Hardened Config

Use Config Wizard to generate a baseline config, then apply your command allowlist and network constraints in one pass.

Open Config Wizard

Sources

Did this guide solve your problem?