Design Philosophy

NemoClaw is architected around a single principle: out-of-process policy enforcement. Rather than embedding guardrails within the agent (which can be circumvented), constraints are enforced at the runtime environment level, outside the agent's reach. This is comparable to browser tab isolation -- a malicious web page cannot read your passwords because the browser sandbox prevents it at the process level, not because the page chooses not to.

The architecture spans three operational levels -- host, runtime, and sandbox -- with two core components (a TypeScript plugin and a Python blueprint) bridging them. This separation ensures security-critical components live outside the agent's execution environment.

System Architecture

NemoClaw Three-Level Architecture

💾
Credential Store
Host-side secrets
💬
Messaging Bridges
Telegram / Discord / Slack
⌨️
NemoClaw CLI
User interface
🛡️
OpenShell Gateway
Policy enforcement
🛤️
Privacy Router
Inference routing
📜
Policy Engine
YAML-based rules
📦
Sandbox Container
Hardened isolation
🤖
OpenClaw Agent
AI assistant
🔌
NemoClaw Plugin
In-sandbox agent

Click any component to see details. Top row = Host Machine, middle row = OpenShell Runtime, bottom row = Sandbox Container.

Protection Architecture

NemoClaw enforces security through four layers, deliberately split between immutable (locked at creation) and hot-reloadable (adjustable at runtime) policies.

LayerControlsMechanismMutability
NetworkOutbound connectionsYAML allowlist + namespace isolationHot-reloadable
FilesystemFile read/write accessLandlock LSMLinux Security Module that restricts filesystem access at the kernel level. Cannot be overridden from userspace.Locked
ProcessSystem calls, privilege escalationseccompLinux kernel feature that filters system calls. Blocks dangerous operations like ptrace, mount, and reboot. + capability dropsLocked
InferenceModel API routingOpenShell gateway interceptionHot-reloadable
⚠️
Why the split? Filesystem and process restrictions are immutable because they are foundational security boundaries. Allowing runtime changes would enable a compromised agent to weaken its own restrictions. Network and inference policies are hot-reloadable because operational needs change -- approving a new API endpoint or switching inference providers should not require rebuilding the sandbox.

Two Core Components

TypeScript Plugin (CLI)

A thin Commander.js package that registers the nemoclaw command and an inference provider. It handles command registration, blueprint resolution and verification, persistent state tracking, SSRF validation, and migration snapshots. The plugin is intentionally minimal -- it contains no security logic itself, keeping the attack surface small.

Python Blueprint

A versioned artifact with its own release cycle that the plugin resolves, verifies (via SHA-256 digest), and executes as a subprocess. It handles all OpenShell CLI interactions through a five-stage lifecycle: Resolve (version constraint checking), Verify (digest validation), Plan (resource determination), Apply (CLI command execution), and Status (state reporting).

💡
Why separate? Security policies need to evolve faster than the CLI. When a new vulnerability class is discovered, only the blueprint needs updating. The plugin's digest verification ensures you always run an authentic, untampered blueprint.