How to Secure Your OpenClaw Agent: Production Security Checklist

This is a production risk-reduction checklist, not a guarantee of safety.

1) Define the trust boundary first

• Run one Gateway per trust boundary.
• Do not share one tool-enabled Gateway across mutually untrusted or adversarial users.
• If someone can modify ~/.openclaw or openclaw.json, treat them as a trusted operator.
• Treat root on the Gateway host as full operator access.
• sessionKey is for routing, not authorization.

2) Lock down who can message the bot

Use pairing or allowlists unless you intentionally want public DMs.

{
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: {
        "*": { requireMention: true },
      },
    },
  },
  session: {
    dmScope: "per-channel-peer",
  },
}

• dmPolicy: "pairing" is the default DM posture.
• Use dmPolicy: "allowlist" for known senders only.
• Use dmPolicy: "disabled" for channels you do not want to receive.
• For groups, require mentions or explicit allowlists.
• For shared inboxes or multi-user DMs, set session.dmScope: "per-channel-peer" or use separate gateways.

3) Keep the Gateway exposure narrow

• Default to gateway.bind: "loopback".
• Use SSH tunneling or Tailscale Serve for remote access when possible.
• If you expose beyond loopback, require gateway auth.
• Treat Funnel/public exposure as intentional, not accidental.
• For trusted proxies, only use gateway.auth.mode: "trusted-proxy" when the proxy is identity-aware and all other ingress paths are blocked.
• Treat browser control and paired node control like operator access, not ordinary user access.

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

4) Sandbox tool execution

Sandboxing is off by default. The Gateway stays on the host; only tool execution moves into the sandbox when enabled.

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",
        backend: "docker",
        scope: "agent",
        workspaceAccess: "ro",
      },
    },
  },
}

• Prefer mode: "all" for the strongest separation you can support.
• Keep workspace access read-only unless write access is required.
• Remember that tools.elevated bypasses sandboxing.
• Sandboxing does not move the Gateway process itself into the sandbox.

5) Constrain tool policy explicitly

Tool policy is enforced before the model call.

• Start from a narrow profile such as tools.profile: "messaging" or tools.profile: "minimal".
• Deny runtime, filesystem, browser, and network tools the agent does not need.
• Keep tools.elevated.enabled: false unless you have a specific reason to allow it.
• If you allow interpreters, keep the current exec approval settings documented in the tools policy page.
• For production, prefer the smallest tool set that still lets the agent do its job.

Example starting point from the current security docs:

{
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}

6) Handle secrets as secrets

• Use SecretRefs where supported instead of hardcoding plaintext secrets.
• Prefer source: "env", source: "file", or source: "exec" depending on the credential source.
• Keep secrets out of prompts, attachments, logs, and shared docs.
• Prefer --token-file or --password-file for CLI use when a file-based secret is appropriate.
• Keep ~/.openclaw/openclaw.json as a real file, not a symlinked config path.
• Add logging.redactPatterns for tokens, hostnames, and internal URLs that are specific to your environment.

For example, a model provider API key can use an env-backed SecretRef such as OPENAI_API_KEY.

7) Audit, logs, and transcripts

• Run openclaw security audit after config changes and before exposing new network surfaces.
• Use --deep when you want a live Gateway probe.
• Use --fix only for the narrow remediations documented by OpenClaw.
• Log/transcript redaction is always on.
• When sharing diagnostics, prefer openclaw status --all over raw logs.
• Review openclaw logs, relevant transcripts, and recent config changes that could widen access.

8) Treat untrusted content as hostile

• Prompt injection is a content risk, not just a sender risk.
• Links, attachments, pasted logs, fetched pages, and tool results can all carry hostile instructions.
• Keep web_search, web_fetch, and browser off unless a trusted workflow needs them.
• Use a read-only or tool-limited reader agent for untrusted content, then hand summaries to the main agent.

Verification checklist

Before calling the deployment ready, confirm all of these:

• openclaw security audit is clean for the intended deployment mode
• openclaw security audit --deep passes if the Gateway is reachable remotely
• gateway.bind is loopback-only, or the remote bind is intentionally documented
• gateway.auth is set for every non-loopback exposure path
• DMs use pairing or allowlists, not accidental open access
• Group rooms require mentions or explicit allowlists
• session.dmScope is isolated for shared inboxes
• Sandbox mode is enabled for the right agents and tools.elevated is off unless required
• Tool policy only exposes the tools the agent actually needs
• Secrets use SecretRefs or other non-plaintext handling
• Logs and status output do not leak secrets
• Recent config changes were reviewed before rollout

Bottom line

OpenClaw is safest when you keep the trust boundary small, expose the Gateway only as far as necessary, limit tools aggressively, sandbox what can be sandboxed, and treat every untrusted message or attachment as potentially adversarial.