Running OpenClaw safely: a hardening checklist

OpenClaw can run commands and read your files, so set it up like the operator tool it is: gateway auth, DM pairing, tool sandboxing, and the built-in security audit.

OpenClaw is an operator agent: it executes shell commands, touches your filesystem, and answers strangers on messaging channels if you let it. Its security model assumes a single trusted operator (you), and the project itself ships good guardrails. This checklist walks the ones that matter, in the order an attacker would meet them.

1. Run the built-in audit first

OpenClaw ships a security auditor that checks inbound access policies, tool blast radius, filesystem permissions, exec approval drift, network exposure, and browser control settings:

openclaw security audit
openclaw security audit --deep   # more thorough checks
openclaw security audit --fix    # apply safe fixes automatically

Re-run it after any config change that widens access.

2. Lock down the Gateway

Set a real bearer token and keep the Gateway on loopback:

{
  gateway: {
    auth: { mode: "token", token: "your-long-random-token" },
    bind: "loopback"
  }
}

If you need remote access, prefer Tailscale Serve over LAN binds: Serve keeps the Gateway on loopback and Tailscale handles access. Only move to "lan" or "tailnet" binds with real authentication and firewall rules in place.

3. Gate who can talk to the bot

Unknown senders should never reach your agent directly. Use pairing, which sends a time-limited code that you approve:

{
  channels: {
    whatsapp: { dmPolicy: "pairing" },
  }
}

In groups, require an explicit mention so the bot is not always-on for everyone in the room:

{
  channels: {
    whatsapp: {
      groups: { "*": { requireMention: true } }
    }
  }
}

4. Limit what the agent can do

Assume the model can be manipulated by content it reads, and limit the blast radius. A conservative baseline for a messaging-facing agent:

{
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs"],
    exec: { security: "deny", ask: "always" }
  }
}

Also keep control-plane tools away from the model by default; gateway can rewrite persistent config and cron creates persistent jobs:

{
  tools: {
    deny: ["gateway", "cron", "sessions_spawn", "sessions_send"]
  }
}

5. Protect secrets on disk

  • ~/.openclaw/ should be 700, and ~/.openclaw/openclaw.json should be 600.
  • Sensitive paths to be aware of: session transcripts under ~/.openclaw/agents/<agentId>/sessions/, channel credentials under ~/.openclaw/credentials/, and auth profiles per agent.

6. Be picky about skills

Community skill marketplaces have had real problems with malicious packages, and OpenClaw's ecosystem is no exception. Install skills the way you would install browser extensions with shell access: only from sources you trust, after reading what they execute. Our directory lists verified skills for OpenClaw with provenance shown for each one.

If something goes wrong

Contain first: stop the Gateway, set gateway.bind: "loopback", and disable risky DMs and groups (dmPolicy: "disabled"). Then rotate everything: the gateway auth token, remote client credentials, provider API keys, and channel tokens. Finally review Gateway logs and session transcripts, and re-run openclaw security audit --deep.

Report vulnerabilities responsibly to security@openclaw.ai.

Source: OpenClaw gateway security docs, checked June 2026.

Share:
Explore OpenClawInstallationIntegrations