NemoClaw Security Posture and Control Trade-Offs
NemoClaw Security Posture and Control Trade-Offs
NemoClaw ships with deny-by-default security controls across five layers: network, filesystem, process, gateway authentication, and inference. This page compares those layers, explains the controls that operators change at runtime, and helps you choose a posture profile. The Security Controls navigation group owns the detailed filesystem, process, and gateway authentication guidance.
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 five protection layers. It does not show onboarding tier presets, optional web search, or endpoints that you approve later.
Network Controls
NemoClaw controls which hosts, ports, and HTTP methods the sandbox can reach, and lets you approve or deny requests in real time.
OpenShell hard-blocks unspecified, loopback, and link-local destinations, including the common cloud metadata range.
An endpoint with allowed_ips can explicitly permit other private ranges, so treat that field as a server-side request forgery (SSRF) boundary change.
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.
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.
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.
Hermes Managed Inference Credential Discovery
NemoClaw configures Hermes with a custom provider through inference.local, and the shipped Hermes image does not install the optional native Bedrock dependency.
AWS credential discovery for supported Bedrock inference therefore remains in NemoClawโs host-local adapter, outside the sandbox.
If direct Hermes Bedrock support is added later, it must apply the same unavailable-metadata rule and include Hermes-specific credential-probe acceptance tests before it is enabled.
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.
Path-Scoped HTTP Rules
Endpoint rules restrict allowed HTTP methods and URL paths.
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.
Operator Approval Flow
When the agent reaches an unlisted endpoint, OpenShell blocks the request and prompts you in the TUI.
Policy Presets
NemoClaw ships preset policy files in nemoclaw-blueprint/policies/presets/ for common integrations.
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.
Personal Tier
The Personal tier selects personal-open-internet as its web authority and preserves non-web policy.
The open-internet preset allows every sandbox binary to reach public and private address ranges on destination ports 80 and 443 through L4 passthrough.
Traffic on those ports is not limited to HTTP or HTTPS.
OpenShell does not inspect the hostname, application protocol, HTTP method, path, or body for those connections.
The preset excludes unspecified, loopback, and link-local ranges, and other ports remain denied unless another entry permits them.
Use it only for trusted personal workloads with trusted prompts and data.
The sandboxโs filesystem, process, gateway authentication, and managed credential controls remain active.
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.
Hermes sends the Tavily placeholder in the JSON api_key field, so the tavily policy preset enables request_body_credential_rewrite for api.tavily.com.
OpenShell replaces these placeholders only when the request reaches the matching egress policy path.
The raw TAVILY_API_KEY is not written into the sandbox configuration.
The tavily preset restricts agent egress to the maintained Python and Node.js paths used by the supported agents.
Its 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
Review filesystem defaults, writable paths, agent state, and Landlock enforcement in Understand Filesystem Controls.
Process Controls
Review capability drops, resource limits, runtime identity, and image hardening in Understand Process Controls.
Gateway Authentication Controls
Review runtime-specific gateway access, dashboard exposure where applicable, secret redaction, and memory scanning in Understand Gateway and Secret Controls.
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.
Provider Trust Tiers
Different inference providers have different trust and cost profiles.
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 on eligible hosts other than N1x and generic Linux managed vLLM install/start.
DGX Spark and DGX Station managed vLLM entries appear by default.
N1x omits local NVIDIA NIM, and N1x Express offers only the Deferred managed-vLLM preview.
N1x remains outside the supported-platform set because its physical NemoClaw Express E2E validation is incomplete.
After NemoClaw qualifies the N1x identity, you must provide explicit managed-vLLM preview intent before onboarding can use this path.
On hosts other than N1x, an already-running vLLM server on localhost:${NEMOCLAW_VLLM_PORT:-8000} also appears in the menu without a flag because selecting it is an explicit user action.
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
Use for always-on assistants with minimal external access.
- Select the Restricted tier during onboarding.
Onboarding defaults to the Balanced tier, which selects the
npm,pypi,huggingface, andbrewpresets. - Choose no web search when prompted.
Enabling web search adds the selected
braveortavilypreset even with the Restricted tier. - Keep the remaining defaults and do not add other 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
pypiandnpmpresets 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.
Personal
Use only for a trusted single-user sandbox that needs arbitrary TCP egress on destination ports 80 and 443.
- Select the Personal tier during onboarding.
- Treat every prompt, downloaded package, webpage, and workspace file as able to trigger external TCP traffic on destination ports
80and443. - Do not place raw credentials or sensitive data in the sandbox unless the agent must use them.
- Create a new Balanced or Restricted sandbox when this broad egress is no longer required. NemoClaw refuses to remove Personal in place because its normalized policy has already replaced overlapping web entries.
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: restfor 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.
Known Limitations
Related Topics
- Network Policies for the full baseline policy reference.
- Customize the Network Policy for static and dynamic policy changes.
- Approve or Deny Network Requests for the operator approval flow.
- Choose an Inference Provider 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.