NVIDIA OpenShell — The Sandbox Your AI Agents Should Be Running In

Your Agent Has Root Access. Do You Know What It's Doing?

I've been running autonomous AI agents in production for months. GitHub Copilot in agent mode, Claude Code, custom multi-agent pipelines — all committed code, triggered workflows, modified infrastructure. The results have been genuinely impressive.

But a few weeks ago, I started staring at a question I'd been avoiding: what exactly can those agents access?

The honest answer was uncomfortable. My Copilot CLI agent could write to any directory it had permissions to. It could make network requests to arbitrary endpoints. It could spawn subprocesses I didn't explicitly authorize. I had instructions, hooks, and gates — three layers of enforcement that made agents structurally better behaved. But all of those layers ran inside the agent process. They were policy-as-suggestion, not policy-as-physics.

Then NVIDIA shipped OpenShell at GTC 2026. And suddenly I had a way to turn those suggestions into walls.

What OpenShell Actually Does

OpenShell is not a container. It's not a VM. It's a policy engine with kernel-level teeth.

When you start an agent inside an OpenShell sandbox, it enforces four protection domains at the OS level — not the application level:

Filesystem isolation via Landlock LSM. The Linux Landlock security module locks allowed paths at sandbox creation. Your agent can only read and write directories you explicitly permit. Not a namespace trick — actual kernel enforcement. There's no os.path.join("..", "..", "etc") that gets around it.

Network control via OPA policy proxy. All outbound traffic routes through an HTTP CONNECT proxy evaluated by Open Policy Agent rules in real-time. Deny-by-default. You declare exactly which hosts, ports, and HTTP methods your agent needs. Everything else is silently blocked.

Process isolation via seccomp BPF. Dangerous syscalls are filtered at the kernel boundary. The agent can't escalate privileges, can't create arbitrary sockets outside the proxy, can't call ptrace on other processes.

Private inference routing. LLM API calls are intercepted by a privacy router that strips the caller's credentials and injects backend credentials. Your agent's context — code, secrets, data — never reaches unauthorized model providers.

The result: even if an agent is compromised, exploited, or just buggy, it physically cannot access things outside the declared policy. Not "it shouldn't." It can't.

The Part That Changes Everything: Policy as Code

OpenShell's killer feature isn't the kernel enforcement — it's that the enforcement is declarative, human-readable, and version-controllable.

Here's what a minimal policy looks like:

# openagent-policy.yaml
filesystem:
  read:
    - /home/user/project
    - /tmp/agent-workspace
  write:
    - /home/user/project/src
    - /tmp/agent-workspace

network:
  outbound:
    - host: "api.github.com"
      ports: [443]
      methods: [GET, POST, PATCH]
    - host: "registry.npmjs.org"
      ports: [443]
      methods: [GET]

process:
  allowed_binaries:
    - node
    - npm
    - git

This policy lives in your repo. It gets reviewed in PRs. It gets updated alongside your code. And — here's the part that made me stop and re-read the docs — it hot-reloads on running sandboxes. Update the file, and the running sandbox immediately enforces the new rules. No restart. No downtime.

If your threat model requires an agent to only ever touch src/ and only ever reach GitHub and npm, you can enforce that exactly. And you can prove it to your security team with a diff.

I Got Involved — Copilot CLI Needed a Provider

When OpenShell launched, it shipped with providers for Claude (via claude CLI), Codex CLI, and OpenCode. Copilot CLI was missing.

That bothered me. I've been building Copilot CLI into everything I do — agentic workflows, terminal automation, PR review loops. Not having first-class OpenShell support felt like a gap worth closing.

So I submitted PR #476 to NVIDIA/OpenShell — a Copilot CLI agent provider.

The implementation followed the established provider pattern but had a few interesting wrinkles:

Credential discovery. Copilot CLI uses GitHub's OAuth flow, so the provider supports automatic credential lookup from COPILOT_GITHUB_TOKEN, GH_TOKEN, and GITHUB_TOKEN in that order. This matches how Copilot CLI itself discovers credentials, so existing token setups just work.

