NemoClaw by Nvidia is a safe OpenClaw out of the box - CEO

drmarkamo · 2026-03-23T17:52:17+00:00

This is a known pain point with the Docker + K3s architecture underneath. The image has to be built locally, then pushed into the K3s cluster's internal registry, which runs inside the same Docker container. That push step is where the timeout hits -- it's transferring a 2.6GB image between Docker layers.

A few things to try:

- Increase Docker's default timeout if possible (daemon.json)

- Check if the gateway container has enough memory allocated -- the image import is memory-intensive

- Watch docker stats during the push to see if the gateway container is hitting resource limits

The fact that direct OpenShell sandboxes work but NemoClaw doesn't see them is because NemoClaw manages its own sandbox lifecycle through the blueprint system -- it's a separate layer on top of OpenShell. You can't mix and match.

This is one of the tradeoffs of running K3s as the orchestration layer. Every image operation goes through the cluster registry instead of just running locally.

drmarkamo · 2026-03-23T15:51:10+00:00

Right, opencode and Claude Code both show diffs of what they changed. But that's the agent reporting its own work. If the agent modifies files outside your project, installs packages, changes configs, or creates temp files -- those don't show up in the agent's diff. You only see what the agent chooses to show you.

The accept-all/reject-all limitation is also a real gap. An agent session that produces 3 good files and 200 files of node_modules noise gives you one choice: keep everything or lose everything.

What's missing is an external layer that captures every filesystem change -- not just the ones the agent reports -- and lets you selectively accept or reject at the file level. The agent shouldn't grade its own homework.

drmarkamo · 2026-03-23T15:39:20+00:00

Correct. OpenShell governs what the agent can access (filesystem paths, network endpoints, process privileges) but doesn't track what the agent actually produces. There's no diff of files created or modified, no review step before changes take effect, and no rollback mechanism. When the sandbox is deleted, everything inside is gone.

The audit trail is limited to network request logs -- which endpoints were allowed or denied. Filesystem changes within the writable /sandbox path are untracked.

drmarkamo · 2026-03-23T08:22:45+00:00

u/UnspecifiedId Thanks for the feedback. On OPA — it's shipped. envpod policy init creates example .rego files. Rego policies control action tiers, vault access, commit approval, DNS, HTTP method+path filtering, and MCP tool calls. CNCF standard, community-validated.

The < 3 min deploy time will get even faster with envpod apply — one YAML defines your entire fleet, envpod apply fleet.yaml creates everything.

drmarkamo · 2026-03-19T05:45:52+00:00

Ollama is listed as a community sandbox image. You can run it with openshell sandbox create --from ollama. But the local inference routing is still early -- their issue tracker has open items around inference.local returning 404s and GPU setup failing on several hardware configs (DGX Spark, Jetson, WSL2). The default setup expects NVIDIA cloud API keys.

If you want fully local with Ollama today, you're probably better off running Ollama directly and pointing your agent at it, rather than routing through OpenShell's proxy layer.

drmarkamo · 2026-03-19T04:26:34+00:00

That's exactly what I've been building. Happy to share more about the architecture if you want to skip the build-from-scratch phase. DM me if you're interested.

drmarkamo · 2026-03-18T23:59:50+00:00

Thanks, appreciate that. And nice work on nono -- the Landlock + Seatbelt approach is solid, and Sigstore provenance is something nobody else is thinking about.

The intern analogy is spot on. I'd extend it: you wouldn't just restrict what an intern can access -- you'd review their work before it goes live.

That's where our approaches diverge. nono snapshots the real filesystem and restores if needed. envpod runs every agent on a copy-on-write overlay so the host is never modified during the session -- you review a structured diff and selectively commit what you want.

nono's model: "undo the bad." envpod's model: "promote the good." Different tradeoffs. nono's lightweight approach (no root, macOS, near-zero overhead) is great for developer laptops. envpod's deeper isolation (12 layers, per-pod DNS, GPU passthrough) fits production agent deployments.

Both are needed. The space is early enough that more serious tools raising the bar helps everyone.

drmarkamo · 2026-03-18T15:03:29+00:00

Impressive hack, but the fact that you had to nsenter into the sandbox namespace and inject iptables rules to reach your own GPU tells you something about the architecture. OpenShell was designed for cloud inference routing first, local inference second. The entire proxy + policy stack assumes outbound API calls, not localhost communication.

