Skip to main content
OpenClaw ships with conservative defaults. On a regular host install the Gateway binds to loopback; most chat channels answer an unknown DM sender with a pairing code instead of processing the message; and group access is allowlisted, usually behind a mention gate. The exceptions are deliberate and documented: container images default to an exposed bind (pair that with auth - see the exposure runbook), and a few workspace channels such as ClickClack trust workspace membership by default - each channel page states its exact defaults. Run on those defaults and you are in good shape, and one command tells you if you have drifted:
The pages below are the deep end: the trust model, what the audit checks, and how to harden further as you expose more surface.
One trust boundary per gateway. This guidance assumes one trusted boundary per gateway: a single operator, or a team whose members trust each other. Group chats and multi-user operation are supported deployments inside that boundary. OpenClaw is not a hostile multi-tenant security boundary for mutually adversarial users sharing one agent or gateway. For mixed-trust or adversarial-user operation, split trust boundaries: separate gateway + credentials, ideally separate OS users or hosts.

​
Security pages

Understand the model: Harden a deployment: Expose and operate: Run it from the CLI:
  • openclaw security - Run the audit, read findings, and apply the supported auto-fixes.
  • openclaw policy - Inspect and test the tool policy the guidance above configures.

​
Where each section moved

Every anchor this page used to publish still resolves here. Each entry below carries the original anchor and links to its new home. Security trust model Running the security audit Hardened baselines Access control and allowlists Prompt injection Tool and agent permissions Browser control risks Network exposure Secrets, storage, and logs Operator incident response