Tom Hundley
🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4
The safest way to run OpenClaw remotely is to avoid exposing it to the public internet at all. Keep the gateway bound to 127.0.0.1, access it through a VPN, SSH tunnel, or authenticated tunnel, and treat any public URL as a last resort that requires TLS, authentication, and restrictive firewall rules. For most users, that is the right answer.
That caution is not theoretical. In May 2026, multiple outlets reported on research from security firm RedAccess about publicly accessible apps built with AI-assisted app builders. The exact counts varied by report and should be treated carefully unless verified against the original research, but the broader lesson is sound: internet-exposed apps are routinely discovered, indexed, and tested for weak or missing authentication. If an AI agent is reachable from a browser, it should be assumed reachable by scanners and opportunistic attackers too.
TL;DR: An exposed agent is more dangerous than an exposed brochure site because it may hold credentials and perform actions, not just display content.
A static website that gets indexed by a scanner is a problem. An exposed AI agent can be much worse. The difference comes down to two properties many agent systems have:
That combination changes the risk profile. Exposure is not just about reading data; it can become a path to using the agent's permissions and connected systems.
This is why reports about exposed AI-built apps matter beyond their immediate context. Even when the original examples are simple CRUD apps, the same exposure pattern becomes more serious when applied to an agent runtime with secrets and tool access.
The defensive principle is straightforward: reduce exposure at the network layer first, then add authentication, encryption, and runtime isolation on top.
TL;DR: If the gateway listens only on 127.0.0.1, remote systems cannot connect to it directly.
If OpenClaw's gateway is bound to localhost, the service accepts connections only from the same machine. A scan against your public IP should not see the gateway port at all. That is the safest default and the baseline every other option should preserve.
Verify the bind address in your gateway configuration:
## gateway config (illustrative)
host: "127.0.0.1"
port: 3000If the host is set to 0.0.0.0, the service listens on all network interfaces. On a cloud VM or a home network with port forwarding enabled, that can make the gateway reachable from outside the machine. Unless there is a specific reason to do otherwise, change it back to 127.0.0.1.
One caveat: localhost binding protects only the service itself. It does not override a reverse proxy, tunnel, container port publish rule, or SSH forward that intentionally exposes the service through another path. Check the full network path, not just the app config.
TL;DR: The safest remote-access pattern is to keep the gateway private and connect through an encrypted, authenticated path.
The cleanest way to reach a localhost-bound service from another machine is to use a private access layer rather than opening a public port.
| Approach | Examples | Tradeoff |
|---|---|---|
| Mesh VPN | Tailscale, ZeroTier, self-managed WireGuard | Keeps the service off the public internet; may add operational overhead or a third-party dependency |
| SSH local tunnel | ssh -L 3000:localhost:3000 your-server |
No extra exposure; requires SSH access and is usually session-based |
| Authenticated tunnel service | Cloudflare Tunnel, ngrok with access controls | Works behind NAT and restrictive firewalls; traffic traverses a third-party service |
All three approaches can preserve localhost binding on the host running OpenClaw. That is the key advantage over simple router port forwarding.
Port forwarding is convenient, but it is also how private services become public services. Once a port is reachable on a public IP, it may be discovered by internet-wide scanners such as Shodan or Censys. Discovery timing varies, so claims like "within hours" are directionally plausible but not guaranteed. The practical point remains: if a port is open to the internet, it should be treated as publicly discoverable.
For an agent that may hold credentials or invoke tools, relying on the app alone to defend that public edge is usually the wrong design.
TL;DR: If public exposure is unavoidable, terminate TLS and enforce authentication at a reverse proxy, not at the raw gateway port.
Some deployments genuinely need a public URL: webhook receivers, shared internal tools, or integrations that cannot route through a VPN. In those cases, expose only a hardened reverse proxy and keep the gateway itself bound to 127.0.0.1.
Here is an illustrative Caddy configuration:
agent.yourdomain.com {
basicauth * {
your_username $2a$14$HASHED_PASSWORD_HERE
}
reverse_proxy 127.0.0.1:3000
}And an equivalent nginx example:
server {
listen 443 ssl http2;
server_name agent.yourdomain.com;
ssl_certificate /etc/letsencrypt/live/agent.yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/agent.yourdomain.com/privkey.pem;
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}A reverse proxy adds several controls the gateway may not provide or may not provide robustly:
Basic auth is acceptable for a small, low-risk setup if paired with HTTPS and a strong unique password, but stronger options such as SSO, OAuth2 Proxy, mutual TLS, or identity-aware access controls are preferable for team use.
TL;DR: Firewalls do not replace authentication, but they reduce who can even attempt to connect.
A firewall is the next layer down. If the reverse proxy is listening on 443, the firewall should allow only the narrowest practical source range.
## UFW example: allow HTTPS only from a specific IP
sudo ufw default deny incoming
sudo ufw allow from 203.0.113.50 to any port 443 proto tcp
sudo ufw enableOn cloud infrastructure, the same principle applies through security groups, network ACLs, or equivalent controls. Start with default deny, then add explicit allow rules.
The strongest posture usually looks like this:
127.0.0.1Each layer limits the damage if another layer is misconfigured.
Sometimes, but it is usually not the best first line of defense for an internet-facing service. A mature reverse proxy is designed for TLS termination, header handling, logging, and access control. Even if the application has authentication, the proxy still provides a stronger perimeter.
Often yes for personal or small-team remote access, provided the service stays off the public internet. A host firewall is still worth keeping because it limits exposure if another device on the private network is compromised.
They can be, but only when their authentication and access policies are enabled. An unauthenticated tunnel still creates an externally reachable path. The security benefit comes from the identity layer and the lack of open inbound ports, not from the tunnel brand itself.
Test from a device that is not on the same LAN or VPN, such as a phone on cellular data or an external VPS. Check whether the public IP responds on the expected ports. External scanning should be done only against systems you own or are authorized to test.
If every path is inside the VPN, transport encryption is already present. Even so, TLS may still be useful for consistency, certificate-based auth, or future-proofing. If any path is public, TLS is mandatory.
The line between "I can reach it from anywhere" and "anyone can reach it" is usually a small configuration mistake: a 0.0.0.0 bind, a forgotten port-forward rule, an unauthenticated tunnel, or an overly broad security-group rule.
For AI agents, that mistake carries more risk than it does for a static site because the system may hold secrets and perform actions. The safest pattern is simple: keep the gateway private by default, add remote access through authenticated private channels, and treat any public exposure as an exception that needs deliberate hardening.
Discover more content: