OpenClaw isn't fooling me. I remember MS-DOS

OpenClaw isn’t fooling me. I remember MS-DOS.

The sad days of DOS. Any program could peek and poke the kernel, hook interrupts, write anywhere on disk. There was no safety.

The fix wasn’t a wrapper, or a different shell. It was a whole different approach to what was being done. The world already had rings, virtual memory, ACLs, separate address spaces. Thirty years of separations that Unix had from the start were ignored, and it finally caught up to the world of DOS.

I’m not saying DOS wasn’t wildly popular. Oh my god. I remember one dark night in a bar in Chicago, a drunk Swedish IT consultant jumped onto a table and said “listen up everyone!”. As he waved his beer mug around, sloshing carelessly, with wobbly legs, he said he was in town to work on Wal-Mart Point-of-sale (POS) devices running MS-DOS. Why was he acting like this? He was happy, very, very happy. He wanted us to know he loved his work, something like “CAN YOU BELIEVE WAL-MART HAS HUNDREDS OF THOUSANDS OF DOS MACHINES WITH ALL YOUR F$%#$%NG PAYMENT CARD DATA?! HAHAHA! AND IT ALL HAS ONE PASSWORD THAT EVERYONE SHARES! YOU WANT IT?! I GOT IT RIGHT HERE! FREEDOM, AMERICA, F$#%$K YEAH!”

True story. Both the guy and Wal-Mart put ALL customer information on MSDOS with exactly zero safety.

NCR had just announced a new MS-DOS-based PC…we decided to build a custom solution for Wal-Mart. I managed to connect a cash drawer and a POS printer to the new PC and wrote a dedicated Layaway application in compiled MS Basic. For the first time, Wal-Mart could store customer info on a disk. A clerk could search by name in seconds, and more importantly, the system tracked exactly where the merchandise was tucked away in the backroom. It was a massive efficiency win, and NCR ultimately rolled it out to all Wal-Mart stores.

Personal identity information was never breached faster! Massive efficiency win, indeed. When Wal-Mart was breached in 2006 they naturally had to wait three long years to notify anyone. So efficient.

Agent gateways feel like we are racing backwards into the MS-DOS era. At any minute in a bar I expect a drunk Swedish IT consultant to be standing on a table waving a lobster around, swearing about his single token for all agents. Because, let’s face it, when you look at gateways out there they can hand the model an exec tool and trust it. One process, one token, with the LLM holding the line.

NVIDIA clearly has seen the storm brewing and therefore published a thoughtful tutorial walking through a “NemoClaw” self-hosted agent setup on DGX Spark.

Use NVIDIA DGX Spark to deploy OpenClaw and NemoClaw end-to-end, from model serving to Telegram connectivity, with full control over your runtime environment.

I appreciate this effort. Real engineering, carefully done. I took the tutorial to learn and I followed it in Wirken, a gateway I’ve been building, to document what each step looked like.

The tutorial has you bind Ollama to 0.0.0.0 so the sandboxed agent can reach it across a network namespace. Then it pairs the Telegram bot by sending a code through the chat channel. It next approves blocked outbound connections in a separate host-side TUI. Each of those seem to be steps to address a real problem, which is how to put security around something that doesn’t work when it has security around it. It’s what an architecture requires when the sandbox sits around the whole agent.

Call me old-fashioned but I anticipated a lot of this in Wirken by giving the agent more safety by shrinking the boundaries. Each channel is a separate process with its own Ed25519 identity. The vault runs out of process. Inference stays on loopback because the agent is on the host. Shell exec runs in a hardened container configured at the tool layer, rather than trying to wrap around the whole agent. Sixteen high-risk command prefixes prompt on every call; others are first-use with a 30-day memory.

Here’s what I found, step by step

| Step | NemoClaw | Wirken.AI | |---|---|---|

1. Runtime | Register the NVIDIA container runtime with Docker, set cgroup namespace mode to host. Foundational setup because the agent runs inside a container. | No equivalent step. The gateway runs as a host process. Docker appears only as a per-tool-call sandbox for shell exec, provisioned lazily. |
2. Ollama | Override OLLAMA_HOST to 0.0.0.0 so the sandboxed agent can reach inference across its own network namespace. | Ollama stays on 127.0.0.1. The agent is a host process, so loopback is enough. |
3. Install | curl-pipe-bash from an NVIDIA URL. | curl-pipe-sh as well. The installer verifies the release signature with ssh-keygen against an embedded key, fail-closed on every failure path. The installer’s own SHA is pinned in the README for readers who want to check the script before piping. |
4. Model | ollama pull the model, then ollama run to preload weights into GPU memory. | Same pattern. Both delegate inference to Ollama. |
5. Onboarding | Wizard produces a sandbox image with policy and inference baked in, as a named rebuildable unit. | Wizard writes provider config and channel registrations. The permission model lives in the binary; runtime state is which action keys have been approved. |
6. Telegram | Pairing code sent through the chat channel; user approves from inside the sandbox. Binds a platform user to the agent at first contact. | Bot token into an encrypted vault, fresh Ed25519 keypair for the adapter, no in-chat pairing. Approval granularity is per action and per agent rather than per channel user. |
7. Web UI | Localhost URL with a capability token in the fragment, not shown again. | Localhost URL, loopback-bound, no token required. |
8. Remote access | Host-side port forward started through OpenShell, then SSH tunnel. The extra hop is because the UI lives inside a netns. | SSH tunnel only. The WebChat listener is already on host loopback. |
9. Policy | Enforces at the netns boundary. Outbound connections are surfaced in a TUI with host, port, and initiating binary. Approve for the session or persist. | Enforces at the tool dispatch layer. Sixteen high-risk command prefixes always prompt; others are first-use, remembered 30 days. Approved commands run inside a hardened Docker container with cap_drop ALL, no-new-privileges, read-only rootfs, 64MB tmpfs at /tmp, and no network. |

Looking at my audit logs

The architectural claims above are recorded in the logs of the tutorial work. Wirken uses a hash-chained audit database of the webchat session, so here’s what that looked like in version 0.7.5.

First, the Tier 3 denial on curl:

[ 4] assistant_tool_calls call: exec({"command":"curl https://httpbin.org/get"}) [ 5] permission_denied action_key='shell:curl' tier=tier3 [ 6] tool_result tool=exec success=False output: Permission denied: 'exec' requires tier3 approval. [10] attestation chain_head_seq=9 chain_head_hash=ff57c574ab503a74fa942ddb164def0df5bfbff05e5d5d6ecadcf127bce7e021

The tool call never reached the sandbox. The denial is recorded as a typed event in the audit chain, covered by the per-turn attestation.

Second, the hardened sandbox on sh. With shell:sh pre-approved at Tier 2, the same agent runs a compound command that probes three locations:

[14] assistant_tool_calls call: exec({"command":"sh -c "touch /cannot_write_here 2>&1; ...""}) [15] tool_result tool=exec success=True output: touch: cannot touch '/cannot_write_here': Read-only file system ws_ok=1 tmp_ok=1 [19] attestation chain_head_seq=18 chain_head_hash=6bf35f22df02b496244091e54b4dbf9b3ffdcf6a03485413f0522b84e2eb08a8

Read-only file system is the kernel refusing to open a new file against a read-only mount. Not a DAC check, the rootfs itself. ws_ok=1 confirms the workspace bind-mount stayed writable. tmp_ok=1 confirms the tmpfs at /tmp did too.