NVIDIA OpenShell

NVIDIA OpenShell is an open source runtime that executes autonomous AI agents inside policy-governed sandboxes, published by NVIDIA under the Apache License 2.0. It sits between an agent and the machine it runs on, deciding which files the agent may read or write, which network destinations it may reach, which binaries are allowed to make those calls, and where its model requests are sent. NVIDIA announced OpenShell at GTC 2026 in San Jose on 16 March 2026, alongside NVIDIA NemoClaw, a reference stack that runs always-on agents inside OpenShell sandboxes.^[1][2][3] The project is written mostly in Rust and remains labelled alpha software as of July 2026.^[1]

Scroll sideways for more →

The problem it addresses

A stateless chatbot has almost no attack surface. An agentic AI system with a persistent shell, live credentials, the ability to install packages and rewrite its own tooling, and hours of accumulated context is a different threat model. NVIDIA's launch post framed the failure mode directly: with full access and full autonomy, you have "a long-running process policing itself", with guardrails living inside the same process they are supposed to guard.^[2]

That matters because the dominant defence in most agent products is textual. System prompts, refusal training and tool descriptions are all instructions to a model, and a manipulated model will ignore them. Prompt injection is the canonical case: Greshake and colleagues showed in 2023 that instructions hidden in retrieved content, not typed by the user, can steer an LLM-integrated application, demonstrating data theft, information contamination and unauthorised API calls against real systems including Bing Chat, and observing that "processing retrieved prompts can act as arbitrary code execution".^[24] Indirect prompt injection is the top entry (LLM01) in the OWASP Top 10 for LLM Applications 2025, which notes that given the stochastic nature of generative models it is unclear whether fool-proof prevention exists, and recommends defence in depth with least-privilege tooling instead; the same list ranks Excessive Agency (LLM06) separately.^[25]

An agent's promise not to do something is therefore not a security boundary. If a poisoned tool description, a malicious README or a compromised skill can redirect the agent, then every credential that process holds is reachable, every subagent it spawns can inherit permissions it was never meant to have, and every third-party skill it installs is an unreviewed binary with filesystem access.^[2] OpenShell's response is to move the decision point outside the agent process entirely. Ali Golshan, NVIDIA's senior director of AI software and the project lead, put it this way to The New Stack: "if you want to give more and more autonomy to an agent, the lowest level of the stack should really be a sandbox... That agent should not be interacting directly with your operating system or host or network or infrastructure."^[15][33]

Origins

Golshan cofounded Gretel, a synthetic data company NVIDIA acquired in March 2025 for a reported nine-figure sum, above Gretel's most recent $320 million valuation; two of his coauthors on the OpenShell launch post, Alex Watson and John Myers, were also Gretel cofounders.^[33][34][2] Golshan told The New Stack in May 2026 that his team had been building OpenShell for about six months, putting the start of work in late 2025; the public repository was created on 24 February 2026, three weeks before the GTC keynote.^[15][1] OpenShell is positioned as part of the NVIDIA NeMo Agent Toolkit stack.^[2][15]

Architecture

The repository documents four components.^[1]

Scroll sideways for more →

NVIDIA's March 2026 launch post named only three of these (the sandbox, the policy engine and the privacy router); the gateway was documented as a first-class component later.^[2][1] Inside each sandbox workload there are two trust levels. A supervisor starts as root, prepares the isolation, runs the proxy, injects credentials and launches the agent; the agent child then runs as an unprivileged user with filesystem, process and network restrictions already applied. On Linux the supervisor clears the capability bounding set during the privilege drop so later exec calls cannot regain container-granted capabilities, and aborts the spawn if that set does not end up empty.^[6]

How the isolation works

OpenShell layers several mechanisms rather than relying on one primitive.^[6][5]

• Filesystem. Landlock, the Linux security module for unprivileged path-based sandboxing, restricts which paths the agent can read or write. A compatibility setting chooses between best_effort (skip inaccessible paths, apply the rest) and hard_requirement (fail startup if any path or the required kernel ABI is missing).^[7]
• Process. The agent runs as a named non-root user and group; configuring root or uid 0 is rejected outright. Seccomp filters block dangerous syscalls, including raw socket paths that would bypass the proxy.^[7][6]
• Network. A network namespace forces ordinary egress through a local HTTP CONNECT proxy, which identifies the calling binary through a /proc/net/tcp inode lookup plus /proc/{pid}/exe, walks parent process identifiers, and enforces SHA-256 binary integrity on a trust-on-first-use basis.^[11][6] Filesystem and process policy are static, applied before the agent's first instruction runs, and changing them requires recreating the sandbox. Network and inference policy are dynamic and hot-reloadable on a running sandbox.^[1][7]

