OpenClaw is more sensitive than a typical web application because it can connect messaging accounts, store credentials, call external services, browse the web, read files, and execute tools. A successful compromise may therefore expose more than the OpenClaw dashboard—it could give an attacker access to every system the agent can reach.

The safest approach is to treat the OpenClaw Gateway as a privileged control plane. Keep it private, authenticate every access path, restrict who can send instructions, isolate tool execution, and grant each agent only the permissions required for its job.

This tutorial explains how to secure a self-hosted OpenClaw deployment using multiple layers of protection.

1. Start With a Minimal, Dedicated Host

Run OpenClaw on a dedicated virtual machine, physical server, or operating-system account. Do not place it beside unrelated applications unless you have a clear isolation plan.

Avoid running the Gateway as root. A separate service account limits the damage caused by a compromised process, plugin, or tool.

On Ubuntu, create a dedicated account:

sudo adduser --disabled-password --gecos "" openclaw
sudo chmod 750 /home/openclaw
sudo -iu openclaw

Install only the packages required by the deployment. Remove unused services and apply operating-system updates:

sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y

Use official OpenClaw release packages or container images. Pin an exact production version instead of relying permanently on a moving tag such as latest. Exact versions make testing, rollback, and incident analysis easier.

2. Keep the Gateway on Loopback

Keep the Gateway private whenever possible.

OpenClaw uses port 18789 by default, and loopback is the recommended binding for local deployments. Loopback allows connections from the same host without exposing the Gateway on a public network interface. OpenClaw’s remote-access guidance identifies loopback with SSH or Tailscale Serve as the safest default.

Use this baseline in ~/.openclaw/openclaw.json:

{
gateway: {
mode: "local",
bind: "loopback",
port: 18789,
auth: {
mode: "token",
token: "${OPENCLAW_GATEWAY_TOKEN}"
}
}
}

Verify the listening address:

ss -ltnp | grep 18789

The result should show 127.0.0.1:18789 or [::1]:18789. It should not show 0.0.0.0:18789 or a public server address.

3. Require Strong Gateway Authentication

Generate a Gateway token through OpenClaw:

openclaw doctor --generate-gateway-token

You can also create a long random value with OpenSSL:

openssl rand -hex 32

Store the token in a protected environment file rather than entering it directly into openclaw.json:

install -m 600 /dev/null ~/.openclaw/.env
printf 'OPENCLAW_GATEWAY_TOKEN=%s\n' 'REPLACE_WITH_YOUR_RANDOM_TOKEN' >> ~/.openclaw/.env

Restrict access to OpenClaw’s state and configuration:

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/.env
chmod 600 ~/.openclaw/openclaw.json

Treat a shared Gateway token as operator-level access. Do not distribute it as though it were a limited end-user credential. OpenClaw documents token generation through openclaw doctor and requires a valid authentication path for non-loopback bindings.

4. Use a Safe Remote-Access Pattern

For personal administration, create an SSH tunnel:

ssh -L 18789:127.0.0.1:18789 admin@openclaw-server

Then open:

http://127.0.0.1:18789

Traffic travels through the SSH connection while the Gateway remains bound to loopback.

Tailscale Serve is another supported private-access option. Tailscale identity may protect the Control UI and WebSocket surface when configured correctly, but do not assume it replaces Gateway authentication for every HTTP API endpoint.

For organisational access, use an identity-aware proxy that:

  • Authenticates every user.
  • Removes untrusted identity headers.
  • Writes its own forwarding and identity headers.
  • Cannot be bypassed through another route.
  • Restricts access to approved users.

Do not enable trusted-proxy mode merely because a proxy terminates TLS. OpenClaw warns that trusted-proxy authentication is safe only when the proxy controls the identity boundary and is the only path to the Gateway.

Apply a host firewall policy:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw deny 18789/tcp
sudo ufw enable
sudo ufw status numbered

Docker users should also review published container ports and the DOCKER-USER chain. A published port may not behave as expected under ordinary host firewall assumptions.

5. Protect API Keys and Channel Credentials

API keys, bot tokens, OAuth credentials, webhook secrets, and model-provider credentials should not be committed to repositories, embedded in container images, copied into screenshots, or retained in shell history.

OpenClaw supports SecretRefs for supported credential fields. SecretRefs reduce plaintext storage, but they are not a process-isolation boundary. A secret remains exposed if it sits in a file the agent can read through shell or filesystem tools.

Start with an audit:

openclaw secrets audit --check

Migrate supported credentials:

openclaw secrets configure --apply

Then repeat the audit and reload the active secret snapshot:

openclaw secrets audit --check
openclaw secrets reload

Do not treat the migration as complete until the audit reports no unresolved references or plaintext residue. Use separate credentials for testing and production, apply provider spending limits where available, and revoke credentials that are no longer required.

6. Restrict Who Can Message the Agent

A private Gateway can still receive hostile instructions through a connected messaging channel.

Use pairing or an explicit allowlist for direct messages. Set session.dmScope to per-channel-peer when several people can message the same bot. This keeps each sender’s direct messages in a separate session.

