OpenClaw Gateway architecture and security controls

OpenClaw ships with conservative defaults: on a regular host the Gateway binds to loopback, most channels answer an unknown sender with a pairing code instead of processing the message, and a security audit command reports what you have loosened. The docs organise the rest around one idea, one trust boundary per Gateway, and a matrix of which control means what. Here is the architecture as the security pages describe it, control by control, with the misreadings the docs explicitly close.

One trust boundary per Gateway

Supported: a single operator, or a team whose members trust each other, ideally one operating-system user, host or VPS per boundary. Not supported: one shared Gateway used by mutually untrusted users. Everyone who can message a tool-enabled agent shares that agent’s delegated tool authority, session tools reach across the whole Gateway by default, and anyone who can modify the host config is a trusted operator. For adversarial users the answer is separate Gateways, not settings.

Most failures here are not exotic exploits - they are “someone messaged the bot and the bot did what they asked.”

The controls, in the docs’ order

• Identity first: who may talk to the bot. DM pairing, allowlists, or an explicit open policy.
• Scope next: where the bot may act. Group allowlists and mention gating, tool policy, sandboxing, device permissions.
• Network exposure: one port for WebSocket and HTTP, loopback by default; LAN, tailnet or custom binds widen the surface and need Gateway auth and a real firewall. The docs prefer Tailscale Serve over a LAN bind.
• Gateway auth: a token, a password, a trusted proxy or device auth authenticate callers to the Gateway APIs; the session key is a routing selector, never an authorisation token.
• Discovery: the Bonjour plugin broadcasts presence on the LAN when enabled; keep it off unless needed, and minimal when on.
• Docker: published container ports bypass the host’s input rules, so firewall them in the Docker user chain, IPv6 included.

What the docs refuse to call a vulnerability

The trust-model page keeps a list of findings closed as no-action, and it is instructive: prompt-injection chains with no policy, auth or sandbox bypass; claims that assume hostile multi-tenancy on one host; operator read access to sessions classed as an access flaw; localhost-only findings; the session key treated as user authorisation; default cross-agent session visibility treated as a tenant bypass. Each is a boundary the software never claimed.

Gateway and node

Gateway and node are one operator trust domain with different roles: the Gateway is the control plane and policy surface, the node is a remote execution surface paired to it, and a caller authenticated to the Gateway is trusted at Gateway scope. Exec approvals are guardrails for operator intent, not tenant isolation, and the trusted single-operator default allows host exec without prompts on purpose. OpenClaw nodes and Remote Hands covers the pairing and Sandboxing, tool policy and elevated the policy layers.

On Diali

Diali runs exactly the supported shape, one Gateway per boundary: every assistant is its own instance, with its own kernel-level sandbox, namespace and network policy, no public ports and outbound access to the public web only, never to our internal network, the cloud metadata server or other tenants, so the network-exposure chapter is answered by the platform and the identity and scope chapters stay in your dashboard. Security on Diali is the page for the boundary; OpenClaw security best practices is the config the docs recommend, explained.

• One boundary per Gateway; adversaries get their own.
• Identity first, scope next, exposure last.
• The session key routes; it never authorises.