Network evaluation is deny-by-default and ordered: identify the calling binary, reject hard-blocked destinations including unsafe internal IP ranges, match destination and binary against policy blocks, apply optional layer-7 rules, then allow, deny, audit or log. Explicit denies and hardening checks beat allow rules, and if nothing matches the request is denied.^[5] For endpoints marked protocol: rest the proxy terminates TLS with the sandbox's own ephemeral certificate authority so it can inspect method and path; it can also evaluate WebSocket upgrades, GraphQL operations, and Model Context Protocol method, tool and parameter rules on request bodies.^[6]

Golshan described the enforcement layer to The New Stack as using "Linux kernel primitives such as seccomp, eBPF, and Landlock".^[15] OpenShell's own architecture documents name Landlock, seccomp, network namespaces and the userspace proxy, and do not describe an eBPF component, so that part is best read as vendor summary rather than documented implementation.^[5][6]

The policy file

Policies are declarative YAML that teams are meant to version-control and review like any other security control.^[4] A minimal file looks like this:^[7]

version: 1
filesystem_policy:
  read_only: [/usr, /lib, /etc]
  read_write: [/sandbox, /tmp]
landlock:
  compatibility: best_effort
process:
  run_as_user: sandbox
  run_as_group: sandbox
network_policies:
  my_api:
    name: my-api
    endpoints:
      - host: api.example.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: full
    binaries:
      - path: /usr/bin/curl

The binding of endpoints to binaries is the distinctive part: a connection is allowed only when the destination and the calling executable both match entries in the same block. The community catalogue's base policy grants /usr/local/bin/claude and /usr/bin/node access to api.anthropic.com, while a separate block allows /usr/bin/git to reach github.com for GET /**/info/refs* and POST /**/git-upload-pack (clone and fetch) with the push path commented out.^[11] Host patterns accept wildcards inside or as the first DNS label but reject *, ** and TLD wildcards such as *.com, failing at load time rather than mismatching silently at the proxy.^[5] A network_middlewares section can insert ordered request middleware, including a built-in regular-expression redactor, after policy admits a request but before credentials are injected.^[7]

Agent-proposed policy, human approval

Because a deny-by-default policy will block legitimate work, OpenShell includes a proposal loop: when an agent hits a constraint it can reason about the denial and propose a policy update, with a human holding final approval.^[2] Layer-7 denial responses carry structured next_steps and an agent_guidance string so a generic agent treats the block as a step rather than a dead end.^[5]

Proposals are checked, not trusted. Every submitted chunk runs through openshell-prover, which builds a Z3 model of the merged policy plus the sandbox's attached credentials and reports categorical findings: reach granted to link-local or cloud-metadata addresses, layer-7 bypass by a credentialed non-HTTP binary such as ssh or nc, new credentialed reach for a binary, or a new HTTP method on an endpoint the binary could already reach. Auto-approval fires only if the approval mode is explicitly set to auto, the prover delta is empty, and advisory security notes are empty. The default at both scopes is manual, so with no configuration every proposal waits for a human.^[5]

The privacy router

The privacy router decides where inference goes. Sandbox code calls a local HTTPS endpoint, inference.local; the router strips the caller's Authorization header, forwards only a per-provider allowlist of inference headers, injects credentials from a gateway-held provider record, and forwards to the configured backend, so the agent never sees the real key. Anything sent directly to an external host such as api.openai.com is judged by the network policy instead.^[8]

NVIDIA describes the intent as keeping sensitive context on-device with local open models and routing to frontier models only when policy allows, driven by the operator's cost and privacy policy rather than the agent's preference.^[2] Supported backends are NVIDIA, Anthropic, Google Vertex AI, AWS Bedrock through a translating bridge, and any OpenAI-compatible provider, which covers self-hosted Ollama and vLLM servers. One provider and one model define inference for a whole gateway, so every sandbox there shares the same backend.^[8][17]

Audit trail

Observable sandbox behaviour is logged in Open Cybersecurity Schema Framework format against vendored OCSF v1.7.0 schemas: proxy decisions map to network or HTTP activity, plus SSH activity, process activity, configuration state change and detection finding classes. Forward-proxy successes are emitted only after the full chain succeeds, so an allowed record cannot coexist with a later denial for the same request, and the project forbids logging secrets, tokens or query parameters because the JSONL output is expected to be shipped elsewhere.^[5][13]

