OpenClaw sandboxing, tool policy and elevated

Three different controls decide what an OpenClaw agent can do, and most of the confusing refusals come from mixing them up. The sandbox decides where tools run. Tool policy decides which tools exist and may be called. Elevated is an escape hatch for one tool, exec, out of the sandbox. Here is each one, the mental model the docs give for why something is blocked, and what changes on a managed host.

The sandbox: where tools run

Sandboxing is off by default. Set to non-main, only sessions other than the main one are sandboxed, which is the common surprise for groups and channels; set to all, everything is. Workspace access is none, read-only or read-write, independent of anything you mount. The default backend is Docker, with Podman, SSH, OpenShell and a leased cloud box as alternatives, and a sandboxed browser is available.

This is not a perfect security boundary, but it materially limits filesystem and process access when the model does something dumb.

Tool policy: which tools exist

• A tool profile is the base allowlist; a fresh local setup defaults to the coding profile.
• Global and per-agent allow and deny lists, per-provider variants, and a sandbox-only policy that applies when a session is sandboxed.
• Deny always wins. A non-empty allow list blocks everything else. Tool policy is the hard stop: a chat directive cannot override a denied tool.
• Policy filters by name, not by effect: if exec is allowed, denying write does not make shell commands read-only.

Tool groups are the shorthand: runtime for exec and process, fs for read, write, edit and patch, then sessions, memory, web, ui, automation and messaging. The Gateway logs an audit entry whenever a policy step removes a tool or a sandbox policy blocks a call, with the rule and the config key that did it.

Elevated: the exec escape hatch

Elevated runs exec outside the sandbox, on the Gateway host by default or on a node when that is the target. It is explicit and gated, it only changes session defaults for authorised senders, and it grants no tool that policy denies. An operator role that requires a sandbox cannot be escaped through it at all, and fails closed if the sandbox cannot be provisioned.

Two things the docs warn about

• Bind mounts pierce the sandbox: whatever you mount is visible inside with the mode you set, read-write if you omit it, so prefer read-only for source and secrets. Mounting the Docker socket hands host control to the sandbox.
• Third-party skills are untrusted code that runs with whatever the agent can run; sandboxing narrows the blast radius, tool policy narrows the tools, and neither reads the skill for you.

The inspector command prints the effective mode, scope, workspace access, tool policy and the config keys to change, which is the fastest answer to why is this blocked. How OpenClaw skills work covers the skill side of the same question.

On Diali

On Diali every assistant already runs in its own kernel-level sandbox with no public ports and outbound access to the public web only, never to our internal network, the cloud metadata server or other tenants, so the where question is answered before OpenClaw’s own sandbox is configured. Tool policy and elevated remain yours, because they decide what the assistant may do rather than where it does it. Security on Diali describes the isolation; Hosted OpenClaw on Diali the assistant.

• Sandbox is where; policy is what; elevated is the exception.
• Deny wins, allow lists exclude, names not effects.
• Read the audit line in the logs before changing a key.