NemoClaw Security Controls, Risks, and Posture Profiles

NemoClaw ships with deny-by-default security controls across five layers: network, filesystem, process, gateway authentication, and inference. You can tune every control, but each change shifts the risk profile. This page documents each configurable control, 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.

OpenShell enforces the platform-level mechanisms that NemoClaw configures, including network namespace isolation, seccomp filters, SSRF protection, TLS termination, and gateway authentication. For the full platform-level controls reference, refer to OpenShell Security Best Practices.

Protection Layers at a Glance

NemoClaw enforces security at five layers. NemoClaw locks some controls 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.

Layer	What it protects	Enforcement point	Changeable at runtime
Network	Unauthorized outbound connections and data exfiltration.	OpenShell gateway	Yes. Use `openshell policy set` or operator approval.
Filesystem	System binary tampering, credential theft, config manipulation.	Landlock LSM + container mounts	Landlock layout: no. Requires sandbox re-creation. Use host-side NemoClaw commands for durable config changes.
Process	Privilege escalation, fork bombs, syscall abuse.	Container runtime (Docker/K8s `securityContext`)	No. Requires sandbox re-creation.
Gateway Authentication	Unauthorized devices or clients reaching the OpenShell gateway or dashboard surfaces when present.	OpenShell gateway	No. Set at image build / onboarding time.
Inference	Credential exposure, unauthorized model access, cost overruns.	OpenShell gateway	Yes. Use the NemoClaw inference switching command.

Network Controls

NemoClaw controls which hosts, ports, and HTTP methods the sandbox can reach, and lets you approve or deny requests in real time. Network policy allowlists do not disable OpenShell’s SSRF guard, so internal-address blocking remains active even when an endpoint matches an egress rule.

OpenShell provides additional network enforcement mechanisms not covered here, including network namespace isolation, SSRF protection, TLS auto-detection and termination, and audit-vs-enforce modes. Refer to the Network Controls section of the OpenShell Security Best Practices.

Deny-by-Default Egress

The sandbox blocks all outbound connections unless you explicitly list the endpoint in the applicable baseline policy files.

Aspect	Detail
Default	All egress denied. Only endpoints in the baseline policy can receive traffic.
What you can change	Add endpoints to the policy file (static) or with `openshell policy set` (dynamic).
Risk if relaxed	Each allowed endpoint is a potential data exfiltration path. The agent can send workspace content, credentials, or conversation history to any reachable host.
Recommendation	Add only endpoints the agent needs for its task. Prefer operator approval for one-off requests over permanently widening the baseline.

Credential Discovery Boundaries

Credential probes are active network behavior, not harmless fallback checks. NemoClaw allows a credential source only in the process that is intended to hold those credentials and can reach that source.

Execution path	Rule
Host-brokered provider	Discover and use host credentials only in the host adapter. The sandbox receives a narrow `inference.local` interface, not the host credentials.
Sandbox-direct provider	Keep only credential sources that are deliberately provisioned and reachable inside the sandbox.
Ambient metadata provider	Disable SDK discovery when the metadata endpoint cannot exist across the sandbox boundary. Do not make an internal or link-local endpoint reachable merely to satisfy an automatic probe.
New agent or provider	Declare the enabled credential sources and add agent-specific tests proving that unavailable sources are not probed.

Network policy remains a second enforcement layer, not a substitute for disabling an impossible credential provider. Adding support for a new metadata-backed source requires a separately designed broker and explicit credential-boundary review.

Deep Agents Managed Inference Credential Discovery

NemoClaw configures the managed dcode runtime with a generated OpenAI-compatible route through inference.local. The sandbox receives a placeholder route key, not the upstream provider credential. The managed launchers reject credential-shaped environment values and upstream auth files before Deep Agents Code starts, so provider discovery stays on the host-side OpenShell boundary. If you need a new sandbox-direct credential source, design it as an explicit provider or MCP integration instead of placing secrets in /sandbox/.deepagents.

Binary-Scoped Endpoint Rules

Each network policy entry uses the binaries field to restrict which executables can reach the endpoint.

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 immediately denies the request.

