NVIDIA Just Built a Sandbox That Knows When to Say No (Openshell)

Author: Better Stack · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: NVIDIA Just Built a Sandbox That Knows When to Say No (Openshell) · Channel: Better Stack · 07:17 · Watch on YouTube

Topics: AI agents, Cybersecurity and software security, AI developer tools, AI infrastructure and hardware, AI safety

Summary

NVIDIA OpenShell is an open-source, Apache 2.0 sandbox designed to control what AI agents can do with files, processes, and network endpoints, rather than merely limiting where they can go. Its supervisor enforces policies, logs denials, and injects credentials only for approved requests, while a Z3 solver checks policy changes before they take effect. The video demonstrates default-deny network access and a rule that allows read-only GitHub access but blocks creating an issue. It also covers trade-offs and caveats, including default-on telemetry, Mac setup requirements, reported failures, and the project’s early-preview status.

Key points

OpenShell is open-source, Apache 2.0 software written in Rust, and does not require an NVIDIA GPU.
Its three components are a gateway, a supervisor that makes policy decisions, and the agent’s sandbox.
File-system and process restrictions are enforced at the kernel level and cannot be weakened by the agent at runtime.
Network access is denied by default; policies can allow specific binaries to access particular endpoints and perform specified actions.
The demonstration allows curl to read from the GitHub API but blocks a POST request to create an issue.
The supervisor injects real credentials only for approved requests, so the agent does not see the credentials directly.
Every denial is logged, and a Z3 solver checks what additional access a policy change would grant before it goes live.
OpenShell can run on Docker, Podman, Kubernetes, and a small micro VM, adding controls on top of those environments.
The video notes that telemetry is on by default, Mac sandboxes require Linux VM features and host networking, and NVIDIA reported that about 12% of sandbox creations failed in a two-week period.
The presenter says simpler options may be easier for quick laptop sandboxes, while OpenShell’s per-request controls may suit agents handling real credentials.

Chapters

Start	Chapter	Summary
00:00	Why containers aren’t enough	The video introduces the limits of ordinary containers and explains OpenShell’s gateway, supervisor, and sandbox design.
01:33	Testing sandbox policies	A live demonstration shows unprivileged execution, blocked file access, default-deny networking, and policy updates for GitHub access.
03:09	Credential protection and policy checks	The presenter demonstrates that read access does not allow GitHub issue creation, explains credential injection, and describes Z3 policy checking.
05:14	Comparisons, caveats, and who should use it	The video compares sandbox options, reviews OpenShell’s telemetry, setup, and maturity caveats, and offers guidance on when its controls may be useful.

Quotes

Nvidia just shipped an open-source sandbox that can tell the difference. — 00:00

Now, out of the box, the sandbox can’t reach anything at all, default deny. — 02:06

Not can it reach GitHub, but what is the specific process allowed to do there? — 03:09

It never had the key to begin with. — 04:11

What is the agent allowed to do with that? — 07:17

Concepts and entities

OpenShell, NVIDIA, Rust, Z3, Docker, Podman, Kubernetes, Anthropic sandbox runtime, GitHub API, landlock

Full transcript (original language)

00:00 If we drop an AI agent in a Docker container, hand it a GitHub token, that container can’t tell whether your agent is reading your repo or opening issues on it. To the container, it’s all just traffic to the same address. Nvidia just shipped an open-source sandbox that can tell the difference. And no, you don’t need an Nvidia GPU cuz I’m running it on a Mac. The core problem here is so many people

00:30 are just running agents in any mode, really. Cloud, code, Codex, open code, run it, approve nothing, and do something else while it’s running. If we want that agent to be useful, then that agent needs your files, your packages, APIs, and your credentials. And today, a lot of people just hand them everything cuz it’s easier. A container is a locked room. It stops the agent wandering into the rest of your machine. But once you hand the agent a key, well, they can go anywhere they want. That’s what Open

01:01 Shell is for. It’s open-source Apache 2.0 written in Rust. You write a policy for what each agent is allowed to touch, and it checks every file access, every system call, and every network connection against it. There are three pieces to all this that make it actually work. A gateway, which is what you talk to, a supervisor, a trusted bouncer that makes every decision, and the sandbox where the agent lives. The sandbox’s only door to the outside world goes through the bouncer, that supervisor.

01:33 Let me show you. If you enjoy coding tools that speed up your workflow, be sure to subscribe. We got videos coming out all the time. Okay, so I spin up the sandbox right here after it’s installed with sandbox status to check it, and run this command here. Right away, you see it runs unprivileged. So, who am I? ID, right? It can’t escalate. And file system access is locked at the kernel level. Try to write outside the paths it was given, so I can touch a file right here, and we get denied. It can only