Installation, platforms and CLI

OpenShell installs as a static binary, from PyPI with uv tool install -U openshell, or into Kubernetes via a Helm chart on GHCR. Supported hosts are Linux on x86_64 and aarch64, macOS on Apple Silicon through Docker Desktop, and Windows through WSL 2, which the docs mark experimental. Seccomp is required and Landlock recommended; on macOS both operate inside Docker Desktop's Linux VM rather than the host kernel. Compute drivers are Docker, Podman, Kubernetes and MicroVM backed by KVM or Hypervisor.framework.^[1][9]

The CLI is organised around gateways, sandboxes, providers, policies and inference, with openshell sandbox create -- claude as the canonical first command and openshell term opening a k9s-style terminal dashboard.^[1][12] GPU passthrough is available with --gpu and marked experimental; it requires host NVIDIA drivers and the NVIDIA Container Toolkit, and the default base image ships without GPU libraries.^[1] NVIDIA's launch post advertised openshell sandbox create --remote spark --from openclaw for running on an NVIDIA DGX Spark; the current CLI reference has no --remote flag on sandbox create, and remote gateways are registered with openshell gateway add --remote <USER@HOST> instead.^[2][12] NVIDIA still lists DGX Spark, DGX Station and RTX-equipped PCs as target hardware.^[2]

NemoClaw, OpenClaw and Hermes Agent

OpenShell is the runtime layer; NemoClaw is the blueprint that assembles a model, an agent harness and that runtime into something installable. NVIDIA describes NemoClaw as "an open source reference stack for running always-on AI agents more safely inside NVIDIA OpenShell sandboxes", also Apache 2.0, providing guided onboarding, a hardened blueprint, routed inference, network policy and lifecycle management behind a single CLI. Its default agent is OpenClaw, the always-on assistant framework; alternatives are Hermes Agent and LangChain Deep Agents Code.^[18]

Hermes Agent is Nous Research's open harness. In OpenShell's supported-agent table it appears alongside OpenClaw as an agent sourced through NemoClaw, meaning routing and policy come from the NemoClaw blueprint rather than the base sandbox image; Claude Code, opencode, OpenAI Codex and GitHub Copilot CLI are preinstalled in the base image and work directly.^[1] Cursor was named among compatible agents in the launch post but is absent from the repository's supported-agent table, appearing instead as a remote-editor option (--editor cursor).^[2][12]

Comparison with other agent sandboxing approaches

Scroll sideways for more →

The layers do different jobs. Docker, gVisor and Firecracker are isolation substrates of escalating strength and cost, and OpenShell can sit on any of them through its driver interface. E2B, Modal and Daytona are hosted execution services consumed as an API by an agent framework. Anthropic's sandbox-runtime and Codex's sandbox modes are per-tool controls shipped with a specific coding agent. OpenShell's claim is to be the horizontal layer beneath all of them: agent-agnostic, self-hosted, enforcing one policy the agent cannot reach.^[15][1]

Adoption and reception

By 31 July 2026 the repository had roughly 7,900 stars, 1,114 forks and 100 or more contributors, with 884 issues and 1,465 pull requests filed and near-daily point releases through July.^[1] Coverage at launch came from MarkTechPost, which highlighted the per-binary, per-endpoint, per-method policy model and the fact that OpenShell is agent-agnostic rather than requiring a rewrite into a particular SDK.^[16]

LangChain announced on the day of the GTC keynote that it would work with NVIDIA on an enterprise agent platform incorporating OpenShell, positioning Deep Agents to run inside GPU-accelerated OpenShell sandboxes, and later said it would contribute openly to the repository.^[20][15]

The most concrete enterprise deployment so far is ServiceNow Project Arc, announced on 5 May 2026 at ServiceNow Knowledge 2026 in Las Vegas with Jensen Huang and ServiceNow chief executive Bill McDermott on stage together. Project Arc is a long-running autonomous desktop agent for knowledge workers that uses OpenShell as its secure runtime, connecting to ServiceNow Action Fabric for workflow context and AI Control Tower for oversight, with ServiceNow contributing back to the project. Jon Sigler, ServiceNow's executive vice president and general manager for AI Platform, said the combination delivers "the governance and security that enterprise AI requires".^[19][15] The partnership also advances NOWAI-Bench, an open benchmarking suite for enterprise agents built on NVIDIA's NeMo Gym library, whose EnterpriseOps-Gym component NVIDIA says Nemotron 3 Super currently leads among open models.^[19] NVIDIA also lists Cisco, CrowdStrike, Google Cloud, Microsoft Security, SAP, Canonical and Red Hat among ecosystem participants.^[14]

