NVIDIA OpenShell: AI Agents Without Handing Them the Keys

TL;DR - NVIDIA OpenShell is an open-source runtime that runs fleets of AI agents inside kernel-enforced sandboxes: Landlock-locked filesystems, seccomp-staged networking, credentials injected per request so the agent never holds them, and an SMT solver that checks what a policy change would allow before a human approves it. It is Apache 2.0, it absorbed 1,850+ commits in eight months, and it is the control layer most agent rollouts are currently missing. What you need to do: read the architecture page, run the demo sandbox, and inventory where agents in your estate touch real credentials.

By The Numbers

I cloned NVIDIA's OpenShell repository at nine this morning, expecting another agent wrapper, and an hour later I was still reading. Not because the README is long, but because of what is in it: a formal verification engine, a per-binary network policy language, and a credential system where the agent never actually holds a secret.

Here is the part that changed my morning. OpenShell does not try to make agents behave better. It puts them in an environment where misbehaving does not pay: the filesystem access is not there, the network path is not there, and the API keys are held by a separate trusted process that only attaches them to requests heading for destinations you approved in advance.

The enforcement lives outside the agent's process. A prompt can argue with the agent. It cannot argue with the kernel.

If your team is running coding agents such as Claude Code, OpenCode, Codex or GitHub Copilot CLI against real repositories, real credentials and real networks, this project deserves a slot in your next planning session. Let me walk you through what it actually enforces, why the verification engine is the bit nobody else ships, and what you can do with it before the weekend is over.

What OpenShell actually is

The project's own one-liner is the shortest honest summary: OpenShell is the safe, private runtime for fleets of autonomous AI agents. Agents are most useful when they can read files, install packages, call APIs and use credentials. That same access is exactly what makes them dangerous. OpenShell keeps the capability and removes the unrestricted part: you declare what each agent may touch in a YAML policy, and the runtime enforces the declaration outside the agent's own process.

The project is young and moving unusually fast. It appeared on GitHub on 24 February 2026 under an Apache 2.0 licence, crossed 17,600 stars and 1,850 commits by late October, and the core is roughly 610,000 lines of Rust. SDKs for Python, TypeScript, Go and Rust connect your applications to an OpenShell gateway. After a stretch of development builds, the team cut v0.1.0 on 25 September 2026 and has shipped a stable release roughly every week since, with v0.1.5 landing on 20 October. NVIDIA backs it with a product page and full documentation, and the whole thing is self-hostable, including on Kubernetes via Helm.

One more thing worth knowing: OpenShell is built agent-first in the development sense too. NVIDIA publishes skills that let your coding agent drive the OpenShell CLI, write sandbox policies and debug gateways, so the loop of "agent proposes, human approves" applies to operating OpenShell itself, not just the workloads inside it.

What actually breaks without it

Run a coding agent on a work machine today and, on most setups, it executes as you. Your filesystem. Your SSH keys. Your cloud tokens sitting in environment variables. Your network routes. NVIDIA's overview names four failure modes that fall straight out of that default, and none of them are exotic:

• Data exfiltration: the agent uploads source code or internal files to an endpoint nobody approved.
• Credential theft: the agent reads local secrets such as SSH keys or cloud credentials.
• Unauthorised API usage: the agent sends your prompts and data to a model provider your organisation never sanctioned.
• Privilege escalation: the agent attempts sudo, setuid paths or other syscall tricks to break out of its user.

None of these need the model itself to turn evil. A convincing instruction hidden in a retrieved document, a poisoned dependency README, or a careless prompt can steer an agent into any of them. We have already watched this movie from the offensive side: the CARLIY0S playbook breakdown I published this week is what an agentic attack stack looks like when it is aimed at banks. OpenShell is the defensive answer to the same question.

The uncomfortable truth about the current default is that "my agent runs in Docker" is not a control. A container stops the agent from touching the host kernel, and then hands it a network interface and whatever environment variables you passed in. That is not least privilege; that is a smaller room with the same open windows.

How the enforcement actually works

OpenShell splits the world into three components. The gateway is the control plane: identity, sandbox lifecycle, policy delivery, credentials. The supervisor sits on the trusted side of the boundary and makes the decisions: checking each request against policy, resolving DNS, holding provider credentials, and opening approved connections. The sandbox lives on the untrusted side with the agent inside it. It records what the agent is trying to do, but it never makes policy decisions of its own.

On the Linux backend, the agent runs as a single non-root identity with no capabilities. Filesystem access is confined by Landlock, a Linux Security Module that locks reads and writes to the paths your policy declares. Network operations are staged through seccomp user notification, so every connection the agent attempts passes a policy check before it leaves the sandbox. The default posture is deny: all egress is blocked except the sandbox's protected channel to its supervisor.