Command detection. Copilot CLI ships as both a standalone binary (copilot) and as a gh extension (gh copilot). The provider detects both forms so the sandbox correctly identifies Copilot invocations regardless of how you've installed it.

Network policy scoping. Because Copilot CLI manages its own API communication to *.githubcopilot.com, the sandbox policy update needed precise endpoint allowlisting — not just "allow GitHub" but specifically the Copilot inference endpoints. The sandbox-policy.yaml updates scope it to the minimum required surface.

The PR also added unit tests for the provider and updated the provider registry documentation. Contributing to OpenShell requires going through their vouch system for first-time contributors — a deliberate friction point that keeps the security posture of the project itself high. Worth noting if you're thinking about contributing.

Running Copilot CLI in OpenShell

With the provider merged, getting Copilot CLI inside an OpenShell sandbox is two commands:

# Create a sandbox with the Copilot CLI provider
openshell sandbox create --provider copilot -- gh copilot suggest "write unit tests for auth.ts"

# Apply a custom policy
openshell policy set my-sandbox --policy openagent-policy.yaml

The agent runs inside the sandbox with your declared policy active. It can suggest code, modify files in allowed directories, make network calls to permitted endpoints — and nothing else. The audit log captures every permitted and blocked action, which is genuinely useful both for debugging and for explaining to stakeholders what the agent actually did.

How This Fits the Agentic DevOps Stack

I've spent a lot of time writing about layered agent enforcement. The model is:

• Layer 1: Instructions — Context engineering, tell the agent what you expect
• Layer 2: Hooks — Intercept tool calls at the moment of action
• Layer 3: Gates — Verify server-side in CI before merge

OpenShell isn't a replacement for any of these layers. It's what I now think of as Layer 0 — the execution boundary that makes every other layer trustworthy. Hooks are more meaningful when the environment they run in is isolated. Gates matter more when you know the agent couldn't have accessed systems it wasn't authorized to touch.

The combination looks like this in practice:

Layer	Mechanism	When	Trust model
0: Sandbox	OpenShell kernel enforcement	During execution	Policy-as-physics
1: Instructions	Context, prompts, harnesses	Before execution	Policy-as-suggestion
2: Hooks	Tool-call interception	At moment of action	Policy-as-logic
3: Gates	CI/CD validation	After execution	Policy-as-verification

Each layer assumes the one below is in place. Hooks are better because the sandbox means there's no escape hatch. Gates are cleaner because you know exactly what the agent could have accessed.

If you're using GitHub Agentic Workflows, you already have a purpose-built sandbox for GitHub's CI environment. OpenShell extends that model to any infrastructure — your staging database, internal APIs, credential stores. Anywhere an agent might go beyond a CI runner.

The State of It

OpenShell is alpha software. Single-player mode. Rough edges. The documentation is sparse in places, and the provider ecosystem is still growing (Copilot CLI is now in it, but don't expect every agent framework to be supported on day one).

That said, the architecture is right. Kernel-level isolation, declarative YAML policies, hot-reload on running sandboxes, Apache 2.0 license. The design choices reflect a serious understanding of what enterprise agent security actually requires — not just containers and hope, but governance infrastructure.

If you're running agents in any sensitive context — production access, internal tooling, credential-adjacent workflows — OpenShell is worth the alpha-software trade-offs right now. The alternative is agents running on trust. And trust doesn't scale.

The Bottom Line

NVIDIA OpenShell is the most architecturally serious entrant in the agent sandbox space because it treats the problem correctly: not as isolation, but as governance. Declarative policies that are versioned, reviewed, and enforced at the kernel level — the same rigor you'd bring to any other piece of infrastructure-as-code.

Contributing the Copilot CLI provider was my way of saying: this is the direction the ecosystem should go. Every major agent should have a first-class OpenShell provider. Every team running agents in sensitive environments should have sandboxes in their stack.

The project is at github.com/NVIDIA/OpenShell. Apache 2.0. Two commands to get started. And if you're using Copilot CLI, the sandbox is ready for you.