Why "Just Run OpenClaw in Docker" Isn't a Security Strategy

Every OpenClaw security discussion ends the same way. Someone asks how to secure their deployment, and the top answer is "run it in Docker." It gets upvoted, the asker feels reassured, and nobody digs into what that actually means.

Docker is a useful layer. It is not a security strategy. And the gap between what people think Docker does and what Docker actually does for an OpenClaw deployment is big enough to lose your credentials through.

What Docker actually does for you

When OpenClaw runs inside a container, it gets filesystem isolation (the container can't see your host filesystem unless you mount volumes), process isolation (a crash or rogue process inside the container doesn't directly affect the host), and a clean base environment (the container starts from a known image, not your messy home directory).

These are meaningful protections. If a malicious skill tries to read ~/.ssh/id_rsa or ~/Documents/client-contracts/, it hits the container boundary instead of your actual files. If a reverse shell opens inside the container, the attacker gets a stripped-down Linux environment, not your MacBook.

OpenClaw's own sandboxing features build on this — the sandbox.mode setting can run non-main sessions in Docker containers with no network and a read-only root filesystem. It's a solid option for isolating untrusted skills.

What Docker does not do

Here's where the "just use Docker" advice breaks down.

Docker doesn't protect the channels OpenClaw is connected to. If your agent is connected to your email, Slack, WhatsApp, or calendar — those connections go through the OpenClaw gateway, which operates outside the container sandbox. A compromised agent can still read your emails, send messages on your behalf, and access your calendar. The container boundary is irrelevant because the data flows through the gateway, not the filesystem.

Docker doesn't protect your API keys. OpenClaw needs API keys to function — at minimum an LLM provider key, plus keys for any integrations. These keys are passed to the container as environment variables or mounted config files. A malicious skill running inside the container has the same access to these keys as a legitimate skill. Container isolation doesn't help when you've explicitly given the container what it needs to steal.

Docker doesn't protect against prompt injection. If your agent processes external content — emails from unknown senders, web pages, documents from clients — that content can contain prompt injection attacks that manipulate the agent's behavior. This happens at the LLM layer, entirely inside the container, using permissions you've legitimately granted. Docker has no visibility into what the LLM decides to do.

Docker doesn't protect against social engineering via SKILL.md. The ClawHavoc campaign worked because users manually ran commands from a skill's documentation. Docker doesn't prevent you from copying a curl | bash command from a skill's README and running it on your host machine. The entire ClickFix attack chain operates outside the container.

Docker doesn't protect MCP server connections. MCP servers are external services that your agent connects to — GitHub, Google Workspace, Slack, databases. Those connections are established from within the container but reach real external services with real credentials. A compromised MCP server or a man-in-the-middle attack on an MCP connection is invisible to Docker.

Docker doesn't protect against CVE-2026-24763. This specific vulnerability was a sandbox command injection — an attacker could break out of Docker-based sandboxing in OpenClaw. Container escapes are a known category of vulnerability. Docker is not a security boundary that you should treat as unbreakable.

What people actually need

Docker should be part of your security setup, not the entirety of it. The layers that matter for an OpenClaw deployment:

Network configuration. Gateway bound to loopback, not 0.0.0.0. No ports exposed to the internet. If you need remote access, use SSH tunneling or a VPN, not a public-facing gateway.

Permission minimization. Each agent gets the minimum tools it needs. A research agent doesn't need exec. A writing agent doesn't need web access. Use per-agent tool allowlists and set dmPolicy to pairing so the agent can't accept unsolicited connections.

Exec control. Deny shell execution globally, enable it per-agent with an explicit allowlist of approved commands. Set ask: "on-miss" so the agent prompts you before running anything not on the list.

MCP auditing. Review every MCP server before connecting it. Pin versions. Limit tool permissions. Log all MCP calls. Block new servers by default.

Supply chain verification. Check installed skills against IOC databases. Verify that SKILL.md files don't contain suspicious "prerequisite" downloads. Hash your identity files and check for tampering after every skill install.

Identity monitoring. Baseline your ~/.openclaw/identity.json and agent configuration files. Detect changes on a schedule.

Docker handles one of these (it contributes to permission minimization). The other five require deliberate configuration that has nothing to do with containers.

The actually useful Docker setup

If you're going to use Docker — and you should — here's the setup that matters:

// In openclaw.json:
"sandbox": {
  "mode": "non-main",
  "network": false,
  "readOnlyRoot": true
}

This gives you container isolation for skill execution while keeping your primary session usable. It's one of 40 items in a full security audit, not a substitute for the other 39.

The OpenClaw documentation itself says it clearly: "There is no 'perfectly secure' setup." Docker is a tool. Use it. But don't stop there.