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.

Each new browser needs a one-time approval. A service created from the current catalog template runs OpenClaw 2026.9.8, which always uses device pairing for its Control UI. You approve the browser from the panel; no terminal is needed. The first time a browser opens the service:

Open the service's address and enter the gateway password from the service's Credentials card.
OpenClaw shows Approve this browser with a request ID. Leave that page open.
In the panel, open the service's page. The card Browsers waiting for approval lists the request; press Refresh if it is not there yet. Check that the request ID is the one your browser shows, then press Approve and confirm.
Go back to OpenClaw. The page connects on its own; reload it if it does not. That browser profile is remembered; another browser, or the same one after clearing its data, needs a new approval.

Who can approve:

Operators and resellers with the services.manage permission, for services of their own customers. This is the permission that also shows the gateway password. A read-only member does not see the card.
Customers on the portal's service page, for their own services, when their plan includes Restart service. Approving a browser gives it full access to the agent, so it needs the plan right for changing a service, not a view right: a customer who may only view status, addresses, logs or metrics gets no card. A suspended customer cannot list or approve, also not with an API key; for a suspended customer only the platform operator can approve.

What to know before approving:

Only approve a request ID you can see in your own browser. A request appears only after that browser entered the correct gateway password, and an approved browser has full access to this OpenClaw. The request ID is what to decide by. The card also shows an address and a device type "as reported": the address is what the reverse proxy passed on, the device type is what the browser says about itself. Neither proves who is asking.
The card lists requests that identify themselves as Control UI browsers. Other OpenClaw clients (for example a paired node) still use OpenClaw's own tools. A client names itself, so anyone who knows the gateway password could make a request look like a browser; nobody without the password can create one.
The card does not refresh by itself. Each refresh starts a short-lived process inside the service's container, so it loads when you open the page and when you press Refresh.
Every approve the panel sends to OpenClaw is written to the audit log with who approved which request ID on which service: service.openclaw.browser_approved when OpenClaw confirmed it, and service.openclaw.browser_approve_unconfirmed with the outcome failed or unknown when OpenClaw refused it or did not answer within 20 seconds. After an unknown, press Refresh: if the request is gone from the list, the browser was approved.
The card appears while the service is running.

Fallback with a terminal on the host, if the panel cannot be used: docker exec <container> node dist/index.js devices approve <request-id>. Find the container with docker ps --filter label=aiadminpanel.service_id=<service-id>.

Memory. The template asks for at least 2 CPU cores and 3 GB of memory, and a host with less than that cannot deploy it. With a browser connected, OpenClaw 2026.9.8 uses about 1.1 GB at rest and close to 2 GB during a chat turn; with 1 GB it is stopped by the kernel as soon as a browser connects, and 2 GB leaves almost no room. When you choose the service's resources at deploy time, give it 3 GB or more.

Templates up to v2.12.9 set gateway.controlUi.dangerouslyDisableDeviceAuth to true so that the password alone was enough. OpenClaw retired that option: 2026.9.7 ignores it, and the current template no longer sets it. A panel update does not rewrite an existing service's saved Compose definition, so a service created earlier keeps the startup command and OpenClaw version it was created with. On OpenClaw 2026.6.5 that older command still disables device pairing; do not treat such a service as having device-pairing protection.

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	Left on (OpenClaw 2026.9.8 default); the template no longer sets the retired `dangerouslyDisableDeviceAuth`	Each new browser needs the one-time approval described above, given from the service's page
Forwarded client address	`gateway.trustedProxies` is set at every start to the address of the panel's Traefik container alone (`/32`), not to the network it is on	OpenClaw 2026.9.7 refuses proxied requests from an untrusted source with `403 proxy_attribution_required`. Trust affects which address is recorded as the client, not who may sign in. If Traefik gets a new address (for example after its container was recreated), the service's page answers 403 until you press Restart on the service
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.8` 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 browser approval step above before sharing the service.

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 — retired upstream and ignored by OpenClaw 2026.9.7. The current template does not set it. A service created from a template up to v2.12.9 still sets it at every start.
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.