OpenClaw security hardening guide

OpenClaw is a powerful AI-agent platform. It can execute tools, browse the web, process untrusted input, and connect to messaging channels. Your deployment on AI Admin Panel ships with a set of hardening defaults applied at the infrastructure layer; additional policies inside OpenClaw itself are your call.

The v2.12.8 template disables Control UI device authentication. Its startup command sets gateway.controlUi.dangerouslyDisableDeviceAuth to true before starting the gateway. Password authentication remains enabled with a generated gateway password and configured allowed origins, but these controls do not restore device pairing. Do not treat this deployment as having device-pairing protection. Arrange a security review before exposing it to untrusted users.

This is a shipped template setting, not a recommendation to disable device authentication. The startup command reapplies it when the container starts, so changing the setting only inside OpenClaw is not a durable correction. A panel update also does not rewrite an existing service's saved Compose definition. Review that definition and the running configuration with your administrator; this guide does not certify an existing deployment as secure.

Use this guide alongside the upstream security documentation for your deployed OpenClaw version. The settings below require review against that version.

What the panel applies automatically

The catalog template configures the following defaults. Its authentication commands run at container startup:

Layer	Applied default	Why it matters
Reverse proxy	The template declares `expose: 18789`, without a published host port; the panel adds Traefik routing	Check the service's HTTPS endpoint before sharing it
TLS	Traefik requests a certificate for the service hostname	Issuance depends on DNS and the installation's TLS configuration
Auth mode	`gateway.auth.mode: "password"` with a panel-generated random password	Protect the gateway password as an access credential
Control UI device authentication	Disabled by the template with `dangerouslyDisableDeviceAuth: true`	Device-pairing protection must not be assumed; see the warning above
Password surfacing	Shown in the service's Credentials card in our UI	You never have to SSH into the container to find it
Container capabilities	Kernel caps `NET_RAW` and `NET_ADMIN` dropped	Reduces access to raw sockets and network administration
Process isolation	`no-new-privileges: true`	Restricts privilege elevation through executed programs
Network scope	Customer or service network, with shared proxy and AI networks used by the deploy worker	Separate services are not proof of hostile-tenant network isolation
Healthcheck	Every 30 seconds on `/healthz`, with `restart: unless-stopped`	A healthcheck reports health; it does not itself restart an unhealthy process
Image version	`ghcr.io/openclaw/openclaw:${VERSION}`, default `2026.9.7` in this catalog	Review the selected version; redeploying a pinned tag does not select a newer release

These describe the shipped template and deploy path, not a live inspection of your service. Review the authentication exception above before relying on the defaults.

What you own inside OpenClaw

The following knobs live inside OpenClaw's own configuration and cannot be enforced from the template layer. Review them after your first successful deploy.

1. Who can message your agent (DM policies)

dmPolicy controls what happens when an unknown sender tries to DM your bot over WhatsApp / Telegram / Slack / Discord.

pairing (default) — unknown senders get a temporary pairing code; you approve in the OpenClaw UI. Recommended for production.
allowlist — only pre-approved senders can DM. Strictest.
open — anyone can DM. Avoid unless you understand the prompt-injection surface.
disabled — ignores all inbound DMs.

Change it in the OpenClaw UI under Settings → Channels → DM Policy.

2. Tool sandboxing

OpenClaw can execute tools (shell, filesystem, network, browser). Verify its tool sandbox configuration for your deployed version; the panel's container hardening does not establish that each tool runs in a separate sandbox.

sandbox.mode: "all" — strongest; all tools run in the sandbox.
sandbox.scope: "agent" (default) — one sandbox per agent; use "session" for stricter per-session isolation.
sandbox.workspaceAccess: "none" — no agent access to the workspace filesystem. Use "ro" for read-only if your agent needs to read files.
tools.elevated.enabled: false — keep this off unless a workflow specifically requires privileged execution; it bypasses the sandbox.

3. Which tools are allowed

Deny-by-default is the recommended posture:

tools.deny: ["group:automation", "group:runtime", "group:fs",
             "sessions_spawn", "sessions_send"]
tools.exec.security: "deny"          # block shell execution
tools.exec.ask: "always"             # require approval per command
tools.fs.workspaceOnly: true         # filesystem tools limited to workspace

For agents reachable by untrusted senders, additionally deny cron, gateway, and browser.

4. Audit logging

Turn on session and action logging so you can review what the agent did, when, and who triggered it. OpenClaw logs to /tmp/openclaw/openclaw-YYYY-MM-DD.log inside the container; you can read it from our Logs tab or via docker logs on the host.

5. Block dangerous inbound content

Treat external content (links in DMs, attachments, pasted instructions) as untrusted. Review upstream content-handling and authentication settings, including:

gateway.controlUi.allowInsecureAuth — never true in production.
gateway.controlUi.dangerouslyDisableDeviceAuth — the v2.12.8 template sets this to true; an in-app change alone is overwritten on container startup. Review a durable correction with your administrator before relying on device pairing.
hooks.gmail.allowUnsafeExternalContent — never true.

Run OpenClaw's own audit periodically

OpenClaw ships with a built-in audit command that scores your configuration and flags drift:

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix

You can run this inside the container via our Terminal tab on the service page. --fix applies upstream-recommended hardening automatically; we plan to surface this as a one-click button in a future release.

Trust model — important

OpenClaw assumes a personal-assistant deployment: one trusted operator per Gateway, many agents allowed within that boundary. It is not suitable for hostile multi-tenant isolation.

Use separate services for separate trusted teams. For adversarial users, obtain a review of host and network isolation as well as application authentication; separate panel services still use shared infrastructure.

Incident response

If an agent is compromised or misbehaves:

Stop the service from the service detail page.
Plan credential rotation with your administrator. The startup command also writes the gateway password into OpenClaw's configuration, so changing an environment variable alone is not proof that gateway authentication changed. Revoke affected provider keys at their issuer and verify the replacement credentials in the application before restoring access.
Review logs in the Logs tab for the time window of concern.
Restart and re-audit with openclaw security audit --deep once you've identified the root cause.