02:06 touch what the policy allows. So, if I go into the temp folder and it’s working directory, that could be allowed. Those file system and process rules are fixed when the sandbox starts. The agent itself can’t weaken them. Now, I try to hit the GitHub API from inside it right here with curl. What do we expect? Denied. I can run that here in terminal two just to check those logs. Now, out of the box, the sandbox can’t reach anything at all, default deny. That’s the point here. Over in another terminal, where my logs are here, that’s

02:38 what’s telling me exactly what happened. I can fire up those open shell logs and we can see a backtrace of that. Curl tried to reach api.github.com on this port, it got blocked. Every denial is logged, so nothing is silent. Now, I can add one rule. Curl can reach the GitHub API, read only. I don’t have to restart anything. I can run this command right here, openshell policy update, and I can update that whole thing. Now, let’s fire back that same command.

03:09 I’ll run the curl command to access GitHub, and it works. Now, same tool, same address, but this time a post to create an issue. We’ll fire up a post to create that issue, and because we didn’t allow it, we get denied. That’s the line a container can’t draw. Not can it reach GitHub, but what is the specific process allowed to do there? The rule is tied to the binary. A different process doesn’t give the same permission. And the agent never

03:39 sees real credentials. That has important. Open shell injects them only for requests that hit an approved endpoint. That’s the control point for an agent, kernel enforced file system and process limits that can’t be weakened at runtime. Plus, network rules that say exactly which binary can do what on which endpoint, with a full audit trail of every decision. A normal container, right? We can’t draw those lines on those. Your agent never sees your real credentials. The supervisor adds them on

04:11 the way out. So, if someone prompt injects your agent and tells it to leak your API key, there’s nothing to leak. It never had the key to begin with. The sandbox doesn’t even look up its own domain names. The supervisor resolves DNS and opens only the approved connections. Underneath, Open Shell runs on Docker, Podman, Kubernetes, and a tiny micro VM. It’s not going to replace your container. It’s just like a set of rules. Then there’s the part I’d expect from a sandbox at all, approver. Before

04:41 policy change goes live, Open Shell feeds it to a Z3 solver, a math engine, to work out what new access that change would actually grant. Policy files with one wildcard nobody thought though. This checks the rule before you trust it with an a 10-second default time limit. Now, Open Shell itself, it went public in February. Nvidia announced it at GTC in March with Cisco, CrowdStrike, Google Cloud, and Microsoft Security as partners. Big names. And it has a little over 20,000 stars on GitHub. Nvidia’s

05:14 own telemetry reports says that in 2 weeks this summer, it created over 550,000 sandboxes and denied 4.2 million agent actions. 4.2 million times an agent tried something the policy said no. Those are Nvidia’s numbers, not an audit, but that’s a lot of no’s. So, how is this different from what we already got? Cuz let’s face it, we got a lot out there, but they aren’t all the same. Docker, Firecracker, Apple’s container, those are walls. Open Shell runs on top

05:45 of them and adds the per request rules, the key injection, and the audit log. And the Tropic sandbox runtime is the lightweight option. Per process file and network limits, much less setup. E2B and Daytona are hosted throwaway sandboxes for running a bit of code. Open Shell is self-hosted, policy-first, and built for agents that run for hours. We got to look at a few things here though first. First, telemetry is on by default. It’s anonymous counts and it’s one environment variable turns it off. I’d

06:17 turn it off. Then, on a Mac, the sandboxes are still Linux. They run inside Docker Desktop’s virtual machine and that machine needs a kernel feature called landlock plus host networking switched on, which is off by default. Open Shell’s own Docker command says everything’s green either way, so test it first. Next up, Nvidia’s own telemetry shows about 12% of sandbox creations failing in that same two-week window. Their blog calls it an early

06:47 preview. The readme says stable weekly releases, but its version is only 0.1.5. Believe the version number, so try it out. And then finally, a sandbox is not some guarantee. It’s just controls what an agent can reach. Remember these. Are you going to use it? Well, maybe yeah. If you just want a quick sandbox for cloud code on your laptop, honestly, Anthropic sandbox runtime or plain containers is a lot less work. Maybe just stick with that. But if you’re handing actual credentials to agents,

07:17 especially if you’re just running agents like wild, the per request rules in the agent never sees the key design, those are real because sandboxes used to answer one question. Can the agent reach it? This one answers the question that actually matters. What is the agent allowed to do with that? I’m Josh from BetterStack. If you enjoy coding tips and tricks like this, be sure to subscribe. We’ll see you in another video. >> [music]