Aspect	Detail
Default	Each endpoint restricts access to specific binaries. For example, the `github` preset restricts access so only `/usr/bin/git` can reach `github.com`. Binary paths support glob patterns (`` matches one path component, `*` matches recursively).
What you can change	Add binaries to an endpoint entry, or omit the `binaries` field to allow any executable.
Risk if relaxed	Removing binary restrictions lets any process in the sandbox reach the endpoint. An agent can use `curl`, `wget`, or a Python script to exfiltrate data to an allowed host, bypassing the intended usage pattern.
Recommendation	Always scope endpoints to the binaries that need them. If the agent needs a host from a new binary, add that binary explicitly rather than removing the restriction.

Path-Scoped HTTP Rules

Endpoint rules restrict allowed HTTP methods and URL paths.

Aspect	Detail
Default	Some endpoints allow GET and POST on `/**` (for example, `clawhub.ai`). Others restrict methods and paths to specific API routes (for example, `integrate.api.nvidia.com` allows POST only to inference and embedding paths and GET to model listings). Read-only endpoints such as `docs.openclaw.ai`, the `npm_registry` baseline entry, and the `pypi` preset allow GET only (PyPI also allows HEAD). The `npm` preset is an intentional exception: npm/Yarn registry traffic uses L4 pass-through for Node 22 undici CONNECT compatibility.
What you can change	Add methods (PUT, DELETE, PATCH) or restrict paths to specific prefixes.
Risk if relaxed	Allowing all methods on an API endpoint gives the agent write and delete access. For example, allowing DELETE on `api.github.com` lets the agent delete repositories.
Recommendation	Use GET-only rules for endpoints that the agent only reads. Add write methods only for endpoints where the agent must create or modify resources. Restrict paths to specific API routes when possible.

