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 default posture immediately after onboarding, before you approve any endpoints or apply any presets.
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.
OpenClaw EC2 Instance Metadata Credential Discovery
NemoClaw forces AWS_EC2_METADATA_DISABLED to true for every OpenClaw process because OpenShell blocks the link-local EC2 Instance Metadata Service endpoint.
This disables only EC2 instance-role credential discovery inside the sandbox.
Static access keys, bearer tokens, shared profiles, SSO and process credentials, web identity, and ECS container credentials remain eligible.
NemoClawโs host-local Amazon Bedrock adapter runs outside this sandbox credential-discovery boundary and remains unaffected.
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.
If the OpenClaw baseline includes npm_registry, that route remains GET-only until the npm preset is active.
Adding that preset temporarily gives the overlapping baseline route the same L4 transport while preserving its openclaw-only binary scope.
Removing the preset restores the exact reviewed GET-only baseline entry.
If you excluded npm_registry, adding or removing npm preserves that exclusion and does not recreate the baseline route.
When no exclusion exists, NemoClaw refuses the npm change if the live baseline differs from the reviewed GET-only entry or compatibility overlay.
The preset separately grants that registry transport to its listed npm, Yarn, and Node executables.
Personal Tier
The Personal tier selects personal-open-internet and every maintained preset supported by the active agent.
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.
OpenClaw sends Braveโs placeholder in the X-Subscription-Token header and Tavilyโs placeholder in the Authorization header.
OpenShell replaces these placeholders only when the request reaches the matching egress policy path.
The raw BRAVE_API_KEY or 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 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
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: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 (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
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.
- Return to Balanced or Restricted and recreate the sandbox when this broad egress is no longer required.
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.
- Review Sandbox Hardening for container-level security measures.
- 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.