OpenClaw Security — How Not to Get Pwned (and Still Ship)

Identity first, scope next, model last.

OpenClaw is both a product and an experiment: we’re wiring frontier-model behavior into real messaging surfaces and real tools. That’s exciting—and it also means you need to be deliberate about security from day one, because an assistant that can read files, run shell commands, browse the web, and message people is not a toy.

There is no “perfectly secure” setup. The goal is to build a system that is safe-by-default, transparent to audit, and hardened enough for the level of access you choose to grant.

The threat model (what can go wrong)

OpenClaw can: execute commands, read/write files, access network services, drive a browser, and send messages—depending on what you enable.

Most failures are not sophisticated exploits; they’re simple: “someone messaged the bot, and the bot did what they asked,” or “the bot read untrusted content and followed instructions it shouldn’t have.”

This is why OpenClaw’s security posture is built around hard controls—pairing, allowlists, sandboxing, tool policies—not around hoping the model will always behave.

Core principle: Access control before intelligence

If you remember one thing, make it this order of operations: Identity first, scope next, model last.

Identity answers “who can talk to the bot” (DM pairing, allowlists, group policies), scope answers “where the bot may act and what it may touch” (tools, sandboxing, filesystem), and model choice is the final layer—important, but never the only defense.

Assume the model can be manipulated; design your configuration so manipulation has a limited blast radius.

Run the audit (your default habit)

OpenClaw ships a security audit command that flags common footguns: gateway auth exposure, browser control exposure, elevated allowlists, and filesystem permissions.

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

Run it regularly, especially after changing config or exposing a new network surface. The --fix mode tightens risky settings (for example changing open group policies to allowlist), restores sensitive redaction defaults, and tightens local permissions for config/credential/session files.

Lock down inbound surfaces (DMs + groups)

OpenClaw supports DM policies that gate inbound DMs before a message is processed: pairing (default), allowlist, open (explicit opt-in), or disabled.

Pairing is the safest default for a personal assistant: unknown senders receive a pairing code and the bot ignores them until you approve the code using openclaw pairing approve <channel> <code>.

For group chats, treat “always-on in a room” as dangerous; require mentions, use group allowlists, and keep “open” group policies as a last resort.

Gateway exposure: keep it private by default

The gateway multiplexes HTTP + WebSocket on a single port (default 18789), and the safest configuration is binding to loopback so only local clients can connect.

If you expand the bind surface (LAN, tailnet, custom), you’re expanding the attack surface—use strong auth (token/password) and a real firewall/allowlist.

Never expose the gateway unauthenticated on 0.0.0.0; that’s the fastest route to a bad day.

If you put the gateway behind a reverse proxy, configure gateway.trustedProxies so client IP detection is correct and proxy headers can’t be abused to bypass local trust checks.

If the gateway sees X-Forwarded-For or X-Real-IP from a proxy that is not trusted, it will not treat the connection as local—preventing authentication bypass scenarios.

Control UI security (device identity vs “break glass”)

The Control UI needs a secure context (HTTPS or localhost) to generate device identity.

You can allow insecure auth (gateway.controlUi.allowInsecureAuth) which falls back to token-only auth and skips device pairing when device identity is omitted, but that’s a downgrade—use it only when you understand the risk.

There is also a “break glass” option (gateway.controlUi.dangerouslyDisableDeviceAuth) that disables device identity checks entirely; keep it off unless you’re actively debugging and can revert quickly.

Tools and sandboxing: control the blast radius

Tools are where value comes from—and also where risk lives. The dangerous combination is “open inbound access + powerful tools.”

Use sandboxing to keep tool execution inside a dedicated workspace (for example under ~/.openclaw/sandboxes) and limit access to your real files unless needed.

At the agent level, set different access profiles: a personal agent might have broader access, while a family/work/public agent should be sandboxed and restricted to a minimal tool allowlist.

Browser control deserves special attention

If the agent can drive a browser profile that’s already logged into accounts, it can access those accounts.

Use a dedicated agent browser profile (not your daily driver), keep downloads isolated, and for remote gateways treat browser control like operator access—tailnet-only and intentionally paired.

Secrets and data hygiene (what lives on disk)

Assume anything under ~/.openclaw/ (or $OPENCLAW_STATE_DIR/) may contain secrets or private data: config, credentials, model auth profiles, plugins, sandbox workspaces, and session transcripts.

OpenClaw stores session transcripts on disk under ~/.openclaw/agents/<agentId>/sessions/*.jsonl, which enables continuity and memory workflows—but it also means anyone with filesystem access can read those logs.

Lock down permissions (directories 700, files 600), use full-disk encryption on the gateway host, and consider separate OS users or separate hosts for strong isolation between agents.