L4-Only vs L7 Inspection (`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.

Aspect	Detail
Default	Endpoints without a `protocol` field use L4-only enforcement: the proxy checks host, port, and binary identity, then relays the TCP stream without inspecting payloads. Setting `protocol: rest` enables L7 inspection: the proxy auto-detects and terminates TLS, then evaluates each HTTP request’s method and path against the endpoint’s `rules` or `access` preset.
What you can change	Set `protocol` to `rest`, `websocket`, `json-rpc`, or `mcp` and use rules that match that protocol. REST and WebSocket rules match methods and paths, JSON-RPC rules match RPC methods, and MCP rules can additionally match tools or parameter names.
Risk if relaxed	L4-only endpoints (no `protocol` field) allow the agent to send any data through the tunnel after the initial connection is permitted. The proxy cannot see or filter the HTTP method, path, or body. The `access: full` preset with `protocol: rest` enables inspection but allows all methods and paths, so it does not restrict what the agent can do at the HTTP level.
Recommendation	Select the matching L7 protocol and use the narrowest supported rules. Omit `protocol` only for protocols without an inspectable mode, endpoints that do not need request inspection, or documented compatibility exceptions that require a client-managed CONNECT tunnel.

Operator Approval Flow

When the agent reaches an unlisted endpoint, OpenShell blocks the request and prompts you in the TUI.

Aspect	Detail
Default	Enabled. The gateway blocks all unlisted endpoints and requires approval.
What you can change	OpenShell merges approved endpoints into the sandbox’s policy as a new durable revision. They persist across sandbox restarts within the same sandbox instance. When you destroy and recreate the sandbox through onboarding, the policy resets to the baseline defined in the blueprint.
Risk if relaxed	Approving an endpoint permanently widens the running sandbox’s policy. If you approve a broad domain (such as a CDN that hosts arbitrary content), the agent can fetch anything from that domain until you destroy and recreate the sandbox.
Recommendation	Review each blocked request before approving. If you find yourself approving the same endpoint repeatedly, add it to the baseline policy with appropriate binary and path restrictions. To reset approved endpoints, destroy and recreate the sandbox.

Policy Presets

NemoClaw ships preset policy files in nemoclaw-blueprint/policies/presets/ for common integrations.

Preset	What it enables	Key risk
`brave`	Brave Search API.	Agent can issue search queries.
`brew`	Homebrew (Linuxbrew) package manager. The sandbox base image includes the `brew` binary; this preset opens network egress to GitHub and the Homebrew formulae index so `brew install` can fetch bottles.	Allows installing arbitrary Homebrew packages, which may contain malicious code.
`claude-code`	Claude Code CLI API, telemetry, and crash-report endpoints.	Allows a separately installed Claude Code CLI to reach Anthropic and telemetry hosts with its own credentials. Do not use this preset for NemoClaw inference routing.
`discord`	Discord REST API, WebSocket gateway, CDN.	CDN endpoint (`cdn.discordapp.com`) allows GET to any path. WebSocket uses `access: full` (no inspection).
`github`	GitHub and GitHub REST API.	Gives agent read/write access to repositories and issues via `git`.
`huggingface`	Hugging Face Hub (download-only) and inference router.	Allows downloading arbitrary models and datasets. POST is restricted to the inference router only.
`jira`	Atlassian Jira API.	Gives agent read/write access to project issues and comments.
`local-inference`	Local Ollama and vLLM through the host gateway.	Allows sandbox access to host-side local inference ports covered by the preset.
`npm`	npm and Yarn registries via L4 pass-through.	Allows installing arbitrary npm packages, which may contain malicious code. OpenShell still gates by host, port, and binary, but does not inspect HTTP method, path, or body for this preset.
`outlook`	Microsoft 365, Outlook.	Gives agent access to email.
`pypi`	Python Package Index (GET and HEAD only).	Allows installing arbitrary Python packages, which may contain malicious code. Publishing is blocked.
`slack`	Slack API, Socket Mode, webhooks.	WebSocket uses `access: full`. Agent can post to any channel the bot token has access to.
`tavily`	Tavily Search API.	Agent can submit search queries and extraction targets to Tavily. The preset allows only `POST /search` and `POST /extract` from the maintained agent runtimes and enables request-body credential rewriting when the agent sends the placeholder in JSON.
`telegram`	Telegram Bot API.	Agent can send messages to any chat the bot token has access to.

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.

Web Search Credential Rewriting

NemoClaw registers each selected web search credential in a sandbox-scoped OpenShell provider and writes a resolver placeholder into the agent configuration.

Deep Agents uses the NemoClaw-managed Tavily opt-in path. The managed dcode launchers reject direct TAVILY_API_KEY injection, and the sandbox can reach api.tavily.com only after you apply the tavily preset and attach the tavily-search OpenShell provider. Because OpenShell attributes these calls to the sandbox Python interpreter, the Tavily egress grant is process-wide for managed sandbox Python, not a dcode-only boundary. OpenShell replaces these placeholders only when the request reaches the matching egress policy path.

The raw TAVILY_API_KEY is not written into the managed Deep Agents configuration.

The tavily preset restricts agent egress to the maintained Python and Node.js paths used by the supported agents. Its exact curl paths are used only by onboarding’s post-create verifier. Do not replace these paths with a broad /** binary rule. Broader binary access would let unrelated sandbox processes send data to Tavily through the same allowed endpoint.

Filesystem Controls

NemoClaw restricts which paths the agent can read and write, protecting system binaries, configuration files, and gateway credentials.

OpenShell covers additional filesystem enforcement details, including hard_requirement compatibility mode for Landlock and policy path validation rules. Refer to the Filesystem Controls section of the OpenShell Security Best Practices.

Read-Only System Paths

The container mounts system directories read-only to prevent the agent from modifying binaries, libraries, or configuration files.

Aspect	Detail
Default	`/usr`, `/lib`, `/proc`, `/dev/urandom`, `/app`, `/etc`, `/var/log` are read-only.
What you can change	Add or remove paths in the `filesystem_policy.read_only` section of the policy file.
Risk if relaxed	Making `/usr` or `/lib` writable lets the agent replace system binaries (such as `curl` or `node`) with trojanized versions. Making `/etc` writable lets the agent modify DNS resolution, TLS trust stores, or user accounts.
Recommendation	Never make system paths writable. If the agent needs a writable location for generated files, use a subdirectory of `/sandbox`.

Agent Config Directory

The /sandbox/.deepagents directory contains Deep Agents Code runtime state and NemoClaw-generated configuration. NemoClaw writes config.toml during onboarding and rebuilds. Direct edits to this file can be overwritten when NemoClaw regenerates the managed inference route.

The managed Deep Agents image deliberately omits raw provider and service credentials from generated configuration. Credential-bearing files such as .deepagents/.env and user-authored .deepagents/.mcp.json are treated as user-managed files and are not included in NemoClaw snapshots. The managed .deepagents/.nemoclaw-mcp.json projection contains OpenShell placeholders and is reconstructed from host-side registry state.

Aspect	Detail
Default	The Deep Agents config tree contains NemoClaw-generated `config.toml`, managed MCP projection state, and mutable Deep Agents memory and skill state.
What you can change	Use host-side NemoClaw commands for durable model, provider, managed MCP, and policy changes; inspect or edit memory and skills through `dcode` or direct file access when appropriate.
Risk of direct edits	Direct edits to generated config can drift from the host registry and may be lost on rebuild. Storing credentials in `.deepagents/.env` or user `.mcp.json` moves them outside the managed credential boundary.
Recommendation	Keep generated config under NemoClaw control. Use OpenShell providers and NemoClaw MCP commands for credentials, and back up Deep Agents state before destructive operations.

Writable Paths

The agent has read-write access to /sandbox, /tmp, /dev/null, and /dev/pts.

Aspect	Detail
Default	`/sandbox` (agent workspace), `/tmp` (temporary files), `/dev/null`, and `/dev/pts` (the devpts pseudo-terminal directory, required so PTY-based tools such as `tmux`, `script`, and interactive shells can allocate a terminal).
What you can change	Add additional writable paths in `filesystem_policy.read_write`.
Risk if relaxed	Each additional writable path expands the agent’s ability to persist data and potentially modify system behavior. Adding `/var` lets the agent write to log directories. Adding `/home` gives access to other user directories.
Recommendation	Keep writable paths to `/sandbox` and `/tmp`. If the agent needs a persistent working directory, create a subdirectory under `/sandbox`.

Landlock LSM Enforcement

Landlock is a Linux Security Module that enforces filesystem access rules at the kernel level.

Aspect	Detail
Default	`compatibility: strict`. Deep Agents sandbox startup fails closed when OpenShell cannot enforce the managed filesystem policy.
What you can change	This is a NemoClaw Deep Agents invariant, not a user-facing knob.
Risk if relaxed	Silent Landlock degradation would leave the terminal coding harness with weaker filesystem isolation while still reporting a successful sandbox.
Recommendation	Run Deep Agents on a kernel and runtime that support Landlock enforcement. Rebuild or move hosts if startup reports an enforcement failure.

Process Controls

NemoClaw limits the capabilities, user privileges, and resource quotas available to processes inside the sandbox.

OpenShell enforces additional process-level controls not covered here, including seccomp BPF socket domain filters and a specific enforcement application order (namespace entry, privilege drop, Landlock, seccomp). Refer to the Process Controls section of the OpenShell Security Best Practices.

Capability Drops

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 behavior 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.

To make the drop fail-closed instead of best-effort, set NEMOCLAW_REQUIRE_CAP_DROP=1 in the entrypoint environment. The agent then refuses to start unless it verifies that the agent process tree’s bounding set is free of dangerous capabilities. It does not boot on a host whose bounding set still holds them, typically one that cannot perform the drop because CAP_SETPCAP or capsh is missing and the container runtime did not provide a clean bounding set. This is opt-in because such hosts are common, including many cloud VMs, Docker Desktop, and WSL. Leaving it unset preserves the best-effort default. The check covers the agent process tree only. The container runtime spawns a nemo-deepagents connect shell outside that tree, so the check does not affect it (tracked in NVIDIA/OpenShell#1452).

Aspect	Detail
Default	The entrypoint drops dangerous capabilities at startup using `capsh`, then uses `setpriv` during user step-down when possible. Best-effort.
What you can change	When launching with `docker run` directly, pass `--cap-drop=ALL --cap-add=NET_BIND_SERVICE` for stricter enforcement. In the standard NemoClaw onboarding flow, the entrypoint handles capability dropping automatically.
Risk if relaxed	`CAP_SYS_ADMIN` and `CAP_SYS_PTRACE` expand kernel and process attack surface. `CAP_NET_RAW` allows raw socket access for network sniffing. `CAP_DAC_OVERRIDE` bypasses filesystem permission checks. If `capsh` or `setpriv` cannot run, the container retains more of the runtime-provided capability set.
Recommendation	Run on an image that includes `capsh` and `setpriv` (the NemoClaw image includes them). For defense-in-depth, also pass `--cap-drop=ALL` at the container runtime level.

Gateway Process Isolation

Gateway and agent UID isolation depends on the container process topology. A direct root-entrypoint container runs the gateway as the separate gateway user and the agent as the sandbox user. An OpenShell-managed container has OpenShell as PID 1 and launches nonroot nemoclaw-start, so the supervisor, gateway, and agent all use the sandbox UID.

Aspect	Detail
Default	Direct root entrypoints use `gosu gateway` for UID isolation. The OpenShell-managed topology runs the gateway and agent under the same sandbox UID because `no-new-privileges` prevents the nonroot entrypoint from changing users.
What you can change	This is not a user-facing knob. The selected container topology determines whether the entrypoint can step down from root to the gateway UID.
Risk if relaxed	A same-UID agent can signal peer processes and can attempt to imitate the expected gateway process shape. The root managed controller prevents PID-reuse mistakes, but it cannot prove provenance against a malicious same-UID process or provide the direct root-entrypoint restart seal for mutable config.
Recommendation	Use a direct root-entrypoint deployment when separate gateway and agent UIDs are required. Treat the managed controller as authenticated lifecycle and exact-target safety, not as a same-UID provenance boundary.

No New Privileges

The no-new-privileges flag prevents processes from gaining additional privileges through setuid binaries or capability inheritance.

Aspect	Detail
Default	OpenShell sets `PR_SET_NO_NEW_PRIVS` using `prctl()` inside the sandbox process as part of the seccomp filter setup. The NemoClaw Compose example also shows the equivalent `security_opt: no-new-privileges:true` setting.
What you can change	OpenShell’s seccomp path enforces this inside the sandbox. It is not a user-facing knob.
Risk if relaxed	Without this flag, a compromised process could execute a setuid binary to escalate to root inside the container, then attempt container escape techniques.
Recommendation	No action needed. OpenShell enforces this automatically when the sandbox network policy is active. In the OpenShell-managed topology, this flag also means the nonroot entrypoint and gateway remain under the sandbox UID.

Process Limit

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 behavior is best effort. If the container runtime restricts ulimit modification, the entrypoint logs a security warning and continues without the limit.

Aspect	Detail
Default	512 processes (`ulimit -u 512`), best-effort.
What you can change	Increase or decrease the limit with `--ulimit nproc=N:N` in `docker run` or the `ulimits` section in Compose. The runtime-level ulimit takes precedence over the entrypoint’s setting.
Risk if relaxed	Removing or raising the limit makes the sandbox vulnerable to fork-bomb attacks, where a runaway process spawns children until the host runs out of resources. If the entrypoint cannot set the limit (logs `[SECURITY] Could not set soft/hard nproc limit`), the container runs without process limits.
Recommendation	Keep the default at 512. If the agent runs workloads that spawn many child processes (such as parallel test runners), increase to 1024 and monitor host resource usage. If the entrypoint logs a warning about ulimit restrictions, set the limit through the container runtime instead.

Open File Descriptor Limit

An open file descriptor limit caps the number of files, sockets, and pipes the sandbox user can hold open at once. The entrypoint sets both soft and hard limits using ulimit -n 65536. This behavior is best effort. If the container runtime restricts ulimit modification, the entrypoint logs a security warning and continues without the limit.

Aspect	Detail
Default	65536 open files, soft and hard (`ulimit -n 65536`), best-effort.
What you can change	Increase or decrease the limit with `--ulimit nofile=N:N` in `docker run` or the `ulimits` section in Compose. The runtime-level ulimit takes precedence over the entrypoint’s setting.
Risk if relaxed	Without this cap, the sandbox inherits the Docker daemon default (`nofile` ~1048576). A runaway or hostile process can then open file descriptors until it exhausts them, causing a denial of service that can starve the gateway, the agent, or the host of file handles. If the entrypoint cannot set the limit (logs `[SECURITY] Could not set soft/hard nofile limit`), the container runs without a file-descriptor cap. Ref #4527.
Recommendation	Keep the default at 65536. If the agent legitimately keeps many connections or files open, raise it deliberately and monitor host file-descriptor usage. If the entrypoint logs a warning about ulimit restrictions, set the limit through the container runtime instead.

Headless Deep Agents Approval Boundary

Interactive dcode sessions keep destructive tools behind the Deep Agents Code approval UI. Headless dcode -n is an explicit automation boundary with no approval UI. The managed headless path automatically approves non-shell tool requests such as file writes and edits, while still disabling shell execution, startup commands, interpreter tool calling, executable hooks, unmanaged MCP files, nested remote sandboxes, remote async subagents, and alternate model routes.

Aspect	Detail
Default	Interactive `dcode` prompts for destructive tools. Headless `dcode -n` auto-approves non-shell tools and keeps shell execution disabled.
What you can change	Choose interactive `dcode` when you need to review tool calls. Use `dcode -n` only for tasks where unattended file edits are acceptable.
Risk if relaxed	Treating headless mode like an interactive approval session can let file edits happen without a human prompt.
Recommendation	Use the interactive TUI for sensitive repositories or destructive tasks. Reserve `dcode -n` for bounded automation with a reviewed workspace and policy.

Non-Root User

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.

Aspect	Detail
Default	`run_as_user: sandbox`, `run_as_group: sandbox`. A separate `gateway` user runs the gateway process.
What you can change	Change the `process` section in the policy file to run as a different user.
Risk if relaxed	Running as `root` inside the container gives the agent access to modify any file in the container filesystem and increases the impact of container escape vulnerabilities.
Recommendation	Never run as root. Keep the `sandbox` user.

PATH Hardening

The entrypoint locks the PATH environment variable to system directories, preventing the agent from injecting malicious binaries into command resolution.

Aspect	Detail
Default	The default sandbox entrypoint sets `PATH` to `/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin` at startup. Agent-specific images may add locked read-only runtime directories, such as `/opt/venv/bin` for LangChain Deep Agents Code.
What you can change	This is not a user-facing knob. The entrypoint enforces it.
Risk if relaxed	Without PATH hardening, the agent could create an executable named `curl` or `git` in a writable directory earlier in the PATH, intercepting commands run by the entrypoint or other processes.
Recommendation	No action needed. The entrypoint handles this automatically.

Build Toolchain Removal

The Dockerfile removes compilers and network probes from the runtime image.

Aspect	Detail
Default	The Dockerfile purges `gcc`, `gcc-12`, `g++`, `g++-12`, `cpp`, `cpp-12`, `make`, `netcat-openbsd`, `netcat-traditional`, and `ncat` from the sandbox image.
What you can change	Modify the Dockerfile to keep these tools, or install them at runtime if package manager access is allowed.
Risk if relaxed	A compiler lets the agent build arbitrary native code, including kernel exploits or custom network tools. `netcat` enables arbitrary TCP connections that bypass HTTP-level policy enforcement.
Recommendation	Keep build tools removed. If the agent needs to compile code, run the build in a separate, purpose-built container and copy artifacts into the sandbox.

Image Digest Pinning

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.

Aspect	Detail
Default	`nemoclaw-blueprint/blueprint.yaml` pins the sandbox image by digest. A CI regression test blocks any mutable-tag reference from merging.
What you can change	Contributors bumping the sandbox image must update the digest in `blueprint.yaml`. Release tooling should rewrite the digest automatically.
Risk if relaxed	Reverting to a mutable tag (`:latest`) allows a registry-side change to replace the sandbox image without any blueprint update, which is a supply-chain risk.
Recommendation	Always reference the sandbox image by digest. If you build a custom image with the onboarding `--from` path, the digest constraint does not apply to your local build.

Gateway Authentication Controls

CLI Secret Redaction

The CLI automatically redacts secret patterns (API keys, bearer tokens, provider credentials) from command output and error messages before logging them.

Aspect	Detail
Default	Enabled. The runner redacts secrets from stdout, stderr, and thrown error messages.
What you can change	This is not a user-facing knob. The CLI enforces it on all command output paths.
Risk if relaxed	Without redaction, secrets could appear in terminal scrollback, log files, or debug output shared in bug reports.
Recommendation	No action needed. If you share NemoClaw debug output, verify that no secrets appear in the collected diagnostics.

Memory Secret Scanner

Deep Agents does not use the OpenClaw NemoClaw plugin memory scanner. The managed dcode launchers reject credential-shaped environment values and upstream auth files before startup, but Deep Agents memory and skill files remain user-authored content. Keep secrets in OpenShell providers and avoid writing raw credentials to /sandbox/.deepagents, project .deepagents/, or skill files.

Inference Controls

OpenShell routes all inference traffic through the gateway to isolate provider credentials from the sandbox.

Routed Inference through `inference.local`

The OpenShell gateway intercepts all inference requests from the agent and routes them to the configured provider. The agent never receives the provider API key.

Aspect	Detail
Default	The agent talks to `inference.local`. The host owns the credential and upstream endpoint.
What you can change	You cannot configure this architecture. The system always enforces it.
Risk if bypassed	If the agent could reach an inference endpoint directly (by adding it to the network policy), it would need an API key. Since the sandbox does not contain credentials, this acts as defense-in-depth. However, adding an inference provider’s host to the network policy without going through OpenShell routing could let the agent use a stolen or hardcoded key.
Recommendation	Do not add inference provider hosts (such as `api.openai.com` or `api.anthropic.com`) to the network policy for NemoClaw model traffic. Use OpenShell inference routing instead. The `claude-code` preset is a separate opt-in exception for running the Claude Code CLI with its own credentials, not a way to configure NemoClaw inference.

Provider Trust Tiers

Different inference providers have different trust and cost profiles.

Provider	Trust level	Cost risk	Data handling
NVIDIA Endpoints	High. Hosted on `build.nvidia.com`.	Pay-per-token with an API key. Unattended agents can accumulate cost.	NVIDIA infrastructure processes requests.
OpenAI	High. Commercial API.	Pay-per-token. Same cost risk as NVIDIA Endpoints.	Subject to OpenAI data policies.
Anthropic	High. Commercial API.	Pay-per-token. Same cost risk as NVIDIA Endpoints.	Subject to Anthropic data policies.
Google Gemini	High. Commercial API.	Pay-per-token. Same cost risk as NVIDIA Endpoints.	Subject to Google data policies.
Local Ollama	Self-hosted. No data leaves the machine.	No per-token cost. GPU/CPU resource cost.	Data stays local.
Custom compatible endpoint	Varies. Depends on the proxy or gateway.	Varies.	Depends on the endpoint operator.

For sensitive workloads, use local Ollama to keep data on-premise. For general use, NVIDIA Endpoints provide a balance of capability and trust. Review the data policies of any cloud provider you use.

Experimental Providers

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 appear by default. An already-running vLLM server on localhost:8000 also appears in the menu without a flag because selecting it is an explicit user action.

Aspect	Detail
Default	Local NVIDIA NIM and generic Linux managed vLLM install/start are hidden. DGX Spark and DGX Station managed vLLM entries, plus already-running vLLM on `localhost:8000`, are offered when detected.
What you can change	Set `NEMOCLAW_EXPERIMENTAL=1` before onboarding to surface Local NIM and generic Linux managed vLLM. To request only the managed vLLM path non-interactively, set `NEMOCLAW_PROVIDER=install-vllm`.
Risk if selected	NemoClaw has not fully validated these providers. NIM requires a NIM-capable GPU. The managed vLLM path pulls a container image and starts it on a supported NVIDIA GPU host. Misconfiguration can cause failed inference or unexpected behavior.
Recommendation	Use experimental providers only for evaluation. Do not rely on them for always-on assistants.

Posture Profiles

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.

Locked-Down (Default)

Use for always-on assistants with minimal external access.

Keep all defaults and do not add presets.
Use operator approval for any endpoint the agent requests.
Use NVIDIA Endpoints or local Ollama for inference.
Monitor the TUI for unexpected network requests.

Development

Use when the agent needs package registries, Docker Hub, or broader GitHub access during development tasks.

Apply the pypi and npm presets for package installation.
Keep binary restrictions on all presets.
Review the agent’s network activity periodically with openshell term.
Use operator approval for any endpoint not covered by a preset.

Integration Testing

Use when the agent talks to internal APIs or third-party services during testing.

Add custom endpoint entries with tight path and method restrictions.
Use protocol: rest for all HTTP APIs to maintain inspection.
Use operator approval for unknown endpoints during test runs.
Review and clean up the baseline policy after testing by removing endpoints that are no longer needed.

Common Mistakes

The following patterns weaken security without providing meaningful benefit.

Mistake	Why it matters	What to do instead
Omitting `protocol: rest` on REST API endpoints without a compatibility reason	Endpoints without a `protocol` field use L4-only enforcement. The proxy allows the TCP stream through after checking host, port, and binary, but cannot see or filter individual HTTP requests.	Add `protocol: rest` with explicit `rules` to enable per-request method and path control on REST APIs. Use L4 pass-through only for documented cases such as npm/Yarn on Node 22, where the client requires a CONNECT tunnel that L7 inspection would break.
Adding endpoints to the baseline policy for one-off requests	Adding an endpoint to the baseline policy makes it permanently reachable across all sandbox instances.	Use operator approval. Approved endpoints persist within the sandbox instance but reset when you destroy and recreate the sandbox.
Relying solely on the entrypoint for capability drops	The entrypoint drops dangerous capabilities using `capsh`, but this is best-effort. If `capsh` is unavailable or `CAP_SETPCAP` is not in the bounding set, the container runs with the default capability set.	Pass `--cap-drop=ALL` at the container runtime level as defense-in-depth.
Leaving generated agent config writable on sensitive workloads	The generated config tree contains model routing, channel settings, and runtime integration state (`/sandbox/.openclaw` for OpenClaw, `/sandbox/.hermes` for Hermes, `/sandbox/.deepagents` for Deep Agents). Writable config lets the agent drift from host-managed policy and routing.	Keep generated config under NemoClaw control for always-on assistants handling sensitive data.
Adding inference provider hosts to the network policy for NemoClaw inference	Direct network access to an inference host bypasses credential isolation and usage tracking.	Use OpenShell inference routing instead of adding hosts like `api.openai.com` or `api.anthropic.com` to the network policy. Apply `claude-code` only when intentionally running the separate Claude Code CLI inside the sandbox.
Disabling device auth for remote deployments	Without device auth, any device on the network can connect to the gateway without pairing. Combined with a cloudflared tunnel, this makes the dashboard publicly accessible and unauthenticated.	Keep `NEMOCLAW_DISABLE_DEVICE_AUTH` at its default (`0`). Only set it to `1` for local headless or development environments.

Known Limitations

Limitation	Impact	Mitigation
Bypassing managed gateway paths	Network policy and inference auth are not enforced when an agent runtime is launched outside the NemoClaw-managed gateway path.	Use NemoClaw-managed sandbox entrypoints for production workflows.
Same-UID lifecycle control in the OpenShell-managed topology	The root controller authenticates the host action, verifies a stable process shape, pidfd-targets the exact observed child, and proves replacement health. It cannot establish malicious process provenance when the supervisor, gateway, and agent share the sandbox UID. Mutable config also has managed cold-start trust and time-of-check/time-of-use limits unless it is root-owned and locked.	Use a direct root-entrypoint deployment when UID isolation and the root restart seal are required. Lock managed config before treating the strict hash as a trust anchor, and recreate a sandbox after suspected same-UID compromise.
Direct filesystem writes bypass application-layer scanners	Application-layer scanners can intercept agent tool calls, not arbitrary raw filesystem writes (e.g., `echo secret > file`).	Landlock restricts writable paths. Application-layer scanning is defense-in-depth, not a filesystem-level control.
Base64/hex-encoded secrets are not detected	Content-based regex scanning cannot detect encoded or obfuscated secrets.	Use environment variables or credential stores instead of writing secrets to files.

Network Policies for the full Deep Agents baseline policy reference.
Credential Storage for provider and managed MCP credential handling.
Workspace Files for Deep Agents state and credential-bearing file exclusions.
Set Up MCP Servers for managed MCP credential replacement.
Inference Options for provider configuration details.
How It Works for the protection layer architecture.
OpenShell Security Best Practices for the platform-level controls reference, including network namespace isolation, seccomp filters, SSRF protection, TLS termination, and gateway authentication.