OpenClaw Security: A Practical Hardening Checklist

0. Run the audit before you change anything

openclaw --version
openclaw security audit
openclaw security audit --deep   # also probes the live gateway
openclaw sandbox explain

Record the version and the findings. --fix exists, but it only flips open group policies to allowlists and tightens file permissions; everything else on this page is a decision you make yourself. Audit output can contain paths and environment details, so redact it before sharing.

1. Decide what one gateway is allowed to serve

Upstream is explicit: one gateway is one trust boundary, meant for a single operator or a team that trusts each other. Several sessions, groups or agents inside it are not isolation between strangers. If two groups should never see each other’s files, keys or tools, give them separate gateways and credentials. No system prompt substitutes for that.

Hermes Agent: the same logic holds. One Hermes home (~/.hermes) holds one set of secrets; split untrusted users into separate installs with their own keys.

2. Keep the gateway off the open internet

gateway.bind defaults to "loopback". "lan", "tailnet" and "custom" widen the surface and need gateway auth plus a real firewall. Never run it unauthenticated on 0.0.0.0.

• Prefer Tailscale Serve or an SSH tunnel for remote access (see OpenClaw with Tailscale).
• Behind nginx or Caddy, set gateway.trustedProxies narrowly and make the proxy overwrite X-Forwarded-For.
• On Docker, published ports bypass host INPUT rules; filter them in the DOCKER-USER chain, not only in ufw.
• Search your config for keys starting with dangerously. Each one is a deliberate downgrade and should have a written reason.

Hermes Agent: the messaging gateway runs via hermes gateway; give any API server or dashboard you enable the same loopback-first treatment and tunnel in.

3. Control who can give the agent instructions

On Telegram, keep channels.telegram.dmPolicy on "pairing", never "open": Telegram bots are searchable, so an open bot is a public endpoint on your model bill. Approve senders with openclaw pairing approve telegram <code>. Discord bots are invite-only, so "open" with allowFrom: ["*"] is reasonable there. Group access is a separate check: an allowed group does not mean every member should get the same tools.

Hermes Agent: authorization is deny-by-default. Use platform allowlists such as TELEGRAM_ALLOWED_USERS in ~/.hermes/.env, or pairing codes approved with hermes pairing approve telegram <code>. Treat GATEWAY_ALLOW_ALL_USERS=true the way you would treat an open DM policy.

4. Restrict tools, then sandbox what remains

Tool policy is evaluated first: a tool denied globally or per agent stays denied whatever the sandbox says. Allow only what each agent needs, and treat exec, browser and web_fetch as the high-risk set. tools.elevated runs exec outside the sandbox; to hard-disable exec, deny it in tool policy.

Sandboxing is not on until you configure it. A minimal starting point from upstream:

{
  agents: {
    defaults: {
      sandbox: { mode: "non-main", scope: "session", workspaceAccess: "none" }
    }
  }
}

Verify the effective result with openclaw sandbox explain instead of assuming. Exec approvals guard operator intent; they are not a boundary against a hostile user. Content the agent reads (web pages, email, repo docs) can carry injected instructions, so the real defence is what the tools can reach, not the model’s judgement.

Hermes Agent: set approvals.mode to smart or manual rather than off, keep cron_mode and unattended_mode on deny, and add approvals.deny patterns for commands you never want run. For containment, set terminal.backend: docker (or ssh to a separate machine). Inside a container backend Hermes skips dangerous-command prompts because the container is the boundary, so its mounts and credentials matter most.

5. Scope and store secrets properly

• Use a separate, revocable, spend-capped model key per agent, so one leak costs one key.
• Never paste keys into skills, screenshots or shared configs. Backups contain secrets too.
• A browser profile logged into your accounts is a credential. Do not hand it to untrusted tasks.
• After a suspected leak, revoke at the provider. Deleting the chat message does nothing.

Hermes Agent keeps secrets in ~/.hermes/.env, and its file tools refuse to read .env files. That helps, but it is not a reason to give the agent broader keys.

6. Treat plugins and skills as code you run

Plugins run in the agent’s process with its credentials. Check the maintainer, source, pinned version, required env vars and outbound hosts before enabling, and pin versions so an upstream push cannot change what you run. Install count is not a safety signal; the exploits page has the numbers. See installing skills safely.

Hermes Agent: review with hermes plugins list and hermes plugins capabilities, pin Git installs to a commit, and grant message-injection capability only to plugins you control. Details in Hermes Agent plugins.

7. Stay current, and re-audit after changes

Several past OpenClaw incidents were closed by a version bump, so an old pinned build keeps old bugs (see how to update OpenClaw). Re-run the audit after every upgrade and every config change that widens access.

The checklist in one table

On OpenClaw Launch, each managed instance runs in its own container with an authenticated HTTPS gateway, which covers most of steps 1 and 2. Who you pair, which skills you install and which keys you connect remain your decisions.

OpenClaw security FAQ

Related security guides

• OpenClaw security exploits
• OpenClaw best practices
• OpenClaw Telegram pairing
• Hermes Agent plugins