Network policies

Baseline network policy, filesystem rules, policy layers, and the operator approval flow for NemoClaw sandboxes.

Network policies

NemoClaw runs with a strict-by-default network policy. The sandbox can only reach endpoints that are explicitly allowed. Any request to an unlisted destination is intercepted by OpenShell, and the operator is prompted to approve or deny it in real time through the TUI.

Policy layers

The baseline policy in nemoclaw-blueprint/policies/openclaw-sandbox.yaml defines rules across four layers:

Layer	Description
Network	Per-endpoint allow rules specifying host, port, protocol, TLS, HTTP methods, and path patterns. Scoped to specific binaries.
Filesystem	Read-write and read-only path allowlists enforced by Landlock LSM (best-effort).
Process	Sandbox process user and group (sandbox:sandbox).
Inference	Inference requests are routed through the OpenShell gateway, not via direct sandbox egress. Only the local route is allowed within the sandbox.

Baseline policy

The baseline policy is defined in nemoclaw-blueprint/policies/openclaw-sandbox.yaml.

Filesystem

Path	Access
/sandbox	Read-write
/tmp	Read-write
/dev/null	Read-write
/usr	Read-only
/lib	Read-only
/proc	Read-only
/dev/urandom	Read-only
/app	Read-only
/etc	Read-only
/var/log	Read-only

The sandbox process runs as the sandbox user and group. Landlock LSM enforcement applies on a best-effort basis.

Network policies

The following endpoint groups are allowed by default. All endpoints use TLS termination on port 443.

Policy name	Endpoints	Binaries	Rules
claude_code	api.anthropic.com:443, statsig.anthropic.com:443, sentry.io:443	/usr/local/bin/claude	All methods, all paths
nvidia	integrate.api.nvidia.com:443, inference-api.nvidia.com:443	/usr/local/bin/claude, /usr/local/bin/openclaw	All methods, all paths
github	github.com:443, api.github.com:443	/usr/bin/gh, /usr/bin/git	All methods, all paths
clawhub	clawhub.com:443	/usr/local/bin/openclaw	GET, POST
openclaw_api	openclaw.ai:443	/usr/local/bin/openclaw	GET, POST
openclaw_docs	docs.openclaw.ai:443	/usr/local/bin/openclaw	GET only
npm_registry	registry.npmjs.org:443	/usr/local/bin/openclaw, /usr/local/bin/npm	All methods (access: full)
telegram	api.telegram.org:443	Any binary	GET, POST on /bot*/**

Inference

The baseline policy allows only the local inference route. External inference providers are reached through the OpenShell gateway, not by direct sandbox egress. This means inference traffic does not appear in the sandbox network policy and does not require additional endpoint rules.

Policy YAML structure

Policies are written in YAML. The following example shows the structure of the baseline policy file:

openclaw-sandbox.yaml

version: 1

filesystem_policy:
  include_workdir: true
  read_only:
    - /usr
    - /lib
    - /proc
  read_write:
    - /sandbox
    - /tmp
    - /dev/null

landlock:
  compatibility: best_effort

process:
  run_as_user: sandbox
  run_as_group: sandbox

network_policies:
  nvidia:
    name: nvidia
    endpoints:
      - host: integrate.api.nvidia.com
        port: 443
        protocol: rest
        enforcement: enforce
        tls: terminate
        rules:
          - allow: { method: "*", path: "/**" }
    binaries:
      - { path: /usr/local/bin/openclaw }

Policy presets

Policy presets are named bundles of endpoint rules that extend the baseline. They are managed per sandbox.

Listing presets

View available presets and see which ones are applied to a sandbox:

nemoclaw <name> policy-list

Output format:

  Policy presets for sandbox 'my-assistant':
    ● preset-name — Description of the preset
    ○ other-preset — Another available preset (not applied)

● = applied, ○ = not applied.

Adding a preset

Add a preset interactively:

nemoclaw <name> policy-add

The command displays available presets, prompts for the preset name, and confirms before applying.

Hot-reloadable vs. locked-at-creation policies

Some policy fields can be updated on a running sandbox without restarting. Others are locked at sandbox creation time.

Policy field	Hot-reloadable
network_policies	Yes — apply with openshell policy set
filesystem_policy	No — locked at sandbox creation
process.run_as_user	No — locked at sandbox creation
landlock.compatibility	No — locked at sandbox creation

The policy file header comments note: “Dynamic updates (network_policies, inference) can be applied post-creation via openshell policy set. Static fields are effectively creation-locked.”

Operator approval flow

When the agent attempts to reach an endpoint not listed in the policy, OpenShell intercepts the request and presents it for operator review:

1. Request intercepted

   The agent makes a network request to an unlisted host. OpenShell blocks the connection and logs the attempt.

2. TUI notification

   The openshell term TUI displays the blocked request with the destination host, port, and requesting binary.

3. Operator decision

   The operator approves or denies the request in the TUI.

4. Session policy update

   If approved, the endpoint is added to the running policy for the duration of the session.

To see the approval flow in action, run the walkthrough script:

./scripts/walkthrough.sh

This opens a split tmux session with the TUI on the left and the agent on the right.

Modifying the policy

Static changes (requires sandbox recreation)

Edit nemoclaw-blueprint/policies/openclaw-sandbox.yaml and re-run the onboard wizard:

nemoclaw onboard

This recreates the sandbox with the updated policy.

Dynamic changes (no restart required)

Apply network policy updates to a running sandbox without restarting:

openshell policy set <policy-file>

Only network_policies and inference fields support hot-reload. Filesystem, process, and Landlock fields require sandbox recreation.