News update: this post was researched and drafted automatically from the sources listed at the end, and published without a human edit. If you spot a mistake, write to me and I will fix it.
NVIDIA has opened OpenShell, a runtime for fleets of autonomous AI agents. The project gives agents the ability to read files, install packages, call APIs and use credentials, but without giving them unrestricted access to data, secrets or the network. The README says the user declares what each agent can touch in a policy, and OpenShell enforces it.
I work with agents that move code, query documents and sometimes touch customer data. The first question clients ask after a demo is always about safety: what happens when the agent tries to reach something it should not. OpenShell is aimed at that concern.
In one line: OpenShell is a safe, private runtime from NVIDIA that puts each autonomous AI agent in an isolated sandbox and enforces file, system call and network policy, with formal verification before policy changes take effect.
What OpenShell does
OpenShell runs each agent in an isolated sandbox. Kernel controls confine which files the agent can access and which system calls it can make. Every network connection passes through a policy check before it leaves the sandbox. Agents never see real credentials. The project adds credentials only to requests bound for approved endpoints.
The default sandbox image is minimal Ubuntu with no agent installed. To run a real agent, the project shows how to run OpenCode against a free OpenRouter model and how to approve new access as the agent needs it.
How policy enforcement works
The project documents two main mechanisms.
- Kernel level enforcement. Each agent runs in an isolated sandbox. The kernel controls file access and system calls. Every network connection passes through a policy check before it leaves the sandbox.
- Formally verified policy changes. Before a policy change is approved, OpenShell uses formal verification to flag risky new access, such as reaching a new host with credentials or calling a new API method, so those changes wait for human review.
- Credential isolation. Agents never see real credentials. OpenShell adds them only to requests bound for approved endpoints.
The architecture has a gateway, a supervisor and the sandbox. The gateway is the control plane for sandboxes, policy and access. A Helm chart deploys the gateway on Kubernetes, and the cluster CNI must enforce NetworkPolicy. Middleware, interceptors and compute drivers extend the surface.
What this means for teams shipping agents
For a small team building RAG chatbots or agentic workflows, OpenShell could sit between the agent and the data it needs. Instead of giving a coding agent a long lived API key with broad scope, a policy can say the key only goes to one endpoint. This matters when the agent runs unattended.
This problem is adjacent to the access control work I wrote about in Giving 19 developers AI access through one proxy, and what actually changed. That piece looked at managing developer access to AI coding tools through a gateway. OpenShell applies the same thinking lower down, at file and system call level.
What I would try first
I would install the local gateway and create a sandbox. The quick start is short:
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demoThen I would run the OpenCode example from the repository, ask the agent to read a file outside the approved path, and watch the policy check block it. That would tell me how the control plane behaves before I touch a client project.
For a client deployment, I would watch three things. First, telemetry defaults. OpenShell collects anonymous telemetry limited to operational categories and counts. It does not collect sandbox names, hostnames, file paths, prompts, credentials, provider or model names, or user content. I would still disable it for regulated clients using OPENSHELL_TELEMETRY_ENABLED=false on the gateway. Second, GPU and lifecycle support inside sandboxes. Third, how the formally verified policy changes reduce the human review load when agents ask for new access over time.
The project is licensed under Apache License 2.0, which makes it easier to adopt in client work. But it is still early. The 0.1.x release brings a stable release cadence, new isolation primitives, an expanded extension surface and new APIs. I will watch how stable the APIs become before using it on production workloads.