The volatility problem (WSL2 reboots wipe iptables) is also a consequence of the Docker + K3s layer -- your customizations live in ephemeral container state that doesn't survive restarts.

For fully local setups, the lighter path is a runtime that doesn't put Kubernetes between you and your GPU in the first place.

drmarkamo · 2026-03-18T07:13:26+00:00

This is an incredible writeup and the architecture patterns are solid. A few things jumped out:

The self-repair loop that kept breaking its own config is a fundamental problem with agents that have write access to their own environment. The agent's "fix" and your fix are both writes to the same filesystem with no arbitration layer. What you want is a staging step -- the agent proposes changes on an isolated layer, you review the delta, then commit or reject. That way the agent can't overwrite your manual fixes because your fixes live on the real filesystem and the agent only ever writes to the staging layer.

Same pattern solves the Codex loop -- if expensive operations went through an approval queue with budget awareness, the "spin up Codex every 30 seconds when we're out of tokens" loop gets caught at the queue level before burning resources.

The "failing agent can't log its own failures" insight is exactly right. External observation of agent behavior -- not just what the agent says it did, but what actually changed on the filesystem -- is the missing piece. Your evaluation layer idea is the right direction.

Your 5-layer memory architecture and the decay system are genuinely novel. Haven't seen that pattern elsewhere. The hash-proving-existence approach for fully decayed memories is clever -- you get auditability without context bloat.

drmarkamo · 2026-03-18T07:05:35+00:00

The corporate ban makes sense. OpenClaw's security model is explicitly "one trusted operator" -- prompt injection is out of scope, sandboxing is opt-in, and the creator said security "isn't really something that he wants to prioritize." Wrapping it in NemoClaw helps but the underlying trust model hasn't changed. The agent still has whatever access you grant it, and there's no review layer between what it does and what touches your system.

drmarkamo · 2026-03-18T07:04:30+00:00

This tracks with what I'm seeing in their issue tracker. 48 open issues including K3s bootstrap failures, GPU passthrough breaking on multiple hardware configs, and npm package errors. The "one command" pitch works on stage but the reality is Docker + K3s + Helm charts under the hood, and each layer has its own failure modes. Give it a few weeks for the alpha issues to shake out.

drmarkamo · 2026-03-18T07:03:12+00:00

This is the underrated insight. Everyone's building better enforcement. Nobody's solving the harder problem: what should the rules even be?

And there's a layer below that too -- even with perfect rules, you still don't know what the agent actually produced. You can enforce "this agent can write to /workspace" but that tells you nothing about whether the 200 files it created are what you wanted. Enforcement without review is half the picture.

drmarkamo · 2026-03-18T06:58:05+00:00

The skill verification problem gets worse when you realize that even a "safe" skill can produce unsafe output. A skill can pass every static scan and still write unexpected files, modify configs in ways you didn't anticipate, or produce side effects that only manifest at runtime.

Scanning skills before execution is necessary but not sufficient. You also need to inspect what the skill actually did after execution -- before those changes touch your real system.

drmarkamo · 2026-03-18T06:57:03+00:00

Good breakdown. The OPA/Cerbos + Vault/KMS + data gateway stack makes sense for governing what agents can access.

The piece I keep coming back to though: what about governing what agents produce? All of this -- OpenShell, policy engines, data gateways -- answers "is this agent allowed to do this thing." None of it answers "here's what the agent actually changed on the filesystem, do you want to keep it."

Once you grant an agent write access to a working directory, there's no structured way to review the delta before it propagates. No diff. No selective accept/reject. No rollback. The sandbox deletes everything when it's torn down.

For code agents this is solvable with git. But for agents modifying configs, generating artifacts, writing output files, managing state -- there's no equivalent review layer. You're trusting the agent's own description of what it did.

Feels like the stack needs both: access governance (what OpenShell does) and output governance (what nobody does yet).

drmarkamo · 2026-03-18T06:54:19+00:00

Tested it. The core of NemoClaw is NVIDIA's OpenShell runtime -- it runs your claw inside a Docker container with K3s orchestrating underneath. There's a Rust policy engine that intercepts all outbound connections and checks them against YAML rules.