Limitations and criticism

The project labels itself alpha and "single-player mode": one developer, one environment, one gateway, with multi-tenant deployment still a goal rather than a shipped feature.^[1] Several specific gaps are documented in the open tracker.

A researcher demonstrated in May 2026 that DNS was a covert exfiltration channel: with no network policy configured, an HTTP request to an attacker-controlled domain was correctly denied by the proxy, but the DNS lookup for that hostname had already carried data encoded in subdomain labels to the attacker's nameserver. NVIDIA maintainer Russell Bryant posted a fix and the issue was closed on 15 May 2026.^[21] A proxy that mediates TCP does not automatically mediate name resolution.

Kubernetes deployment is constrained by the privilege the supervisor needs. Sandbox pods request CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_SYSLOG and runAsUser: 0, which Red Hat OpenShift's default restricted-v2 SecurityContextConstraint forbids; the filed issue argues that granting a custom constraint with those capabilities weakens the cluster and is "a non-starter for many enterprise deployments".^[22] A related draft RFC from external contributors proposes splitting supervisor and agent into separate pods, the agent running with zero capabilities as non-root under a gVisor or Kata RuntimeClass, because the current shared-pod design "creates a wide blast radius if the agent escapes its confinement".^[23] Both remained open on 31 July 2026.

Other rough edges are acknowledged in the documentation: GPU passthrough is experimental and the default image ships without GPU drivers; the Helm path warns of breaking changes; Windows runs only through WSL 2; and reliable readiness composition currently requires a single gateway replica because supervisor sessions are process-local, tracked as issue #1868.^[1][10] The default policy also covers Claude Code more completely than other agents, so OpenAI Codex and partially opencode need a custom policy naming their endpoints and binaries before they can reach model APIs.^[1]

Significance

OpenShell is an argument as much as a product: that the security primitives for AI agents belong below the application layer, where the model cannot reason its way past them, and that this layer should be shared open infrastructure rather than a per-vendor feature. Comparable enforcement exists in narrower form inside individual coding agents, but OpenShell is the most complete attempt so far to make it agent-agnostic, self-hostable and auditable in one package. Whether it becomes the common layer depends on whether harness vendors, cloud platforms and governance tools converge on it, which is what the ServiceNow and LangChain commitments are meant to signal.

See also

• NVIDIA NemoClaw
• OpenClaw
• Hermes Agent
• Prompt injection
• Guardrails (AI)
• Agent skills
• AI safety
• NVIDIA NeMo Agent Toolkit

References

