Tech Analysis

NVIDIA OpenShell: A Sandbox for AI Agents, Explained

October 2026

The question behind it

AI coding agents run commands on a computer, read and write files, and call the internet, usually with the permissions of whoever started them. After a month of stories about models escaping test environments and a poisoned AI gateway stealing credentials, a practical question follows: how do you let an agent do useful work without handing it everything? NVIDIA’s OpenShell, an open-source project released this year, is one answer. This is an explainer based on NVIDIA’s published documentation. We haven’t run it ourselves, so we describe what it is designed to do, not how well it performs.

What OpenShell is

NVIDIA describes OpenShell as a safe, private runtime for autonomous AI agents. In practice, it launches an agent inside an isolated sandbox and controls what that sandbox can reach. It is released under the Apache 2.0 licence, and the repository had around 7,800 stars when we checked.

Gateway. The control plane that creates and manages sandboxes and acts as the authentication boundary.
Sandbox. An isolated runtime, container-based, where the agent runs, with its outbound traffic forced through a checkpoint.
Policy engine. Enforces rules on files, network and processes, from the application layer down to the kernel.
Privacy router. Sends model requests to backends you choose, intended to keep sensitive context on the sandbox’s own compute.

It runs on Linux, macOS on Apple Silicon, and Windows through WSL 2 (experimental), using Docker, Podman or host virtualization for the sandboxes. Agents it supports out of the box include Claude Code, OpenCode, Codex and GitHub Copilot CLI, with others available through community and NVIDIA catalogues.

How a request is handled

The core idea is a default of almost no outbound access. Every sandbox starts with minimal network access, and you open specific doors with a short YAML policy. Every outbound connection is intercepted and one of three things happens: it is allowed if the destination and program match a rule, it is routed to a managed model backend for inference, or it is denied and logged.

NVIDIA’s quickstart illustrates the granularity. With a read-only policy for a code-hosting API, a request to read data goes through, while a request to create an issue is refused because the policy doesn’t permit that method and path. The policy can be changed on a running sandbox without restarting it. That is a more precise control than simply allowing or blocking a website, and it matters for agents, which often need one narrow capability on a service, not full access.

Four protection layers

Filesystem. Limits reads and writes to allowed paths. Fixed when the sandbox is created.
Process. Blocks privilege escalation and dangerous system calls. Also fixed at creation.
Network. Blocks unauthorised outbound connections. Can be changed while running.
Inference. Redirects model API calls to controlled backends. Can be changed while running.

How credentials are handled

Agents need keys and tokens, and OpenShell bundles them as named “providers” that are injected into a sandbox when it is created. According to the documentation, credentials are not written to the sandbox’s filesystem and are supplied as environment variables at runtime. For model calls routed through its inference path, the system strips the credentials the agent supplied and adds the backend’s own, so the agent doesn’t have to hold the real key for that route.

One observation of ours, not NVIDIA’s: environment variables are visible to the programs running inside the sandbox. So a provider credential protects against leaking to disk and against casual exposure, but it doesn’t make a key unreadable to code the agent runs. That is a good reason to give each sandbox its own narrowly scoped key with a spending limit.

What it doesn’t do

It isn’t finished. The project calls itself alpha software and “single-player mode”: one developer, one environment, one gateway. Multi-tenant enterprise deployment is a goal, not the current state.
Parts are experimental. Windows support, GPU passthrough and the Kubernetes deployment path are marked experimental.
A sandbox is still software. In the Hugging Face incident, OpenAI’s account was that a flaw in a proxy meant to be the only exit was exploited. Containment tools can have bugs too, so layers and monitoring still matter.
Policies are only as good as you write them. A permissive rule gives back the access the sandbox was meant to take away.
Telemetry is on by default. OpenShell collects anonymous usage data about sandbox, provider and policy activity, which it says excludes prompts, credentials, hostnames and file paths. It can be switched off with a setting or compiled out.

If you run coding agents

You don’t need OpenShell specifically to adopt the idea. The habits it encodes apply anywhere:

Start from no network access and add only what a task needs.
Give the agent its own credentials, scoped and spending-capped, rather than yours.
Keep production secrets and personal files out of reach of anything experimental.
Read the logs of what was allowed and denied, because they show what the agent actually tried.
Treat your tools’ own dependencies as part of the risk, as the LiteLLM incident showed.

If you already use a container or virtual machine for agent work, an explicit outbound allow-list is the single change most worth borrowing.

Sources

For disclosure: we use AI tools, including Claude, to help research and draft our posts, and Claude Code, made by Anthropic, is among the agents OpenShell supports. We have no connection to NVIDIA and haven’t tested the software. Details in an alpha project change quickly, so check the current documentation. We are not security professionals, and this is general information, not advice for your setup.

More from Offgrid Studio

LiteLLM Was Compromised Twice. What an AI Gateway Holds
AI Agents Broke Out of Their Tests: What We Know
What Is Your AI App Sending? Watching LLM Traffic

Back to the blog