OpenClaw’s defaults are conservative for a single operator on a laptop. The trouble starts the moment you point it at a server, a shared machine, or a customer’s data — because two of the protections you would assume are on, are not. Sandboxing and exec approvals ship off by default, and that is the project saying so, not a critic.
The evidence is public and specific. Cisco’s AI security team tested a third-party OpenClaw skill and found it performing data exfiltration and prompt injection without the user’s awareness, noting the skill repository lacked the vetting to stop malicious submissions. Reviewing OpenClaw 2.0, The Register reported that the Secret Store is not encrypted at rest and the sandbox is not enabled by default, concluding the release “is not bringing security by default.” And OpenClaw’s own docs are blunt about the scope: default OpenClaw “is a trusted single-operator assistant,” and one gateway is one trust domain — not a boundary between people who do not trust each other.
OpenClaw ships its own audit. Start there — it reports what you have drifted from and, for some checks, offers an auto-fix.
openclaw security audit openclaw security audit --deep # schedule this, and alarm on the check IDs
Do not run mutually distrusting people on one gateway. For mixed-trust use, split the boundary: separate gateway, separate credentials, ideally separate OS users or hosts. This is a design constraint, not a config flag.
On a normal host install the Gateway binds to loopback. Container images are the exception — they default to an exposed bind, so pair that with auth. For remote access, front it with Tailscale or an identity-aware proxy rather than opening a port.
By default an unknown sender gets a pairing code instead of a processed message, and groups are allowlisted behind a mention gate. Keep that. “Open” DMs on a gateway that touches email and files is how strangers end up driving your agent.
This is the big one, because it is off by default and it is the layer that contains a compromised run:
agents.defaults.sandbox.mode: "all" agents.defaults.sandbox.workspaceAccess: "ro" # unless the agent owns the workspace
Run it on the openshell or docker backend. Sandboxed execution
defaults to no network (network: "none") or a default-deny policy.
Pick a permission mode per session — guarded or
workspace. full requires operator.admin; do not
hand it out casually. Give each agent the narrowest profile that still does its job.
Plain-text keys in a config or a workspace .env are exposed the moment the
host is. Reference secrets instead, and check them in CI:
openclaw secrets audit --check
The Cisco finding is the reason. ClawHub shows scan status, but a pending or stale scan can still let an install through — and native plugins run in-process, not in the sandbox. Pin versions, lock dependencies, allowlist what you install, and verify before adding:
openclaw skills verify
A real browser is a real attack surface. OpenClaw’s browser SSRF policy is strict by default — keep it, and keep the bypass flags off in production.
Turn on message auditing, export OpenTelemetry to your SIEM with operator-owned retention, schedule the deep audit, and treat security advisories as a standing feed. The project ships CVEs; you are the one who applies them.
The project publishes the order: contain (isolate the instance), rotate (assume any reachable secret is compromised), audit (read the logs and transcripts), then collect evidence before you wipe anything.
Claw Guide is published by the team behind Claw Way, a managed OpenClaw host. We disclose that on every page. This checklist is written for self-hosters and applies to any deployment; it deliberately does not describe how our own platform is built. · contact