NemoClaw Enterprise Readiness and Admin Capability Guidance
This page gives field teams and enterprise evaluators a single reference for what NemoClaw supports today, what an operator must handle manually, what the OpenShell platform or the inference provider owns, and what is roadmap-only. Use it to answer enterprise readiness and support-boundary questions consistently instead of inferring an answer from individual bug fixes.
NemoClaw is an open-source reference stack for running sandboxed agents more safely inside OpenShell. It is in active development, and interfaces can change between releases. NemoClaw is not a hardened, multi-tenant enterprise control plane, and several admin and control-plane expectations are platform-owned or roadmap-only. This page states where each capability stands so evaluators do not treat roadmap items as current commitments.
Confirm before you commit
Treat this page as a living reference for an active evaluation window, not a contractual support matrix. Confirm the current state of any capability with the NemoClaw product and engineering owners before you repeat it in a customer commitment. Statuses can change between releases, and the tracked issues linked here may resolve or change scope.
How to Use This Guidance
Each capability below carries one status from the following vocabulary.
This page covers support boundaries and admin capability classification. For validated platform, inference, and launch claims, pair it with the launch claims and platform support matrix tracked in NVIDIA/NemoClaw#4630.
Support Boundaries
NemoClaw orchestrates several components that it does not all own. Knowing who enforces each boundary prevents misattributing a limitation to NemoClaw when the owner is OpenShell, the agent runtime, or the provider.
For the architecture behind these boundaries, refer to How It Works and Architecture Details.
Enterprise Readiness by Capability Area
The following matrix answers the most common enterprise evaluation questions. Each row links to the deeper documentation and, where a concrete fix is in progress, to the tracked issue.
For remote deployment specifics, refer to Deploy to Remote GPU Instances and Brev Web UI. For container-level hardening beyond the entrypoint defaults, refer to Sandbox Hardening.
Admin and Control-Plane Capabilities
Enterprise admins often expect a control plane with centralized management, identity integration, and fleet-wide policy. NemoClaw targets a single-operator, single-host reference workflow today. The following table classifies each admin and control-plane expectation by current support state so you can set accurate expectations.
Known Limitations and Workarounds
These limitations are most likely to surface during an enterprise evaluation. Each one includes the current workaround or next step.
Field Conversation Guidance
Use the following phrasing to describe NemoClaw accurately in customer and field conversations.
- Describe NemoClaw as an open-source reference stack for running agents more safely inside OpenShell, in active development, rather than a finished enterprise control plane.
- State that egress is deny-by-default and that an operator approves new endpoints, so the agent cannot reach arbitrary hosts.
- Explain that inference credentials stay on the host and the agent calls models through a routed
inference.localendpoint, so the sandbox never holds provider keys. - Frame centralized fleet management, operator RBAC, enterprise SSO, and multi-tenant isolation as roadmap-only or out of scope today, and avoid presenting them as current capabilities.
- Position cost controls and spend limits as provider-owned, and recommend setting provider-side limits for unattended agents.
- When a customer hits a known limitation, point to the workaround in this guide and the tracked issue rather than promising a fix date.
Ownership and Keeping This Current
This guidance must stay accurate for the duration of the evaluation window.
- The NemoClaw product and engineering owners review this page before it is reused in launch-facing or customer-facing material.
- Update the affected rows whenever a tracked issue resolves, a capability ships, or a status changes, and align the status vocabulary with the platform support matrix in #4630.
- Treat each linked issue as the source of truth for in-progress work, and remove the link when the work lands and the row moves to a supported status.
Related Topics
- Security Best Practices for the full control-by-control risk framework.
- Network Policies for the baseline egress policy reference.
- Monitor Sandbox Activity for status, logs, audit records, and the TUI.
- Troubleshooting for installation, onboarding, and runtime issue resolution.
- How It Works for the protection-layer architecture.