Network rules are per-binary, which is where this gets genuinely useful for real teams. A policy can let one executable reach one host while the rest of the sandbox stays offline, and it can restrict what that binary may send, for example allowing reads from an API while writes are denied. Filesystem and process rules lock at sandbox start. Network rules hot-reload while the sandbox runs, so tightening access does not mean tearing the agent's session down.

The credentials piece is my favourite part, because it inverts the usual model. Your API keys live in the gateway, not in the sandbox. When the agent's request is bound for an approved endpoint, the supervisor attaches the credential to that request in flight. The agent sees an opaque placeholder and gets the response; it never holds the token. Revoking a credential takes effect without the agent ever having had it, which closes the "agent read my environment variables" class of incident entirely. It is the payment-terminal model: the waiter never sees your card number, and neither does the agent.

The part that should get your attention: verified policy changes

Two pieces separate OpenShell from a well-written wrapper around Docker, and both aim at the same moment: the one where the agent wants more access than you gave it.

The policy advisor handles the everyday case. When a sandboxed request is blocked, the agent can submit a proposal for the exact network rule it needs, with the blocked request as evidence. The proposal never changes anything on its own: by default every proposal waits for a human to approve or reject it, and proposals cannot touch filesystem, process or Landlock settings at all. Teams that want less friction can opt in to automatic approval, which only approves a proposal when the risk checks find nothing to flag.

Those risk checks come from the policy prover, and this is the feature that makes OpenShell more than a curiosity. The prover is an SMT solver, shipped as a standalone openshell-prover binary, that reasons about what a policy allows rather than pattern-matching its text. It runs two kinds of checks:

1. Boundary check: verifies that a candidate policy allows nothing beyond a boundary policy you define, which in practice is your organisation's maximum allowed access for agents. An agent can draft a policy for a subagent, and the prover can prove the draft stays inside the parent's limits before anything runs.
2. Proposal risk check: runs whenever an agent proposes a new network rule, and flags the classic exfiltration patterns. Reaching a new host with credentials attached. Calling a new API method. Touching cloud metadata addresses such as 169.254.169.254. Any finding blocks auto-approval and sends the change to a human.

Because the prover is a standalone binary with published SHA-256 checksums, you can wire boundary checks into CI: an agent-authored policy gets proven against your boundary before it can be applied anywhere. NVIDIA is honest about the limits, and I respect that. The guarantees apply to the policy constructs and behaviour the prover's model represents, and coverage expands release by release. Treat it as a formal floor that keeps growing under your security policy, not as proof of universal safety.

What IT teams are doing with it

NVIDIA's documentation names four deployment patterns, and they map cleanly onto work that is probably already on your roadmap:

• Secure coding agents: run Claude Code, OpenCode, Codex or GitHub Copilot CLI with constrained file and network access instead of full user-level trust.
• Private enterprise development: give selected sandboxes access to self-hosted or private model endpoints while sensitive context stays inside your perimeter.
• Compliance and audit: treat the policy YAML as version-controlled security controls, reviewable in pull requests and auditable after the fact. Telemetry is limited to operational categories and counts, excludes paths, prompts, credentials and content, and can be disabled with OPENSHELL_TELEMETRY_ENABLED=false or compiled out entirely.
• Kubernetes fleets: deploy the gateway with Helm. One real prerequisite: your CNI must actually enforce NetworkPolicy, because the network fence assumes it.

That Kubernetes prerequisite deserves a pause. If your cluster's CNI silently ignores NetworkPolicy resources, plenty of things in your estate are more exposed than your architecture diagrams say, and an agent runtime will happily inherit that gap. Standing up OpenShell's Helm chart is a decent way to find out, and the finding is worth having regardless of what you decide about agents.

The concerns, honestly

Nothing here is a magic wand, and the maturity story matters when you are planning a rollout:

• It is a 0.1 release line. The cadence is weekly and the upgrade guide is published, but you are reading release notes as you go. Pilot on real work, not on the crown jewels.
• The prover's guarantees are scoped. If a policy feature is not represented in the prover's model, the formal check does not cover it. The human approval step is not ceremony; it is the actual control.
• Windows is experimental (WSL 2 only), and sandboxes need Docker, Podman or host virtualization underneath.
• Policy authoring is still a human skill. OpenShell proves your policy does what it says. It cannot prove the policy says what your organisation meant. Least-privilege design is the same discipline it has always been; we covered the cost of getting it wrong when an AI agent with too much access deleted a TV season.

What you should do right now

