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.
Agents with message-tool access can send across conversations and channel providers by default. If your deployment needs messaging confined to the current provider or conversation, configure cross-provider messaging restrictions.

​
Security pages

Understand the model:
  • Security trust model - One trust boundary per gateway, the boundary matrix, and the findings closed as no-action.
  • Running the security audit - What openclaw security audit checks and the order to fix findings in.
  • Security audit checks - Reference catalog of every checkId, its severity, and its auto-fix support.
  • Threat model - Adversarial threats to the OpenClaw platform and ClawHub, mapped to MITRE ATLAS.
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