How to Avoid Exposing OpenClaw Gateway Publicly

The safest OpenClaw network posture is boring: the Gateway listens on loopback, trusted operators reach it through SSH or a tailnet, and public users talk only to product-specific applications that you control. That matters because OpenClaw is not just a chat server. It can own tools, nodes, browser control, sessions, channels, model credentials, and automation.

30-second answer

Keep gateway.bind loopback by default. For remote access, use SSH forwarding or Tailscale Serve. If you intentionally use LAN, tailnet, custom bind, or public ingress, configure Gateway auth and understand which surfaces become reachable. Use separate Gateways for separate trust boundaries instead of trying to make one Gateway safely serve everyone.

When this pays off

This guide matters when someone wants to “just expose the port” so a phone, dashboard, webhook, Open WebUI, or customer app can connect. That shortcut can work in a demo and hurt in production. Buyers evaluating OpenClaw for business automation need confidence that the control plane is private even when the output appears in public channels.

Operator runbook

1. Classify every caller first. Operator clients, Control UI, WebChat, API clients, nodes, and public customers do not have the same trust level. If you cannot describe who is connecting and why, keep the Gateway loopback-only and put a small backend service in front of any external workflow.
2. Use loopback plus SSH for universal remote access. The official remote guide describes forwarding 18789 over SSH and keeping the Gateway WebSocket on 127.0.0.1. This works across hosts without opening the Gateway itself to the network.
3. Use Tailscale Serve for operator convenience. Serve gives HTTPS and tailnet routing while the Gateway stays loopback-bound. It can use verified Tailscale identity headers for Control UI/WebSocket flows, but the docs make clear that HTTP API endpoints still follow normal Gateway auth.
4. Require auth on non-loopback binds. If you bind to tailnet, LAN, custom, or auto in a way that leaves loopback, configure token, password, or trusted-proxy auth. Remember that gateway.remote.token is a client credential source; it does not configure server auth by itself.
5. Treat /v1 and /tools/invoke as privileged. The OpenAI-compatible API and Tools Invoke API both use Gateway auth and can represent operator-grade access. Do not expose them as customer APIs. Put your own app backend in the middle and call OpenClaw privately.
6. Split when trust differs. OpenClaw security docs are direct: for mixed-trust teams, adversarial users, or separate tenants, use separate Gateways and ideally separate OS users or hosts. Session keys, model names, and scopes are not a hostile multi-tenant security boundary.

Verification

Run openclaw security audit after network or auth changes. Then check openclaw gateway status, confirm the bind mode, and test that missing or wrong credentials fail. If you rely on a tunnel or tailnet, test from outside that trusted path and confirm the Gateway is unreachable.

Common mistakes

Do not treat a long token as a substitute for private ingress. Do not expose browser control or node pairing paths casually. Do not share one Gateway token across a customer app and an internal admin tool. And do not assume public HTTPS means safe; the question is what authenticated callers can do after they connect.

Turn it into a repeatable operating system

The Playbook gives you the network posture map: local-only, SSH, tailnet, trusted proxy, public product backend, and separate Gateway. That map helps you move fast without turning your AI operator into an accidental public admin panel.

Before rollout

Before rollout, draw the actual traffic path from user to app to Gateway. If a public user can reach the Gateway directly, redesign. If only your backend can reach it, document the backend credential, rotation plan, and the exact OpenClaw surface it is allowed to call.