1. Read the architecture page (15 minutes). The gateway / supervisor / sandbox split is the mental model your team needs before anything else.
2. Run the demo sandbox on a Linux box or an Apple Silicon Mac: curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh then openshell sandbox create --name demo.
3. Do the Run Your First Agent walkthrough. It runs OpenCode against a free OpenRouter model and makes you approve each piece of access as the agent asks. Forty-five minutes, and it is the fastest way to feel what deny-by-default egress is like in practice.
4. Inventory your estate. Where do agents run today with full user credentials? Build the list now; it becomes your OpenShell pilot shortlist.
5. If you already do policy-as-code, wire the prover into CI. Boundary-checking agent-authored policies before they merge is the whole discipline in one step.
6. Test your CNI. Apply a deny-all NetworkPolicy to a canary namespace and check whether it is actually enforced. If it is not, you have found next sprint's problem.

Key takeaways

• NVIDIA OpenShell is an open-source agent runtime with real enforcement: Landlock filesystem locks, seccomp-staged networking, and deny-by-default egress enforced from outside the agent's process.
• The agent never holds credentials. The supervisor injects them per request, bound to approved endpoints, which kills the environment-variable theft class entirely.
• Policy changes are verified, not just reviewed. An SMT-solver prover checks agent-proposed rules against your boundary and flags credentialed reach to new hosts, new API methods and cloud metadata endpoints before a human approves them.
• The policy advisor gives agents a legitimate path to ask for access, so deny-by-default does not mean your agents stall on every task.
• It is young: v0.1.x, weekly releases, experimental Windows support, and prover guarantees scoped to its model. Pilot it like the 0.1 it is.
• The Kubernetes path exposes a gap you may already have: if your CNI does not enforce NetworkPolicy, OpenShell's Helm deployment will help you find out.

FAQ

Is NVIDIA OpenShell free and open source?

Yes. Apache 2.0 licensed, hosted at github.com/NVIDIA/OpenShell, self-hostable, with a Helm chart for Kubernetes. NVIDIA also offers a cloud trial via its Brev Launchable service if you want to try before installing.

Which platforms does it support?

Linux and macOS on Apple Silicon are supported today; Windows works through WSL 2 on an experimental basis. You need Docker, Podman or host virtualization available, because sandboxes are provisioned through a compute runtime.

Does it work with Claude Code or GitHub Copilot CLI?

Yes, and with any other harness. NVIDIA's use-case list names Claude Code, OpenCode, Codex and Copilot CLI explicitly, and the default sandbox ships with no agent installed, so you bring the tooling your team already uses and OpenShell constrains it from the outside.

How is this different from running an agent in Docker?

A container isolates the agent from the host, then hands it a network interface and your environment variables. OpenShell adds per-binary network rules with method restrictions, Landlock filesystem confinement, per-request credential injection, hot-reloadable policy and formal verification of what a change would allow. Enforcement lives outside the agent's process, where a prompt cannot reach it.

Is it production ready?

Treat it as a fast-maturing 0.1 line: weekly stable releases, an upgrade guide, unusually thorough documentation for its age, but scoped prover guarantees and experimental Windows support. Pilot it on real work with real review, and read the upgrade notes before each bump.

Does it protect against prompt injection?

It does not stop the injection; it removes the payoff. A hijacked agent in an OpenShell sandbox can only reach the files, hosts and methods your policy allows, and anything riskier needs a human-approved policy change. Contain the blast radius and the injected instruction has nothing to steal with.

My Take

The thing I keep coming back to is where the enforcement sits. Every agent-safety approach that lives inside the agent, system prompts, guardrail models, output filters, is in a negotiation with something that is specifically good at winning negotiations. OpenShell moves the control out of the negotiation entirely. The agent does not get told "no" and talk its way around it; the file read simply fails, the packet simply dies, the credential simply is not there.

The prover is the piece I did not expect anyone to ship this year, and it points at where this category is going. Agentic security is going to end up looking like the rest of security engineering: policies as code, changes reviewed by humans and proven by machines, everything in git. The teams who practise that loop now, on a 0.1 runtime with demo workloads, will write their organisations' agent policies properly when the workloads are real.

Eight months, 17,600 stars, six stable releases in 25 days. Whatever your agent rollout looks like next year, the control layer it runs on will probably look a lot like this.

Mathew Clark Founder, SecureInSeconds Currently: re-reading the policy YAML on my own cron-driven agents with noticeably less confidence than I had on Monday

Further reading

• NVIDIA OpenShell on GitHub - the repo, releases and roadmap
• OpenShell overview and docs - start here for concepts
• Architecture: gateway, supervisor and sandbox
• Policy Prover: formally verified policy changes
• Policy Advisor: agent-proposed network rules
• Run Your First Agent - the 45-minute walkthrough
• When an AI agent deleted a TV season: least privilege for agents
• The CARLIY0S AI heist playbook: the offensive mirror image