Pattern Automation
← Blog

NemoClaw Personal Tier: 6 Network Checks Before a Business Pilot

The Personal tier in NemoClaw includes a required open-internet network preset. Here is what the current NVIDIA docs say it permits, which address ranges they exclude, and what to verify before company data becomes visible to an agent.

Discuss this post in AI

Send a pre-filled prompt to ChatGPT, Claude, Gemini, or Perplexity — get a summary, ask follow-ups, or compare ideas from this guide.

Separate sandbox isolation from network reach

NVIDIA describes NemoClaw's deny-by-default security controls across five layers: network, filesystem, process, gateway authentication, and inference.[2] The Personal tier also selects a required personal-open-internet preset for web access.[1] Those facts are compatible: the sandbox can retain filesystem and process protections while the selected network policy grants a specific outbound capability.[1][2]

When Personal is selected or carried forward, that preset is mandatory for every agent and onboarding entry point. NEMOCLAW_POLICY_MODE=custom and NEMOCLAW_POLICY_MODE=skip control only additional presets; neither setting removes Personal's required web authority.[1]

What the Personal tier permits

The network-policy reference describes a hostless layer-4 endpoint on destination ports 80 and 443. A request is allowed only when every resolved address is within the preset's allowed ranges.[1] The rule does not inspect the application protocol or payload, and it does not restrict the hostname, HTTP method, path, or body.[1] So traffic on those ports is not limited to ordinary HTTP or HTTPS.[1]

NVIDIA's security-posture guide says the Personal preset allows every sandbox binary to reach public and private address ranges on ports 80 and 443. It excludes unspecified, loopback, and link-local ranges—including the common cloud metadata range—and other ports remain denied unless another policy entry permits them.[2] Do not read that metadata block as a guarantee that all private destinations are unreachable; check the effective allowed ranges for the installed policy.[1][2]

The network-policy reference explicitly warns that an agent can send workspace data or sandbox-visible credentials to an arbitrary reachable service on either port without an operator approval prompt.[1] This documents a capability of the selected policy; it does not mean every deployment will transmit data.[1] The other documented controls remain active, so the right question is which boundary the network preset enforces—not whether the word “sandbox” appears in the product description.[1][2]

Six checks before a business pilot

  1. Confirm the selected tier and effective presets. Record whether onboarding chose or carried forward Personal.[1] Do not assume custom or skip removes its required web preset; the docs say those modes affect only additional presets.[1]
  1. Inspect the actual egress rules. Confirm the active destination ports and allowed address ranges for the installed version.[1][2] Include private address ranges in the review; do not infer that they are blocked simply because loopback, link-local, and the common metadata range are excluded.[1][2]
  1. Limit what the agent can see. Start with a sanitized workspace and no production secrets.[1] If the agent can read a file, assume its contents may be available to an outbound request under this policy.[1]
  1. Run a controlled egress test. In a non-production sandbox, use a synthetic canary and a test endpoint your team controls.[1] Exercise an adversarial instruction that asks the agent to send the canary, then inspect the request and available logs. Do not use real credentials, production data, or production metadata/internal services.
  1. Verify both allowed and denied paths. Test only against controlled destinations.[1][2] Confirm the expected behavior for ports 80 and 443, and verify that other ports and the documented blocked address classes behave as your policy expects. Keep the test evidence with the policy snapshot.[1][2]
  1. Repeat after policy or onboarding changes. Re-check the effective preset after re-onboarding, changing tiers, or updating NemoClaw.[1] The reference says Personal restores its required preset if it is deselected during setup.[1]

A practical go/no-go rule

NVIDIA recommends using this tier only for trusted personal workloads with trusted prompts and data.[1][2] For a business pilot, a conservative rule is to keep sensitive data and untrusted external content out of the agent workspace until an operator has verified that the effective egress policy enforces the required boundary. That caution follows from the documented ability to send workspace data or sandbox-visible credentials to any reachable service on ports 80 and 443 without an operator approval prompt.[1]

For broader questions about connector scopes, data handling, and human approval, see Pattern's AI-agent security checklist.

Documentation checked October 11, 2026; defaults and policy details may change in later releases.

Sources

  1. [1] NVIDIA — NemoClaw Network Policies
  2. [2] NVIDIA — NemoClaw Security Posture and Control Trade-Offs

Explore Neuro OS →

More from Blog