OpenClaw sandboxing and exec approvals: what your agent can touch
By default: no sandbox, no prompts, full shell. The three real walls — tool policy, exec approvals, and the Docker sandbox — and which layer stops what.
Out of the box: no sandbox, no approval prompts. OpenClaw’s default is a trusted-single-operator setup where exec runs shell commands on the host directly. When you want walls, there are three real ones — tool policy (deny a tool outright), exec approvals (allowlist + ask-before-run), and an opt-in Docker sandbox with no network and a read-only root. Knowing which layer does what is most of the job.
The default, stated plainly
OpenClaw’s security docs open with the sentence most vendors would bury: your AI assistant can execute arbitrary shell commands, read and write files, reach the network, and message people. The default exec posture is security: "full" with ask: "off" — no approval prompts — because the design assumes one trusted operator talking to their own agent on their own machine. The docs’ other memorable line explains where that goes wrong: most failures aren’t exotic exploits, they’re “someone messaged the bot and the bot did what they asked.” The layers below exist for exactly that day.
Layer 1: tool policy — the hard stop
Every tool survives an allow/deny check before the model ever sees it. tools.deny removes a tool or whole groups (tools.deny: ["group:runtime", "exec"]), and deny always wins — the docs are explicit that nothing downstream, not even the elevated escape hatch, can override a denied tool. One nuance worth writing on your hand: disabling the file tools does not make exec read-only — a shell is a shell. If you don’t want the agent touching files, exec has to go too.
Layer 2: exec approvals — allowlist plus ask
Between “blocked” and “anything goes” sits the approval system. tools.exec.security has five settings — deny, allowlist (only pre-approved commands run), ask, auto, and full — and tools.exec.ask decides when you get prompted: always, on-miss (only for commands the allowlist doesn’t cover), or off. Pending commands land as approval requests in the Control UI, where you approve or reject them. Allowlists are per agent, and there’s a sharp edge the docs call out themselves: if you allowlist an interpreter like python or node, enable tools.exec.strictInlineEval — otherwise python -c "..." rides in on the interpreter’s approval and runs arbitrary code anyway.
Layer 3: the sandbox — real isolation, honestly scoped
Sandboxing (off by default) moves tool execution into a container while the Gateway stays on the host. Turn it on with agents.defaults.sandbox.mode — "all" for everything, or "non-main" to sandbox only sessions beyond your own main one (a nice fit for agents that also talk to a group). The Docker defaults are genuinely strict: no network egress, read-only root filesystem, all capabilities dropped, and the agent’s real workspace invisible unless you mount it (workspaceAccess: "ro" or "rw"). The docs’ own honesty is worth quoting rather than improving: it’s “not a perfect security boundary,” but it materially limits what a bad turn can touch. Two things stay outside it by design: the Gateway process itself, and anything you route through the gated /elevated escape hatch.
What this buys you against prompt injection
OpenClaw’s docs say directly that prompt injection is not solved by system-prompt guardrails — soft guidance loses to a sufficiently clever web page, email, or pasted log. Hard enforcement comes from the layers above plus pairing and channel allowlists on who can talk to the agent at all. Two more official recommendations complete the picture: cheaper models are measurably more susceptible to instruction hijacking (use a strong model on any agent that runs tools), and the outermost wall is architectural — run the agent on a machine that isn’t your daily driver, so that even a fully-hijacked turn is spending someone else’s blast radius. Once you’ve chosen your layers, the built-in security audit will tell you how the running config actually landed.