NVIDIA OpenShell: Policy-Enforced Sandboxes for Autonomous Coding Agents

Every coding agent you run today — Claude Code, Codex, OpenClaw — inherits your shell permissions, your SSH keys, your cloud credentials. You already know this. What you might not have internalized is that there is no enforcement layer between the agent and your infrastructure. The approval prompts are UI sugar. A prompt injection in a malicious dependency's README bypasses all of them, and your agent happily exfiltrates your .env to an attacker-controlled endpoint while you watch the spinner.

NVIDIA announced OpenShell and NemoClaw at GTC 2026. They take a fundamentally different approach to this problem — out-of-process policy enforcement that the agent cannot override even if it is compromised. I spent the last week running agents inside OpenShell. Here is what it actually does and where it fits.

Why your agent needs a sandbox (and why system permissions are not enough)

The standard advice is "run your agent in a container." That is necessary but insufficient. A Docker container with default settings still lets the agent:

• Read every file mounted into the container
• Make arbitrary outbound network requests (exfiltrating your code, credentials, or data)
• Install and execute any binary
• Send your proprietary code to whichever LLM endpoint it wants
• Escalate privileges if the container runtime has known CVEs

The 2025 incident graveyard shows this is not theoretical:

• Amazon Q VS Code extension (CVE-2025-8217) — an attacker compromised a GitHub token in the CI/CD pipeline and injected malicious code into the official extension build. The compromised v1.84.0 was distributed through Amazon's legitimate release process. The payload targeted Q CLI calls but failed to execute due to a syntax error — a lucky break, not a security control.
• n8n sandbox escape (CVE-2026-25049, CVSS 10.0) — researchers exploited flaws in the expression sandbox's AST sanitizer to achieve full RCE, extract the N8N_ENCRYPTION_KEY, and decrypt every stored credential (AWS keys, AI API tokens, database passwords).
• The official Git MCP server — three CVEs allowed path traversal, argument injection, and path validation bypass. Chained together via prompt injection, they enabled arbitrary command execution on developer machines through malicious .git/config files — the exact attack that out-of-process policy enforcement would block.

These are the default outcome when agents run with your permissions and no infrastructure-level enforcement.

What you actually need is policy enforcement at the infrastructure level — constraints that the agent cannot override, reason away, or prompt-inject around.

NVIDIA OpenShell: architecture

OpenShell is not a container runtime. It is a governance layer that wraps existing agents (Claude Code, OpenClaw, Codex, OpenCode) in policy-enforced isolation without requiring code changes to the agent itself.

How it works

The architecture runs a K3s Kubernetes cluster inside Docker. Three components handle isolation:

Gateway — the control-plane API that manages sandbox lifecycle, authentication boundaries, and credential injection. When you run openshell sandbox create -- claude, the gateway provisions an isolated environment, injects your API keys as environment variables (never as files), and applies your policy.

Sandbox — the isolated container where your agent actually runs. It ships with Python 3.13, Node.js 22, git, gh CLI, and common editors. The sandbox has no outbound connectivity by default — every connection must be explicitly allowed by policy.

Policy Engine — the critical differentiator. It enforces constraints across four layers, operating outside the agent's process space:

The "immutable at creation" vs "hot-reloadable" split is a deliberate design choice. Filesystem and process policies define the security boundary — changing them requires destroying and recreating the sandbox. Network and inference policies are operational controls that need to adapt as the agent's task evolves.

The privacy router

Most sandboxes treat LLM API calls as just another outbound HTTP request. OpenShell treats them as a distinct policy domain.

The privacy router intercepts inference calls and makes routing decisions based on organizational policy:

• Sensitive code context gets routed to a local Nemotron model running on your GPU (or local vLLM/Ollama instance)
• General queries can route to frontier models (Claude, GPT) when policy permits
• Credential stripping happens automatically — the router removes any caller-injected API keys and injects backend-appropriate credentials

This means your agent can use Claude for reasoning and a local model for code that touches proprietary algorithms, and the agent itself never makes that decision. Policy does.

Configure it with:

openshell inference set --provider nim --model nvidia/nemotron-3-super-120b

Or route to a local Ollama instance:

openshell inference set --provider ollama --model codellama:34b

Policy as YAML

Policies are declarative YAML files. Here is a realistic example for a coding agent working on a specific project:

# Static policies (locked at sandbox creation)
filesystem:
  allow_read:
    - /workspace/my-project/**
    - /usr/lib/**
    - /usr/local/lib/**
  allow_write:
    - /workspace/my-project/src/**
    - /workspace/my-project/tests/**
    - /tmp/**
  deny_read:
    - /workspace/my-project/.env
    - /workspace/my-project/secrets/**

process:
  allow_binaries:
    - /usr/bin/python3
    - /usr/bin/node
    - /usr/bin/git
    - /usr/bin/npm
  deny_capabilities:
    - CAP_SYS_ADMIN
    - CAP_NET_RAW

# Dynamic policies (hot-reloadable)
network:
  egress:
    - destination: api.anthropic.com
      ports: [443]
      binary: /usr/bin/curl
    - destination: registry.npmjs.org
      ports: [443]
      binary: /usr/bin/npm
    - destination: '*.github.com'
      ports: [443]
      binary: /usr/bin/git

inference:
  routes:
    - pattern: '*.py'
      backend: local/nemotron
    - pattern: '*'
      backend: anthropic/claude-sonnet

Apply it:

openshell policy set my-sandbox --policy ./agent-policy.yaml

Update the network section without restarting:

openshell policy set my-sandbox --policy ./updated-policy.yaml

The engine evaluates every action against binary, destination, method, and path. When an agent hits a denied action, it receives a clear error — and well-designed agents like Claude Code can reason about the constraint and propose a policy update for you to approve.

Getting started

# Install
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

# Create a sandboxed Claude Code session
openshell sandbox create -- claude

# Or run OpenClaw from the community catalog
openshell sandbox create --from openclaw

# Connect to a running sandbox
openshell sandbox connect my-sandbox

# Monitor everything
openshell term

The openshell term command launches a k9s-inspired terminal dashboard that shows running sandboxes, policy violations, and connection logs in real time.

GPU passthrough

For local inference or ML workloads:

openshell sandbox create --gpu -- claude

This requires the NVIDIA Container Toolkit on the host and passes GPU devices into the sandbox. The agent can run inference locally while the policy engine still controls which models and endpoints are accessible.

NemoClaw: the enterprise wrapper

NemoClaw is not a separate product. It is a plugin that bundles OpenShell with NVIDIA's Nemotron models and Agent Toolkit into a single installable stack. Think of it as OpenShell for organizations that want NVIDIA's full inference stack out of the box.

What NemoClaw adds:

• Nemotron model integration — one-command setup of Nemotron 3 Super 120B via build.nvidia.com or local NIM/vLLM
• Agent Toolkit — framework for building custom agents that automatically run inside OpenShell sandboxes
• Intent verification — a proactive validation layer that checks agent actions against policy before execution, not just blocking after the fact
• Audit logging — compliance-grade logging of every action, decision, and policy evaluation
• Role-based access control — enterprise identity management integration
• Telegram bridge — communicate with sandboxed agents via Telegram (surprisingly useful for long-running tasks)

Install and run:

openshell sandbox create --from openclaw

What OpenShell defends against

OpenShell does not solve every threat model — it makes specific bets. Here is what it actually defends against well, and where its limits are.

Agent exfiltrating sensitive data

OpenShell controls egress per-destination AND per-binary. It is the only sandbox I know of that treats inference calls as a distinct data channel with its own routing policy. If your agent processes proprietary code and you need to guarantee that code never reaches a third-party LLM endpoint, the privacy router enforces this at the infrastructure level — not as a policy document developers can ignore.

Credential theft via prompt injection

OpenShell injects credentials as environment variables and never writes them to the filesystem. Combined with filesystem policy that blocks reads outside permitted paths, a prompt injection attack cannot extract credentials from config files or shell history. The agent itself never has the credentials in a place it can leak them.

Supply chain attacks via malicious packages

OpenShell can restrict which binaries execute and which registries the agent can reach. You can allowlist npm but restrict it to registry.npmjs.org only, preventing the agent from adding alternative package sources mid-task.

Where OpenShell is weaker

OpenShell uses shared-kernel containers with eBPF/seccomp hardening. This is weaker against kernel-level escapes than dedicated-kernel sandboxes (microVMs). If your threat model is "untrusted code from arbitrary users running in shared infrastructure," OpenShell is not the right choice. Its bet is that for autonomous coding agents running your own trusted code with potentially-compromised inputs, policy semantics matter more than isolation depth.

Hands-on: running Claude Code in OpenShell

Here is what the actual experience looks like.

Setup (macOS/Linux)

# Install OpenShell
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

# Verify Docker is running
docker info > /dev/null 2>&1 && echo "Docker OK" || echo "Start Docker first"

# Create a Claude Code sandbox (auto-detects ANTHROPIC_API_KEY)
openshell sandbox create -- claude

The first run takes a few minutes — it pulls the base image and starts the K3s cluster. Subsequent sandbox creation is faster.

Inside the sandbox

Once inside, Claude Code runs exactly as it does on your host. The difference is invisible until you hit a policy boundary:

Claude> Let me check the project structure...
Claude> I'll install the required dependencies...
[POLICY DENIED] Binary /usr/bin/pip not in process allowlist.
Claude> I see that pip is restricted. I can use the allowed package
       manager instead. Let me check what's available...

The agent adapts. It reads the policy denial, reasons about alternatives, and adjusts its approach. This is the intended interaction model — the agent operates autonomously within defined boundaries and surfaces constraint violations as decision points for the developer.

Monitoring

In a separate terminal:

# Real-time dashboard
openshell term

# Or stream logs for a specific sandbox
openshell logs my-sandbox --tail

The dashboard shows every allow/deny decision, which lets you iteratively refine policies. Start restrictive, observe what the agent actually needs, and relax policies incrementally.

What OpenShell gets wrong (for now)

No tool review is complete without the rough edges.

Alpha software. The project is still early — documentation exists but has gaps, and I had to read source code for several policy schema details.

No Windows native support. Requires WSL2 or a Linux VM.

Single-player mode only. The architecture supports multi-tenant, but right now it is one developer, one gateway, one environment. Enterprise teams will need to wait.

Startup is slow compared to cloud sandboxes. The K3s bootstrapping adds seconds. For batch workloads with thousands of short-lived sessions, this is a dealbreaker.

No computer use support. OpenShell is terminal-only. If your agent needs to interact with GUIs, this is not the right tool yet.

GPU support requires NVIDIA hardware. The local inference story is compelling but only works if you have NVIDIA GPUs. No AMD, no Apple Silicon GPU passthrough.

The bigger picture

What I find most interesting about OpenShell is the privacy router. Every organization I have talked to about agent adoption raises the same concern: how do I make sure my proprietary code does not end up in someone else's training data? OpenShell is the first sandbox I have seen that treats this as an infrastructure problem rather than a policy document problem.

Run openshell sandbox create -- claude on a machine with a GPU, point the inference router at a local model for sensitive contexts, and you have a coding agent that is genuinely private-by-default. That is a new capability, not just a new wrapper.