OpenClaw security: check the policy your gateway uses

Start an OpenClaw security review by identifying who can reach the gateway, where tools execute and which commands need approval. At the pinned revision, the sandbox resolver falls back to off; the host exec approval constants are security=full, ask=off and askFallback=deny. The checks below connect those source values to the project's documented inspection commands so you can examine a configured installation. Sandbox resolver; Exec constants.

• Run openclaw security audit to inspect configuration risks identified by the project's own checks. Official security guidance.
• Use openclaw exec-policy show and the appropriate openclaw approvals get target to inspect effective command policy. Inspection commands.
• Check sandbox mode and backend together, then review workspace access and container settings. Resolved sandbox settings.
• Review diagnostics settings separately from model and tool connections. The exporter check appears below.

Define the OpenClaw security threat model

Identify the people who share the gateway's trust boundary before connecting accounts or opening network access. OpenClaw's official security guidance assumes a single trusted operator, or a team whose members trust each other. For mixed-trust or adversarial users, it advises separate gateways and credentials, ideally on separate OS users or hosts. A paired node extends the operator's execution capability to another machine. One trust boundary per gateway; Gateway and node trust.

The assets to account for are the files and credentials reachable by tools, connected accounts, stored conversations and the gateway/node hosts. The important inputs include messages, fetched pages, email, documents and attachments. Even a private bot can encounter malicious instructions through material it reads. The project's prompt-injection guidance recommends limiting tool reach, keeping secrets outside the agent's reachable filesystem and sandboxing sensitive execution. Untrusted content and enforcement layers.

This gives you a concrete review question: if a fetched document steers the model toward an unwanted command, which tool policy, approval or execution boundary stops it? Channel access controls answer who can speak to the bot; they do not remove hostile text inside an authorized user's research material. Apply the checks below to the agent handling that content. This page is a source review, with no exploit testing or deployed-system security score.

Run the OpenClaw security configuration checks

Run the official audit first, then inspect the execution host separately. These are documented inspection commands; the examples here are instructions for your installation, not commands run during our review. Security audit; Effective policy inspection.

Run /exec in the relevant conversation to inspect current session defaults: the offline policy view does not include per-session /exec overrides. A tool preview also has a limited scope; the docs say inclusion does not guarantee execution and absence does not prove a tool is disabled. Use the requested policy, target host and session together when interpreting the result. Session and preview scope.

Inspect network exposure alongside those command settings. The security overview describes loopback binding for a regular host installation, while container images default to an exposed bind that must be paired with authentication. Follow its exposure runbook before moving a gateway beyond loopback. This is a separate check from allowing a shell command: gateway authentication controls entry to the system. Host and container exposure defaults; Official exposure runbook.

Check OpenClaw sandbox mode, backend and mounts

Read the resolved sandbox mode before relying on Docker settings. The source resolves agent-specific values ahead of defaults, with mode off, backend docker and workspace access none as fallbacks. That combination describes an available backend without enabling it. Inspect the agent override as well as the shared setting so you know which value applies to the session. Sandbox resolution.

When Docker sandboxing is selected, inspect its network, capability and mount configuration. The reviewed Docker defaults include network none and dropping all capabilities; the resolver also accepts configuration overrides. Those settings describe the selected container's intended restrictions. Workspace access and bind mounts determine which host data is passed into that environment. Docker defaults and bind configuration.

The official prompt-injection guide makes the off-mode consequence explicit: implicit host=auto resolves to the gateway host when no sandbox is active, while explicit host=sandbox refuses execution without an available sandbox runtime. Use that distinction when diagnosing why a task ran on the gateway or refused to start. The effective containment and escape resistance of a deployed backend require runtime verification beyond this static review. Sandbox and host selection.

Understand OpenClaw exec full, off and deny

Read all three exec fields together, then compare them with the effective policy output. The source constants supply fallbacks, and the resolver accepts overrides. The docs explain each field's job. Fallback constants; Resolution; Policy definitions.

The practical consequence is that askFallback: deny does not turn full/off into an ask-first policy. A request allowed without an ordinary prompt never needs that unanswered-prompt fallback. Conversely, once a prompt is required, the fallback defines what happens if the approval channel is unavailable. Tool policy, host policy and applicable session modes still matter, so these exec findings do not establish universal send, purchase or deletion gates across integrations. Approval layers; Ask and fallback semantics.

For new configuration, the pinned docs prefer tools.exec.mode, with deny, allowlist, ask, auto and full modes. Full maps to the ordinary full/off behavior; ask uses allowlist policy and prompts on misses. Check the documented migration rules before combining this field with legacy security and ask keys: mixed policy can be rejected, and some legacy combinations have no exact normalized equivalent. Normalized exec modes.

Also inspect tools.exec.strictInlineEval if you allow interpreters. The docs describe approval requirements for recognized inline-evaluation forms and separate full-session/elevated exceptions. Use the relevant path's policy description when reviewing such commands, rather than assuming the word full overrides every other setting. Strict inline evaluation and exceptions.

Review OpenClaw scheduled work and tool availability

Check which gateway starts scheduled work and whether cron is enabled. The gateway constructs a CronService and resolves enablement from configuration. Trace an unattended workflow through that gateway and its target agent, then use the effective-policy checks for the host it can reach. A schedule identifies another entry point into the agent's permissions. Cron configuration; Cron service construction.

