nemoclaw helps. the real enterprise problem remains
one agent got safer. shared gateways not so much
nvidia just gave openclaw a real containment layer. that matters. but it doesn’t solve openclaw’s hardest enterprise problem: hostile multi-tenancy on a shared gateway. that’s where openclaw tenant wrapper, or octw, fits. nemoclaw hardens one runtime. octw isolates tenants from each other. those are different jobs, and a lot of people are mixing them up.
first, one definition makes this conversation much easier to follow. a gateway is the running openclaw server process that handles requests, tools, memory, sessions, and routing. openclaw’s security guidance is explicit that one gateway is one trusted operator boundary. it isn’t a hostile multi-tenant security boundary for mutually untrusted or adversarial users sharing one agent or gateway. if you need adversarial-user isolation, the guidance is to split trust boundaries with separate gateways and credentials, ideally on separate os users or hosts.
openclaw already has a substantial security toolkit of its own. its public docs cover gateway auth, trusted-proxy auth, sandboxing, openshell support, secrets handling, multiple gateways, a security audit workflow, formal verification materials, and a mitre atlas threat model. nemoclaw is narrower and more opinionated. nvidia’s docs describe it as the openclaw plugin for openshell, with a sandboxed environment where network requests, file access, and inference calls are governed by policy.
that distinction matters because these projects solve different layers of the problem.
openclaw = agent platform
nemoclaw = runtime containment
octw = tenant isolation
once you separate those layers, the rest gets much easier to reason about.
where nemoclaw actually differs from openclaw
the easy mistake is comparing nemoclaw to openclaw like they’re peer platforms. they aren’t.
openclaw is the main runtime. it owns the gateway, sessions, tools, plugins, skills, memory, and channels. openclaw can already run with sandbox backends, including openshell. nemoclaw adds an opinionated way to do that. nvidia’s architecture docs say nemoclaw has two main components: a typescript plugin that integrates with the openclaw cli, and a python blueprint that orchestrates openshell resources. the blueprint lifecycle is resolve, verify digest, plan, and apply.
that’s why the real comparison isn’t “which one’s better?” it’s “which layer are you trying to strengthen?” if you want a safer runtime boundary around one agent or one trust domain, nemoclaw is the interesting addition. if you need a platform boundary between customers or teams that shouldn’t trust each other, nemoclaw’s only part of the answer.
what the “enterprise-ready” claim means in practice
a lot of the nemoclaw discussion gets muddled because “enterprise-ready” can mean two very different things.
the first meaning is runtime control. on that axis, nemoclaw has real substance. nvidia’s docs say it’s strict by default. the sandbox can only reach endpoints that are explicitly allowed. requests to unlisted destinations are intercepted by openshell and surfaced to the operator for approval in real time. writable filesystem access is tightly constrained. inference is routed through openshell instead of leaving the sandbox directly. those are hard controls, not prompt decorations.
the second meaning is platform maturity. on that axis, nemoclaw still looks early. nvidia’s repo calls it alpha software, says it’s early-stage, warns that interfaces and behavior may change, and says it shouldn’t yet be considered production-ready. the quickstart also says nemoclaw currently requires a fresh installation of openclaw. that doesn’t mean the security model’s fake. it means the deployment story’s still moving. the honest read is narrower and more credible: strong security posture, not yet a finished enterprise platform.
that same distinction applies to the claim that nemoclaw was reviewed by security experts and is locked down. my read is that the protection’s real, but the public assurance story’s still incomplete. in the public docs and repo i reviewed, i didn’t find public evidence of a third-party audit, a nemoclaw-specific public threat model, or a published formal verification package. i’d treat “reviewed by security experts” as a positive design signal, not as a substitute for a public assurance case.
how real is the protection?
the strongest thing about nemoclaw is also the simplest thing to explain: policy sits outside the agent.
according to nvidia’s docs, nemoclaw runs with strict-by-default policy. only allowlisted endpoints are reachable. unknown outbound requests are intercepted and surfaced in the tui for approval. writable paths are limited to /sandbox, /tmp, and /dev/null, while major system paths like /usr, /lib, /proc, /app, /etc, and /var/log are read-only. inference requests don’t leave the sandbox directly. openshell intercepts them and routes them to the configured provider.
the enforcement mechanisms are concrete.
network policy: only listed endpoints are allowed by default, and unlisted destinations are blocked and surfaced for approval
filesystem policy: /sandbox and /tmp are read-write, while major system paths are read-only
process isolation: the sandbox uses seccomp, network namespaces, and landlock
inference routing: model calls go through openshell rather than direct sandbox egress
that’s a real containment boundary.
but “locked down” should be read literally, not mystically. the default allowlist still includes useful but nontrivial destinations like github, the github api, openclaw services, the npm registry, telegram, and nvidia endpoints. landlock enforcement is also explicitly documented as best-effort. this is a practical sandbox, not a mathematically complete box. if you allow github and npm, you still accept supply-chain risk from github and npm.
persistent prompt injection still survives the sandbox
nemoclaw changes the blast radius of prompt injection much more than it changes the existence of prompt injection.
openclaw’s context and system-prompt docs say bootstrap files are injected into project context on every turn, including agents.md, soul.md, tools.md, identity.md, user.md, heartbeat.md, bootstrap.md on first run, and memory.md or MEMORY.md when present. the docs are also explicit that memory/*.md daily files aren’t auto-injected. they’re accessed on demand through memory_search and memory_get. openclaw’s memory docs separately say memory is plain markdown in the workspace and the files on disk are the source of truth. that distinction matters. bootstrap files can create durable persistence inside prompt context, while daily memory files are durable state on disk that the agent can still read later when needed.
that creates a straightforward persistence path. malicious instructions don’t need to live inside model weights to survive. they can live in files that the agent later reads back into context or reads on demand from disk. if poisoned content tries to reach a forbidden host, touch a disallowed path, or break outside policy, nemoclaw can help. if the malicious content can operate entirely inside permissions you already approved, persistent poisoning can still survive inside the sandbox. the right summary is simple: prompt injection’s better contained, not solved.
supply-chain risk is still the hardest part
that’s where the difference between runtime control and content trust gets impossible to ignore.
openclaw’s plugin architecture is refreshingly plain about the tradeoff. native plugins run in-process with the gateway. they aren’t sandboxed. a loaded native plugin has the same process-level trust boundary as core code, and a malicious native plugin is equivalent to arbitrary code execution inside the openclaw process. the plugin docs also stress that only native openclaw plugins execute runtime code in-process.
openclaw’s public security model and threat model are also unusually explicit about the attack surface. the security guide says if multiple untrusted users can message one tool-enabled agent, they should be treated as sharing the same delegated tool authority. the threat-model materials enumerate risks like prompt injection, malicious skill installation, skill update poisoning, credential harvesting, and unauthorized command execution. that isn’t a reason to dismiss the platform. it’s evidence that the maintainers are doing real security work in public and not pretending the hard parts don’t exist.
the public advisory history reinforces the point. openclaw has disclosed and patched a workspace plugin auto-discovery issue that could execute code from cloned repositories, a skill-download target-directory validation issue that could write outside the intended install sandbox, and a tools.exec.safeBins long-option-abbreviation bypass that could skip required exec approvals in allowlist mode.
nemoclaw improves this picture only partway. its blueprint path is versioned and orchestrated through the plugin-and-blueprint flow, which is good for the nemoclaw bootstrap path itself. but that doesn’t validate every plugin, skill bundle, package, or repository the agent’s later allowed to touch. if your policy still permits github, clawhub, or npm, the sandbox can still ingest bad content from an allowed place. runtime policy can reduce what malicious content’s able to do after execution. it doesn’t turn untrusted content into trusted content. you still need pinning, scanning, curated sources, and a deliberate update path.
openclaw is less opinionated, but more mature in public
that’s the part many comparisons miss.
if you only compare default runtime containment, nemoclaw looks safer than a typical upstream openclaw deployment. i think that’s a fair conclusion. it starts from a stricter execution model. if you compare public security maturity, openclaw has the stronger paper trail today. it has a public security guide, multiple-gateway guidance, a security audit workflow, a formal verification page with explicit caveats, and a mitre atlas threat model.
the formal verification page is especially notable because it’s careful about scope. it says the models are tla+/tlc today and explicitly says they aren’t a proof that openclaw’s secure in all respects or that the full typescript implementation’s correct. it also warns that drift between model and code is possible and that results are bounded by the explored state space. that kind of precision builds trust.
the security audit tooling is stronger than most people realize. openclaw documents openclaw security audit, --deep, --fix, and --json. the audit flags common footguns like auth exposure, elevated allowlists, and filesystem permissions. --fix applies safe, deterministic remediations like flipping common groupPolicy=”open” cases to groupPolicy=”allowlist”, tightening redaction defaults, and locking down permissions on sensitive state and config files. that’s unusually mature public hardening tooling for an agent platform.
the cleanest way to say it is this: nemoclaw currently looks stronger on default runtime containment. openclaw currently looks stronger on public security maturity and operational transparency. those are both valuable. they’re just different kinds of security work.
multi-tenant deployment is where octw matters most
openclaw’s own security model says the quiet part out loud: it isn’t a hostile multi-tenant security boundary. if you need stronger isolation, the docs say to split trust boundaries with separate gateways and, ideally, separate os users or hosts. the multiple-gateways docs say much the same thing in operational form: if you need stronger isolation or redundancy, run separate gateways with isolated profiles, ports, state directories, and workspaces.
nemoclaw doesn’t really change that boundary. it makes a gateway safer to run. it doesn’t turn one gateway into a secure multi-tenant bus. if multiple untrusted users can message one tool-enabled agent, openclaw tells you to treat them as sharing the same delegated tool authority for that agent. that’s the scenario the upstream guidance is warning you about.
that’s the gap octw is designed to close.
octw, short for openclaw tenant wrapper, is a recent project where i added tenant isolation around the official openclaw image by provisioning one isolated openclaw gateway container per tenant.
based on octw’s public repository and docs, the intended pattern is one isolated upstream openclaw installation per tenant, with a shared control plane and per-tenant isolation at the container, network, and filesystem levels. the current docs describe per-tenant bridge networks marked internal, dedicated volumes with 0700 permissions, non-root execution, dropped linux capabilities, no-new-privileges, no host port publishing, optional gvisor, jwt auth at the edge, tenant-scoped roles, aes-256-gcm secret encryption, forwarded-header sanitization, injected tenant and user identity headers, and audit events stored in postgres. architecturally, that lines up with the way openclaw itself says to think about trust boundaries. instead of trying to stretch one gateway across adversarial tenants, octw treats each tenant as its own gateway boundary from the start.
there’s one important nuance here. octw’s public, but it still looks early. my read is that it’s the cleaner pattern for multi-tenant deployments right now because it matches openclaw’s documented trust model directly. but that’s still an architectural judgment, not proof that octw’s already battle-proven infrastructure.
where nemoclaw and octw could complement each other
i do think the two projects can complement each other. the cleanest mental model is simple: octw handles the outer boundary between tenants, and nemoclaw hardens what happens inside each tenant boundary. openclaw already supports openshell as a sandbox backend, so part of the conceptual bridge already exists upstream. nemoclaw adds a stricter plugin-and-blueprint layer on top of that, with managed inference routing, policy defaults, and host-side orchestration.
[user]
↓
[edge proxy / auth]
↓
[octw: per-tenant gateway]
↓
[nemoclaw: sandbox + policy]
↓
[openclaw runtime]
↓
[tools / plugins / memory]
the reason this combination’s still a future-looking architecture is operational, not conceptual. nemoclaw’s alpha and still early. the quickstart currently requires a fresh installation of openclaw. octw, by contrast, is already aligned with the upstream openclaw image and with openclaw’s documented trust model, but it’s also early by public project signals. so my current read is straightforward: octw’s the cleaner pattern for multi-tenant deployments right now, and nemoclaw’s the hardening layer worth watching and potentially adding per tenant as the deployment story matures.
what i’d actually run today
if you’re a solo builder, run openclaw with sandboxing enabled and a strict tool allowlist.
if you’re a small trusted team, keep openclaw, isolate by project, use secretrefs, and be conservative with plugins.
if you’re building saas or anything customer-facing, don’t share a gateway across untrusted users. run one gateway per tenant or per trust boundary.
if the workload’s higher risk, add nemoclaw-style containment inside each tenant boundary and keep egress tight. review unknown destinations manually. that recommendation follows directly from openclaw’s trust-boundary guidance, multiple-gateway guidance, and nemoclaw’s documented containment model.
quick deployment decision cheat sheet
use this to decide your setup in 30 seconds.
just you, local builds
→ openclaw + sandbox
→ minimal plugins
→ tight allowlistsmall trusted team
→ openclaw + per-project isolation
→ shared gateway can be acceptable inside one trust boundary
→ strict plugin disciplinemultiple customers or users you don’t fully trust
→ never share gateway
→ one gateway per tenant
→ isolated volumes + networkssensitive data or higher-risk workflows
→ add nemoclaw inside each tenant boundary
→ restrict egress aggressively
→ require manual approval for unknown callsif you’re unsure
→ default to more isolation, not less
quick self-check: you might already be exposed
if any of these are true, you’ve got risk right now.
multiple users share one gateway
plugins auto-install or auto-update
the agent can call unrestricted external endpoints
memory is shared across users or unrelated workflows
you don’t know what your allowlist actually includes
fix those first.
minimal policy mindset
if you want the shortest possible baseline for thinking about this, start here.
default deny outbound traffic
explicitly allow only required endpoints
keep writable paths limited to workspace-only locations
block dynamic installs unless reviewed
treat every plugin, repo, package, or skill as a trust decision
that mindset matters more than any brand name.
minimum checklist
don’t share gateways across untrusted users
restrict network egress hard
pin dependencies and versions
treat plugins as code execution risk
be selective about repos, packages, and skills
isolate memory and credentials per trust boundary
run the security audit regularly
those aren’t fluffy best practices. in openclaw land, they’re the difference between a controlled system and a future postmortem.
bottom line
my current read is simple.
nvidia made openclaw meaningfully safer to run. that part’s real. nemoclaw adds concrete runtime controls around network access, filesystem exposure, and inference routing. but it doesn’t solve persistent prompt injection by itself, it doesn’t solve supply-chain trust, and it doesn’t solve hostile multi-tenancy on one shared gateway. openclaw itself is already telling you that the answer there is separate trust boundaries. that’s why octw belongs in the same conversation. openclaw provides the runtime. nemoclaw strengthens the runtime boundary. octw provides the tenant boundary. put together carefully, they’re complementary layers rather than competing products.
sources
 | A guest post by
|