OpenClaw security best practices

The OpenClaw docs publish a hardened baseline: a copy-and-paste Gateway configuration that keeps a deployment private, paired and tool-restricted, and a shorter secure baseline for people who only want the first three lines. This post is that configuration explained key by key, why each line is there, and which of the decisions survive on a managed host where the plumbing is someone else’s.

The Gateway: local, loopback, token

Mode local and bind loopback keep the Gateway off the network; token authentication with a long random token gates every client, even local ones, because the default auth mode is token even for loopback binds. The docs put a real number on the port, 18789, and a real warning on the alternative: setting auth to none lets any local process connect.

The channels: pairing and mentions

• DM policy pairing on every channel: unknown senders wait for your approval, and approval is per channel.
• Groups require a mention by default, so the agent reads a room without answering every line.
• A separate number for phone-based channels, so personal conversations stay private and the bot number carries the automation.
• DM scope per channel peer, so one sender’s session cannot bleed into another’s.

The tools: a profile, a deny list, and no escape hatch

The hardened baseline starts from the messaging tool profile and denies four groups outright: automation, runtime, the filesystem, and spawning or messaging other sessions. Filesystem access is workspace-only, exec is denied and set to ask always, elevated is disabled, session visibility is limited to the agent’s own, and agent-to-agent access is off. The docs say to re-enable a tool when you need it, deliberately, rather than to start open and close later. One rule is built in and cannot be configured away: non-owner senders never get the cron or gateway tools.

Treat these controls as defense in depth that reduces direct capability for a requester, not as hostile multi-user isolation.

What the baseline does not do

• It does not sanitise content: requester-scoped controls limit what a sender can do, not what a web page or an email can say to the model.
• It does not isolate hostile local users: for that, the docs say to run separate Gateways under separate operating-system users or hosts, or to sandbox.
• It does not choose your model tier, which the prompt-injection page treats as a security control in its own right.

Prompt injection and OpenClaw covers the content side, and Sandboxing, tool policy and elevated the where-tools-run side; the baseline is the who-may-do-what side, and the three are meant to stack.

On Diali

The Gateway lines are ours: it is never on the internet, the instance has no public ports and outbound access to the public web only, never to our internal network, the cloud metadata server or other tenants, and the token never leaves the vault. The channel and tool lines are yours, in the dashboard, because who may message the assistant and what it may run are policy rather than plumbing. Security on Diali is the page for the boundary; Hosted OpenClaw on Diali for the assistant.

• Local, loopback, token: the Gateway is not a server.
• Pairing, mentions, a separate number: the channels are gated.
• A profile, a deny list, no elevated: the tools are the smallest set that does the job.