For example:

{
session: {
dmScope: "per-channel-peer"
},

channels: {
whatsapp: {
dmPolicy: "pairing",
groupPolicy: "allowlist",
groupAllowFrom: ["+15555550123"],

groups: {
"REPLACE_WITH_APPROVED_GROUP_ID": {
requireMention: true
}
}
}
}
}

Replace the sender and group identifiers with approved values.

Do not confuse mention gating with access control. requireMention controls when the agent responds. The group policy, approved senders, and configured group identifiers determine who may trigger it and where.

7. Minimize Tools and Sandbox Execution

No. OpenClaw sandboxing is off by default.

When sandboxing is enabled without another backend, OpenClaw uses Docker. Its documented Docker defaults include no network access, a read-only root filesystem, and dropped Linux capabilities. The Gateway itself and native plugins remain outside the sandbox, so sandboxing does not isolate every part of the system.

Begin with a restrictive tool policy:

{
tools: {
profile: "messaging",

deny: [
"group:automation",
"group:runtime",
"group:fs",
"sessions_spawn",
"sessions_send"
],

fs: {
workspaceOnly: true
},

exec: {
security: "deny",
ask: "always"
},

elevated: {
enabled: false
}
}
}

When an agent needs shell, browser, or filesystem access, enable sandboxing:

{
agents: {
defaults: {
sandbox: {
mode: "all",
backend: "docker",
scope: "session",
workspaceAccess: "ro",

docker: {
readOnlyRoot: true,
network: "none",
capDrop: ["ALL"]
}
}
}
}
}

Do not mount high-risk host paths such as:

/var/run/docker.sock
~/.ssh
~/.aws
/root
/etc

Mounting the Docker socket can give a sandboxed process control over the Docker host.

8. Treat Plugins and Skills as Trusted Code

Plugins can register tools, access configuration, communicate over the network, and run inside the Gateway process. Enabling a plugin is closer to installing server software than adding passive content.

Prefer official catalog entries or established publishers, but do not treat catalog inclusion as proof of a full security review.

Before installation:

  • Review the source and dependencies.
  • Check requested tools and permissions.
  • Pin an exact version.
  • Use an explicit plugin allowlist where practical.
  • Remove extensions that are no longer required.

After any plugin or skill change, run:

openclaw security audit --deep

Deep auditing adds plugin and skill scans and attempts a live Gateway probe, but it does not replace manual code review.

9. Audit, Monitor, Back Up, and Update

Run these checks after changes to networking, authentication, channels, plugins, tools, or proxies:

openclaw config validate
openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw status --deep

OpenClaw also provides limited automatic remediation:

openclaw security audit --fix

Review every resulting change. Automatic fixes can tighten selected permissions and policies, but they do not replace a manual security review.

Create a verified backup before upgrades or major configuration changes:

mkdir -p ~/Backups/openclaw
openclaw backup create --output ~/Backups/openclaw --verify

The –verify option validates the archive after it is written. Treat the backup as sensitive because OpenClaw state may include conversations, credentials, tool output, sessions, and authentication data. Store it in encrypted storage with restricted access.

10. What Should You Do After a Suspected Compromise?

Act quickly:

  1. Stop the Gateway and remove public or remote exposure.
  2. Rotate the Gateway token, model keys, bot tokens, OAuth credentials, and webhook secrets.
  3. Disable affected channels, plugins, skills, and scheduled tasks.
  4. Review logs, sessions, configuration changes, and installed extensions.
  5. Restore from a known-good verified backup when system integrity is uncertain.
  6. Run openclaw security audit –deep before reconnecting channels.

Do not assume that changing one password removes every persistence path. A malicious plugin, exposed API credential, modified scheduled task, or altered configuration may survive a partial cleanup.

Conclusion

Securing OpenClaw requires several independent controls. Keep the Gateway private, authenticate every access path, restrict messaging users, deny unnecessary tools, and isolate risky execution. Protect credentials at rest, treat plugins as trusted code, and separate users who do not share the same trust boundary.

Security also requires verification. Confirm the listening address, inspect firewall rules, audit secrets, test backups, and rerun deep security checks after every material change. A secure deployment is not defined by one token or firewall rule. It is defined by limited access, limited permissions, tested recovery, and regular review.

Frequently Asked Questions

1. Is OpenClaw safe to self-host?

It can be operated securely when the Gateway is private, authentication is enabled, tools are restricted, and credentials are protected. Its ability to execute tools makes careless configurations high risk.

2. Should port 18789 be publicly accessible?

No, not under the recommended baseline. Keep it on loopback and use an SSH tunnel, private network, or correctly configured identity-aware proxy.

3. Is OpenClaw sandboxing automatic?

No. Sandboxing is disabled by default and must be enabled in the agent configuration.

4. Can several users share one Gateway?

Trusted users can share a Gateway, but mutually untrusted users should use separate instances. Session separation is not full tenant isolation.

5. How often should security audits run?

Run an audit after every exposure, channel, plugin, tool, proxy, or authentication change. Schedule additional recurring audits for production systems.