Inspect the enabled tools and plugins for that agent. The source builds tools for messaging, scheduling, web access, sessions and other operations conditionally, including plugins; an active count depends on configuration. The exec docs give a useful example: a messaging tool profile can exclude exec and process even when command approvals permit execution. Tool availability determines which action can be requested, approval policy determines whether it may proceed, and sandboxing determines its execution environment. Tool construction; Availability versus approval.

Review approval delivery for automation too. The pinned docs distinguish gateway-host cron approvals sent to capable operator clients from node-host automation's headless policy. Use the documented automation behavior for the chosen target before depending on a human to answer a scheduled request. Automation approval delivery.

Inspect OpenClaw memory, providers and diagnostics

Locate workspace MEMORY.md alongside the memory index when reviewing retention. Memory-core promotes records into that Markdown file and uses a SQLite-backed manager. Treat both as storage surfaces to inventory; deleting one file is not verified erasure of sidecar indexes, logs or recall history. Markdown promotion; SQLite-backed manager.

Check the configured provider as part of the same data review. The pinned default constants name openai and gpt-6-astra, but provider and plugin configuration can change destinations. Keep the model endpoint, messaging services and diagnostics exporter as separate entries in your connection inventory. Model and provider constants.

For the diagnostics OTel exporter, inspect diagnostics.enabled and diagnostics.otel.enabled. Its startup returns early when diagnostics configuration is missing, diagnostics is explicitly disabled, or OTel is not enabled. That establishes an opt-in condition for this exporter. Other telemetry defaults and an exhaustive effective outbound-host list are not established by these files. Exporter startup condition.

Use the comparison table to choose corresponding components in other projects. For example, the Hermes Agent review provides memory-file and terminal-backend checks, while the NanoClaw profile separates container mounts from provider approval prompts.

Check the scope of this OpenClaw security review

Use the reproduction record to distinguish the retained source slice from the attempted whole-tree scan. REA's full-tree retry reached the runner's 600-second cap without a complete JSON result. The retained graph analysis instead covers nine exact-byte cited-source files, with repository-relative paths and file hashes preserved. It parsed those files without parse failures; it is not a complete dependency analysis.

The earlier failed whole-tree attempt retained inventory evidence. A later runner metadata-release error required recovering timeout metadata from filesystem timestamps, not recovering a successful scan. The commands and output identities below preserve that distinction. Additional setup and security guidance in this page was read manually from the pinned repository documentation; it does not expand REA's nine-file coverage.

Reproduce this

Use the pinned revision and recorded commands below to trace the findings.

We read these with REA (morluto/rea, MIT, v6.4.0), an open-source reverse-engineering tool for agents, plus manual source reading. REA's repository supplies the tool; it does not endorse this review. We are not affiliated with this project or REA. This is static reading only: no target agent was executed and no live traffic was observed.

The pinned checkout is e46cb104f29782ab08caee36607946074f91056f. REA mapped the JS/TS application graph (Electron boundaries, imports, storage, request call sites); behavioural conclusions (approval paths, defaults, telemetry) were confirmed by reading the source. Electron boundaries were mapped where present. REA did not establish non-JavaScript core behavior.

These are portable equivalents of the commands recorded in the pass-2 manifest, run from a working directory that holds the pinned repository at repos/openclaw. Clone the repository at the pinned commit into repos/, create rea-out/, and run the commands from that directory. These are analysis commands, not instructions to start the agent. Executable and workspace paths are normalised to npx [email protected] and relative paths; some original runs also set a writable compiler-cache directory through ADDITIONAL_SWIFT_DRIVER_FLAGS.

npx [email protected] analyze-javascript-application repos/openclaw --format json --analysis-timeout-ms 120000 > rea-out/openclaw.json 2> rea-out/openclaw.stderr

npx [email protected] analyze-javascript-application repos/openclaw --format json --analysis-timeout-ms 120000 > rea-out/openclaw-analysis.json 2> rea-out/openclaw-analysis.stderr

npx [email protected] analyze-javascript-application rea-out/source-slices/openclaw --format json --analysis-timeout-ms 120000 > rea-out/openclaw-core.json 2> rea-out/openclaw-core.stderr

The retained analysis is partial. A writable compiler cache resolved the initial parsing setup failure, but blocked process-table inspection produced cleanup_incomplete. The runner stopped lingering CLIs after complete JSON output; that does not establish clean worker shutdown. Missing graph observations cannot establish absent behavior. The reproduction record records output hashes separately from Evidence IDs and subject digests.

For the bounded command, first recreate rea-out/source-slices/openclaw from the nine files listed in the reproduction record. Keep their repository-relative paths and verify their recorded SHA-256 values; do not substitute a reduced tree of your own choosing. The whole-tree timeout option applies per source, while the runner imposed the separate 600-second total cap.

FAQ

Where should I start an OpenClaw security check? Run the official security audit, then inspect sandbox selection and the effective exec policy for the gateway or node that performs the work. The checklist above gives the documented commands.

Does askFallback deny make every command wait for approval? No. It blocks when a required prompt cannot be answered. Use the exec table above to distinguish that fallback from the policy deciding whether a prompt is required.

Is a missing exec tool the same as sandboxing? No. Tool policy determines whether an operation is available. The sandbox configuration determines the environment used for sandboxed execution. Inspect both before enabling a workflow.

How can I compare this with Hermes Agent? Use the Hermes Agent configuration checks and comparison table to compare approval paths, execution environments and memory stores. Choose the deployment settings you need to inspect before comparing product labels.