1. ^NVIDIA, "OpenShell: the safe, private runtime for autonomous AI agents" (README and repository metadata), GitHub, accessed 31 July 2026. github.com/...OpenShell
2. ^Ali Golshan, Alex Watson and John Myers, "Run Autonomous, Self-Evolving Agents More Safely with NVIDIA OpenShell", NVIDIA Technical Blog, 16 March 2026. developer.nvidia.com/...fely-with-nvidia-openshell
3. ^NVIDIA, "NVIDIA CEO Jensen Huang and Global Technology Leaders to Showcase Age of AI at GTC 2026", NVIDIA Newsroom, 2026. nvidianews.nvidia.com/...ase-age-of-ai-at-gtc-2026
4. ^NVIDIA, "Overview of NVIDIA OpenShell", NVIDIA OpenShell documentation, accessed 31 July 2026. docs.nvidia.com/...overview
5. ^NVIDIA, "Security Policy" (architecture/security-policy.md), NVIDIA/OpenShell, GitHub, accessed 31 July 2026. github.com/...security-policy.md
6. ^NVIDIA, "Sandbox" (architecture/sandbox.md), NVIDIA/OpenShell, GitHub, accessed 31 July 2026. github.com/...sandbox.md
7. ^NVIDIA, "Customize Sandbox Policies", NVIDIA OpenShell documentation, accessed 31 July 2026. docs.nvidia.com/...policies
8. ^NVIDIA, "Inference Routing", NVIDIA OpenShell documentation, accessed 31 July 2026. docs.nvidia.com/...inference-routing
9. ^NVIDIA, "Support Matrix", NVIDIA OpenShell documentation, accessed 31 July 2026. docs.nvidia.com/...support-matrix
10. ^NVIDIA, "Compute Runtimes" (architecture/compute-runtimes.md), NVIDIA/OpenShell, GitHub, accessed 31 July 2026. github.com/...compute-runtimes.md
11. ^NVIDIA, "sandboxes/base/policy.yaml", NVIDIA/OpenShell-Community, GitHub, accessed 31 July 2026. github.com/...policy.yaml
12. ^NVIDIA, "OpenShell CLI Reference" (.agents/skills/openshell-cli/cli-reference.md), NVIDIA/OpenShell, GitHub, accessed 31 July 2026. github.com/...cli-reference.md
13. ^NVIDIA, "Vendored OCSF Schemas" (crates/openshell-ocsf/schemas/ocsf/README.md), NVIDIA/OpenShell, GitHub, accessed 31 July 2026. github.com/...README.md
14. ^Ali Golshan, "How Autonomous AI Agents Become Secure by Design With NVIDIA OpenShell", NVIDIA Blog, 23 March 2026. blogs.nvidia.com/...autonomous-ai-agents-openshell
15. ^Darryl K. Taft, "Jensen Huang and Bill McDermott bet on OpenShell to secure enterprise AI agents", The New Stack, 12 May 2026. thenewstack.io/nvidia-openshell-agent-runtime
16. ^Asif Razzaq, "NVIDIA AI Open-Sources 'OpenShell': A Secure Runtime Environment for Autonomous AI Agents", MarkTechPost, 18 March 2026. marktechpost.com/...nment-for-autonomous-ai-agents
17. ^NVIDIA, "OpenShell", NVIDIA Perspectives, last updated 29 July 2026. perspectives.nvidia.com/nvidia-openshell
18. ^NVIDIA, "NemoClaw" (README), GitHub, accessed 31 July 2026. github.com/...NemoClaw
19. ^NVIDIA, "NVIDIA and ServiceNow Partner on New Autonomous AI Agents for Enterprises", NVIDIA Blog, 5 May 2026. blogs.nvidia.com/...tonomous-ai-agents-enterprises
20. ^LangChain, "LangChain Announces Enterprise Agentic AI Platform Built with NVIDIA", LangChain blog, 16 March 2026. langchain.com/...nvidia-enterprise
21. ^"DNS-based data exfiltration bypasses sandbox network policy", issue #1169, NVIDIA/OpenShell, GitHub, opened 5 May 2026, closed 15 May 2026. github.com/...1169
22. ^"feat: Support restricted SecurityContextConstraints for managed Kubernetes platforms", issue #899, NVIDIA/OpenShell, GitHub, opened 20 April 2026. github.com/...899
23. ^"Proposal: Split Supervisor and Agent into Separate Pods with gVisor Isolation", issue #981, NVIDIA/OpenShell, GitHub, opened 26 April 2026. github.com/...981
24. ^Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz and Mario Fritz, "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection", arXiv:2302.12173, 23 February 2023. arxiv.org/...2302.12173
25. ^OWASP GenAI Security Project, "OWASP Top 10 for LLM Applications 2025", accessed 31 July 2026. genai.owasp.org/llm-top-10
26. ^Anthropic, "sandbox-runtime" (README), anthropic-experimental, GitHub, accessed 31 July 2026. github.com/...sandbox-runtime
27. ^OpenAI, "Codex configuration: sandbox and approvals", Codex documentation, accessed 31 July 2026. learn.chatgpt.com/...config-basic
28. ^The gVisor Authors, "What is gVisor?", gVisor documentation, accessed 31 July 2026. gvisor.dev/docs
29. ^Firecracker project, "Secure and fast microVMs for serverless computing", accessed 31 July 2026. firecracker-microvm.github.io
30. ^Modal, "Sandboxes", Modal documentation, accessed 31 July 2026. modal.com/...sandbox
31. ^E2B, "E2B: secure open source cloud runtime for AI apps and agents" (repository), GitHub, accessed 31 July 2026. github.com/...E2B
32. ^Daytona, "Secure and Elastic Infrastructure for Running Your AI-Generated Code", accessed 31 July 2026. daytona.io
33. ^NVIDIA, "Ali Golshan" (author profile), NVIDIA Technical Blog, accessed 31 July 2026. developer.nvidia.com/...aligolshan
34. ^Kyle Wiggers, "Nvidia reportedly acquires synthetic data startup Gretel", TechCrunch, 19 March 2025. techcrunch.com/...es-synthetic-data-startup-gretel