01 · NemoClaw User Overview (from the nemoclaw-user-overview skill)

This document is the condensed output of NemoClaw's official nemoclaw-user-overview agent skill. It's the NVIDIA-authored framing of the same material covered across the rest of this walkthrough, useful when you want the "official" pitch and decision table without the conceptual build-up.

The Three Projects

NemoClaw sits above OpenShell in the operator workflow — it drives OpenShell's APIs and CLI to create and configure the sandbox that runs OpenClaw. Models sit behind OpenShell's inference routing; NemoClaw onboarding wires provider choice into that routing.

🦞 NemoClaw  ──orchestrates──▶  🐚 OpenShell  ──isolates and runs──▶  🦞 OpenClaw
(CLI, plugin, blueprint)        (gateway, policy, inference)          (assistant in sandbox)

NemoClaw Path vs OpenShell Path

Both paths assume OpenShell can sandbox a workload. The difference is who owns the integration work.

What NemoClaw Adds Beyond openshell sandbox create --from openclaw

OpenShell already ships a community sandbox for OpenClaw — running openshell sandbox create --from openclaw produces a working isolated environment. NemoClaw layers on:

• Hardened filesystem layout — /sandbox home is read-only; gateway config /sandbox/.openclaw is immutable; only /sandbox/.openclaw-data, /sandbox/.nemoclaw, /tmp are writable.
• Image hardening — strips gcc, g++, make, netcat from the runtime image.
• Credential filtering — blocks provider API keys, DISCORD_BOT_TOKEN, SLACK_BOT_TOKEN, TELEGRAM_BOT_TOKEN from leaking into sandbox creation as build args; stores them as OpenShell providers instead.
• Process limits — ulimit -u 512 in the entrypoint on top of OpenShell's seccomp + privilege dropping.
• Sentry exfil block — POST sentry.io/** is denied entirely (any authenticated client can POST to any Sentry project, so path allowlists can't help).
• Blueprint versioning — digest-pinned, compatibility-checked, reproducible across machines.
• State migration — snapshot/restore across machines with credential stripping and integrity verification.
• Automated channel wiring — bot tokens collected at onboarding, registered as OpenShell providers, OpenClaw config baked with placeholders that the L7 proxy resolves at egress.
• Guided onboarding wizard — validates credentials from the host, picks providers, configures inference routing in one command.

When to Use Which

The Three Scenarios — A Beginner's Walkthrough

The sections above give the official framing. This section walks through the same material as three concrete scenarios, with side-by-side tables, so you can see exactly what changes at each level.

Scenario A: OpenClaw standalone (no OpenShell, no NemoClaw)

Your laptop
├── OpenClaw Gateway (running as YOU, with YOUR permissions)
├── Your files (fully accessible)
├── Your network (fully open)
├── Your API keys (in env vars or config files)
└── Your messaging tokens (Telegram, Slack, etc.)

OpenClaw runs directly on your machine. It has full access to your filesystem, your network, your real API keys, and runs as your user account. It's like hiring a brilliant assistant and giving them the keys to your house, your car, and all your passwords. OpenClaw does have its own application-layer defenses (prompt injection filtering, tool deny lists, DM pairing, openclaw security audit), so it's not reckless — but the perimeter is your laptop itself.

Scenario B: OpenShell + OpenClaw (manual setup, no NemoClaw)

Your laptop (host)
├── OpenShell gateway (control plane)
│   ├── Credential store (real API keys live HERE)
│   ├── L7 proxy (inspects all traffic)
│   ├── Policy engine (your YAML rules)
│   └── Inference proxy (model routing)
│
└── Sandbox container (isolated)
    ├── OpenClaw Gateway (thinks it's on a normal machine)
    ├── Restricted filesystem (you decide what's writable)
    ├── Restricted network (deny-all by default)
    ├── Placeholder credentials (not real keys)
    └── Runs as user "sandbox" (not as you)

You manually run openshell sandbox create --from openclaw, write your own policy YAML files, set up providers, configure inference routing, and decide which hosts to allow. It's like building your own secure office from scratch — you pick the locks, write the guard's rulebook, and decide the floorplan. Flexible, but you own every decision.

Scenario C: NemoClaw (the full NVIDIA stack)

Your laptop (host)
├── NemoClaw CLI (orchestrates everything below)
│   └── calls OpenShell under the hood
├── OpenShell gateway (same as Scenario B, but configured BY NemoClaw)
│   ├── Credential store
│   ├── L7 proxy
│   ├── Policy engine (NemoClaw's hardened policies)
│   └── Inference proxy
│
└── Sandbox container (hardened beyond OpenShell defaults)
    ├── OpenClaw Gateway
    ├── Read-only home directory
    ├── No compilers (gcc, g++, make, netcat removed)
    ├── Process limit (max 512 processes)
    ├── Curated network allowlist
    ├── Placeholder credentials
    └── Runs as user "sandbox"

You run one command: nemoclaw onboard. It handles everything.

Side-by-side: setup experience

Side-by-side: where credentials live

With manual OpenShell, if you accidentally pass --env TELEGRAM_BOT_TOKEN=real-token during sandbox creation, the real token lands in the container. NemoClaw actively strips known credential env vars from the creation command — a guardrail against operator mistakes, not just agent mistakes.

Side-by-side: filesystem security

Why strip compilers? If an agent is compromised, having gcc means an attacker could compile custom binaries to probe sandbox defenses. Removing them raises the bar. This is NemoClaw-specific hardening the community OpenShell sandbox doesn't do.

Side-by-side: network policies

Side-by-side: process isolation

Side-by-side: reproducibility

The blueprint digest-pinning (sha256:b3d832b... in blueprint.yaml) means every machine running nemoclaw onboard with that blueprint gets the exact same container image, policies, and configuration. This is what makes fleet deployment auditable — your security team can verify one blueprint and know it applies everywhere.

Side-by-side: day-to-day operations

What stays the same across ALL three

OpenClaw's application-layer defenses work identically everywhere:

• Prompt injection filtering (regex, boundary wrapping, unicode folding)
• Tool deny list (exec, shell, fs_write blocked from Gateway HTTP by default)
• Environment variable blocklist (NODE_OPTIONS, LD_PRELOAD, etc.)
• DM pairing (unknown senders need approval codes)
• openclaw security audit (50+ automated security checks)
• Skill/extension supply-chain scanning
• Rate limiting and flood protection
• CLI secret redaction

These are baked into OpenClaw itself. NemoClaw doesn't add to them or change them.

Presentation-ready summary

OpenClaw is the AI assistant. Running it standalone gives you app-level safety. Adding OpenShell gives you infrastructure-level isolation — but you write every policy. NemoClaw gives you NVIDIA's battle-tested policies out of the box, with a single command, reproducible across your entire fleet.

Core Capabilities

The Core Challenge It Solves

Autonomous AI agents like OpenClaw can make arbitrary network requests, touch the host filesystem, and call any inference endpoint. Without guardrails, that creates security, cost, and compliance risks that compound as agents run unattended. NemoClaw gives you a single CLI (nemoclaw) that orchestrates the full stack — gateway, sandbox, inference provider, and network policy — so those guardrails come on by default and stay reproducible across machines.

Next: 02-mental-model.md — the unified stack model, end to end.