If you have installed OpenClaw on a home server, leave its Gateway on the local machine until you have a reason to connect remotely. A chat integration can make an assistant easier to reach, but it also gives messages a path to tools and data on the host. First decide who is trusted to use the agent, what it may do, and how you will close off access.

OpenClaw’s security guide says a regular host install binds the Gateway to loopback by default. Unknown direct-message senders receive a pairing code in the default setup, and group access is normally allowlisted. Keep those protections in place while you test. The Gateway security guide also says the system is designed around one trusted boundary per Gateway, not a shared boundary for adversarial users.

Key Takeaways

  • Keep the Gateway on loopback unless you have configured and tested an authenticated private route.
  • Pair only the people and groups allowed to send requests to the agent.
  • Limit shell, browser, and other powerful tools when the agent reads messages or web pages from outside your trust boundary.
  • Run openclaw security audit after configuration changes and review each finding.

Keep the Gateway off the public internet

Use the default loopback bind for a single-user installation. A local Gateway can still connect to approved messaging channels, but a remote client cannot reach it just because it exists on your home network. Avoid router port forwarding and public tunnels while you are still exploring the configuration.

If you need remote access, follow OpenClaw’s network exposure guidance. It requires Gateway authentication for remote exposure and describes private access paths such as a tailnet, SSH tunnel, or correctly configured identity-aware proxy. The path you choose should authenticate the operator and limit which machines can reach the service. A long random token is a credential: keep it in a secret store or protected environment, not in a public config file or a message to the bot.

Before enabling a remote path, test it from outside the home network and confirm that an unauthenticated connection fails. Then check that the Gateway is not also reachable through an unintended public address. If you cannot explain which route is private and what authenticates it, leave remote access disabled.

Pair known senders and restrict groups

For direct messages, keep pairing or an explicit allowlist. A pairing request gives the owner a chance to recognize a new sender before the agent acts on that person’s messages. For group chats, allow only rooms you chose. Add a mention requirement or sender allowlist when membership is broad or changes often.

OpenClaw’s security and access-control FAQ recommends pairing or allowlists for direct messages and restricting groups to selected rooms. A channel membership list is not necessarily the same as a permission boundary on the computer. Anyone allowed to operate a tool-enabled agent can steer it within the access you have granted.

If another person needs a different set of permissions, do not treat a private conversation or a session name as the access-control system. Give that person a separate Gateway or host. Our guide to sharing OpenClaw with a small team explains how to decide where that boundary belongs.

Narrow the agent’s tools before adding channels

Start with the smallest tool set needed for one task. If an agent reads messages, documents, or web pages from other people, be deliberate about shell execution, browser control, file access, and scheduled jobs. OpenClaw’s security FAQ recommends denying or tightly scoping high-risk tools for agents that handle untrusted input, and enabling sandboxing where tool execution needs a narrower boundary.

Test a low-risk request first. Confirm what files the agent can read, whether it can run commands, and whether a reply can trigger an action outside the chat. A message that says “run this command” is still external input. Tool permissions should be set by the host operator, not inferred from the wording of a message.

Audit after every access change

Run openclaw security audit after connecting a channel, changing a bind address, enabling a tool, or changing authentication. Read the findings and fix the ones that apply to your deployment. The command is a check, not a guarantee that a configuration is safe for every household or threat model.

Then verify the actual state: confirm the Gateway bind, check the allowed senders and rooms, and try a request from an account that should not be authorized. Keep a short note of the intended access boundary so a future update does not quietly widen it.

If your assistant needs to run around the clock, compare the computer’s workload before purchasing a new one. Our guide to choosing a Mini PC for OpenClaw separates the Gateway’s needs from local model inference. For a different home-network issue, see how to fix a renter’s Wi-Fi dead zone.