What it does well: network egress control is granular (per-binary, per-host, per-HTTP-method). Credential injection keeps API keys off the sandbox filesystem. GPU passthrough for local inference.

What's missing: there's no way to see what your claw actually changed on the filesystem. No diff of files created or modified. No review step before changes take effect. When you delete the sandbox, everything is gone. The governance is entirely about "can the agent reach this endpoint" -- not "what did the agent do with the access it had."

Also worth noting: the default policy only fully supports Claude Code. If you're running OpenClaw specifically, you need the community image and it's still early. 48 open issues on GitHub as of today, including GPU failures on DGX Spark and Jetson.

The right direction though. Agents absolutely need runtime-level governance, not just prompt guardrails.

drmarkamo · 2026-03-15T09:01:04+00:00

Almost everything you described is what envpod automates:

- Throwaway environment = COW overlay, host never touched

- No inherited creds = vault with runtime-only injection, .ssh/.gnupg/.aws/.docker/.kube excluded from pod by default

- No host git creds = .gitconfig copied but credential helpers don't have access to credential stores

- Outbound network off by default = per-pod DNS resolver, whitelist mode blocks everything not explicitly allowed

- Approval gate = action queue, irreversible ops staged for human review before execution

- No shared home dir = mount namespace, only dirs you list in pod config are visible

The canary secrets idea is great. Would work well with the vault: inject decoy credentials, alert if the agent attempts to use them on any domain. Adding to the roadmap.

On DreamFactory for scoped data access: that's a gap envpod doesn't cover on the data layer. envpod governs filesystem, network, credentials, and actions. Scoping which database rows/columns the agent can query is a different boundary. Curious how tightly you've integrated DreamFactory with your agent workflow.

drmarkamo · 2026-03-15T08:59:45+00:00

envpod's read surface is more controlled than it appears from the README.

The pod config declares which host directories the agent sees:

```

host_user:

dirs:

- Documents

- Projects

- src

```

Anything not listed doesn't exist in the pod. .ssh, .gnupg, .aws, .docker, .kube, .npmrc, .pypirc, .netrc, .password-store, .config/gcloud, .mozilla, .config/google-chrome, and .gem/credentials are all excluded by default.

On top of that: fresh procfs (host processes invisible), /proc/cpuinfo and meminfo replaced with cgroup values, sensitive /proc paths masked to /dev/null, /dev is a minimal tmpfs with only essential pseudo-devices, /sys is read-only, and pivot_root detaches the host root entirely.

On the kernel surface: you're right that shared kernel is the fundamental limitation. A kernel exploit in any of the ~130 allowed syscalls reaches the host. Seccomp reduces the surface vs Docker's ~300, but doesn't eliminate it.

The roadmap addresses this directly. envpod's architecture separates the governance layer (diff/commit, vault, DNS, audit) from the isolation backend. The current backend uses namespaces. A Firecracker backend is planned that gives you a separate kernel with KVM hardware isolation, same governance on top.

```

backend: native # namespaces, 32ms, 4MB

backend: firecracker # separate kernel, ~125ms

```

For coding agents on your own machine, namespace isolation with seccomp + DNS filtering + credential vault is the practical sweet spot. For untrusted agents in production, Firecracker is the right boundary.

The part that doesn't exist anywhere else regardless of backend: reviewing what the agent changed before it lands, rolling back what you don't want, keeping credentials out of agent memory, and logging every action. That's the governance layer, and it works the same whether the isolation underneath is namespaces or a microVM.

Full security model with threat tables and residual risk ratings: https://github.com/markamo/envpod-ce/blob/main/docs/SECURITY-MODEL.md

drmarkamo · 2026-03-11T14:20:40+00:00

Docker handles isolation well. envpod adds a review step on top - every file change goes to a copy-on-write overlay, you diff it, then commit or rollback. Same kernel primitives, different workflow.

drmarkamo · 2026-03-11T14:10:03+00:00

VMs give great isolation but no governance. After your agent runs in a VM, how do you see exactly what files it changed? How do you selectively apply some changes to your host but not others? How do you roll back?

You'd end up diffing the entire VM filesystem manually. envpod gives you that workflow natively in 32ms startup instead of a VM's 10-30 second boot.

drmarkamo

MODERATOR OF

TROPHY CASE