NemoClaw Security Best Practices: Controls, Risks, and Posture Profiles
NemoClaw Security Best Practices: Controls, Risks, and Posture Profiles
NemoClawNemoClaw Security Best Practices: Controls, Risks, and Posture Profiles
NemoClaw ships with deny-by-default security controls across four layers: network, filesystem, process, and inference. You can tune every control, but each change shifts the risk profile. This page documents every configurable knob, its default, what it protects, the concrete risk of relaxing it, and a recommendation for common use cases.
For background on how the layers fit together, refer to How It Works.
NemoClaw enforces security at four layers. NemoClaw locks some when it creates the sandbox and requires a restart to change them. You can hot-reload others while the sandbox runs.
The following diagram shows the default posture immediately after onboarding, before you approve any endpoints or apply any presets.
NemoClaw controls which hosts, ports, and HTTP methods the sandbox can reach, and lets operators approve or deny requests in real time.
The sandbox blocks all outbound connections unless you explicitly list the endpoint in the applicable baseline policy files.
Each network policy entry restricts which executables can reach the endpoint using the binaries field.
OpenShell identifies the calling binary by reading /proc/<pid>/exe (the kernel-trusted executable path, not argv[0]), walking the process tree for ancestor binaries, and computing a SHA256 hash of each binary on first use.
If someone replaces a binary while the sandbox runs, the hash mismatch triggers an immediate deny.
Endpoint rules restrict allowed HTTP methods and URL paths.
protocol Field)All sandbox egress goes through OpenShell’s CONNECT proxy.
The protocol field on an endpoint controls whether the proxy also inspects individual HTTP requests inside the tunnel.
When the agent reaches an unlisted endpoint, OpenShell blocks the request and prompts the operator in the TUI.
NemoClaw ships preset policy files in nemoclaw-blueprint/policies/presets/ for common integrations.
Recommendation: Apply presets only when the agent’s task requires the integration. Review the preset’s YAML file before applying to understand the endpoints, methods, and binary restrictions it adds.
NemoClaw restricts which paths the agent can read and write, protecting system binaries, configuration files, and gateway credentials.
The container mounts system directories read-only to prevent the agent from modifying binaries, libraries, or configuration files.
The /sandbox/.openclaw directory contains the OpenClaw gateway configuration (model routing, CORS settings, channel config).
The current entrypoint reads the gateway auth token from OpenClaw config when present, exports it as OPENCLAW_GATEWAY_TOKEN, and writes it to /tmp/nemoclaw-proxy-env.sh so interactive sandbox sessions can reach the gateway through system-wide shell hooks.
In root mode, the gateway process still runs as the separate gateway user, but the token is intentionally available to sandbox shells for local gateway access.
Writable agent state such as plugins, skills, hooks, and workspace metadata lives directly under /sandbox/.openclaw.
By default, this directory starts writable so the agent can manage its own config, install skills, and write to standard home-directory paths natively.
For sensitive workloads, use a reviewed host-side immutability workflow after initial setup so config and high-risk state entry points cannot be changed by the sandbox user.
The immutability workflow locks high-risk state directories (skills, hooks, cron, agents, extensions, plugins, workspace, memory, devices, canvas, telegram, wechat, whatsapp, platforms, weixin, profiles, skins) to root:sandbox with chmod -R go-w.
The OpenClaw gateway (a member of the sandbox group) keeps read access to plugin and agent code; the sandbox user can no longer write them.
The same workflow also locks the secret-bearing directories (credentials, identity, pairing) to root:root 700 with chmod -R go-rwX.
Neither the sandbox user nor the gateway can read those secrets while the lock is active.
Restoring the mutable-default posture returns both groups to sandbox:sandbox 2770.
The list is the union of state directories declared by every shipped agent manifest; the lock helper silently skips dirs that aren’t present in a given agent’s config tree.
Two exemption kinds keep runtime data writable.
The lock inventory omits top-level Hermes runtime dirs (sessions/, memories/, logs/, cache/, plans/) and the image-build-regenerated openclaw-weixin/; the lock helper never touches those paths.
Inside a locked tree, the helper restores agents/<agent-id>/sessions/ to sandbox:sandbox 2770 after the surrounding agents/ lock so the OpenClaw TUI can create and write session metadata under an otherwise root-owned parent.
If any high-risk state-dir root is a symlink when the lock runs, it refuses to proceed and reports “Config not locked: state dir root is a symlink” rather than silently following the link with privileged chown -R / chmod -R.
/sandbox/.openclaw with mode 2770 (setgid sandbox:sandbox) and openclaw.json with mode 660, so the agent and its group can read and write config directly. A reviewed host-side immutability workflow should compare the intended ownership and mode with the live sandbox filesystem before treating the config tree as locked.openclaw.json. In the default mutable state, .config-hash is sandbox-owned and is not a tamper-proof trust anchor, so startup does not fail closed on that hash. When the hash is root-owned and read-only, startup enforces it and refuses to start if the hash does not match.openclaw.json and other locked files into host-side state.
Verification recomputes hashes inside the sandbox and surfaces drift on mismatch, so a host-root tamper that flips permissions back to 444 root:root after rewriting the file is still flagged.
Sandboxes locked before the seal landed have no recorded hash; permission-only verification cannot prove their bytes match the image original, so the seal is not a retroactive proof of integrity for legacy state.
The same limitation applies when the locked file set grew after the existing seal was captured.
Rebuild the sandbox for a known-good baseline before trusting a new seal.OPENCLAW_GATEWAY_TOKEN and writes it to /tmp/nemoclaw-proxy-env.sh for interactive sandbox sessions. Keep this in mind when deciding whether a workload should run with mutable config or an immutable config posture.The agent has read-write access to /sandbox, /tmp, and /dev/null.
Landlock is a Linux Security Module that enforces filesystem access rules at the kernel level.
NemoClaw limits the capabilities, user privileges, and resource quotas available to processes inside the sandbox.
The entrypoint drops dangerous Linux capabilities from the bounding set at startup using capsh.
This limits what capabilities any child process (gateway, sandbox, agent) can ever acquire.
When the entrypoint switches from root to the sandbox and gateway users, it uses setpriv when available to remove the remaining privilege-separation capabilities from the child process at the same time as the user change.
The initial entrypoint drop removes cap_sys_admin, cap_sys_ptrace, cap_net_raw, cap_dac_override, cap_sys_chroot, cap_fsetid, cap_setfcap, cap_mknod, cap_audit_write, and cap_net_bind_service.
During setpriv step-down, the child process also loses cap_setuid, cap_setgid, cap_fowner, cap_chown, and cap_kill.
This is best-effort: if capsh is not available or CAP_SETPCAP is not in the bounding set, the entrypoint logs a warning and continues with the default capability set.
If setpriv is unavailable, the entrypoint falls back to gosu and logs a warning that the remaining bounding-set capabilities were retained for the child process.
For additional protection, pass --cap-drop=ALL with docker run or Compose (see Sandbox Hardening).
The in-sandbox gateway runs as a separate gateway user, not as the sandbox user that runs the agent.
The no-new-privileges flag prevents processes from gaining additional privileges through setuid binaries or capability inheritance.
A process limit caps the number of processes the sandbox user can spawn.
The entrypoint sets both soft and hard limits using ulimit -u 512.
This is best-effort: if the container runtime restricts ulimit modification, the entrypoint logs a security warning and continues without the limit.
The sandbox runs agent processes as a dedicated sandbox user and group.
The entrypoint starts as root for privilege separation, then drops to the sandbox user for all agent commands.
The entrypoint locks the PATH environment variable to system directories, preventing the agent from injecting malicious binaries into command resolution.
The Dockerfile removes compilers and network probes from the runtime image.
The blueprint references the sandbox image by an immutable @sha256: digest instead of a mutable tag such as :latest.
A registry compromise or accidental force-push cannot silently swap the sandbox image.
The entrypoint and migration flows enforce chmod 600 on all auth-profiles.json files under ~/.openclaw.
This prevents other users on the host from reading stored credentials.
The OpenClaw gateway authenticates devices that connect to the Control UI dashboard. NemoClaw hardens these defaults at image build time.
Device authentication requires each connecting device to go through a pairing flow before it can interact with the gateway.
NemoClaw binds the OpenShell gateway to loopback by default.
The allowInsecureAuth setting controls whether the gateway permits non-HTTPS authentication.
The auto-pair watcher automatically approves device pairing requests from recognized clients, so you do not need to manually approve the Control UI.
The CLI automatically redacts secret patterns (API keys, bearer tokens, provider credentials) from command output and error messages before logging them.
The NemoClaw plugin blocks the agent from writing likely secrets (API keys, tokens, private keys) into persistent memory files. The scanner intercepts Write, Edit, and similar tool calls targeting memory and workspace paths before they reach disk.
OpenShell routes all inference traffic through the gateway to isolate provider credentials from the sandbox.
inference.localThe OpenShell gateway intercepts all inference requests from the agent and routes them to the configured provider. The agent never receives the provider API key.
Different inference providers have different trust and cost profiles.
Recommendation: For sensitive workloads, use local Ollama to keep data on-premise. For general use, NVIDIA Endpoints provide a good balance of capability and trust. Review the data policies of any cloud provider you use.
The NEMOCLAW_EXPERIMENTAL=1 environment variable gates local NVIDIA NIM and generic Linux managed vLLM install/start. DGX Spark and DGX Station managed vLLM entries are offered by default, and an already-running vLLM server on localhost:8000 is offered in the menu without a flag, because selecting either is an explicit user action.
The following profiles describe how to configure NemoClaw for different use cases. These are not separate policy files. They provide guidance on which controls to keep tight or relax.
Use for always-on assistants with minimal external access.
Use when the agent needs package registries, Docker Hub, or broader GitHub access during development tasks.
pypi and npm presets for package installation.openshell term.Use when the agent talks to internal APIs or third-party services during testing.
protocol: rest for all HTTP APIs to maintain inspection.The following patterns weaken security without providing meaningful benefit.