# NVIDIA OpenShell

> Source: https://aiwiki.ai/wiki/nvidia_openshell
> Updated: 2026-09-30
> Fact-checked: 2026-09-30
> Categories: AI Agents, AI Safety, Developer Tools, NVIDIA, Open Source AI
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "NVIDIA OpenShell." aiwiki.ai, 30 Sept 2026. https://aiwiki.ai/wiki/nvidia_openshell
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

**NVIDIA OpenShell** is an open source runtime that executes autonomous AI agents inside policy-governed sandboxes, published by [NVIDIA](https://aiwiki.ai/wiki/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 the credentials it uses may be sent. NVIDIA announced OpenShell at GTC 2026 in San Jose on 16 March 2026, alongside [NVIDIA NemoClaw](https://aiwiki.ai/wiki/nvidia_nemoclaw), a reference stack that runs always-on agents inside OpenShell sandboxes.[1][2][3] The project is written mostly in Rust. After six months of near-daily 0.0.x releases labelled alpha, NVIDIA published OpenShell 0.1.0 on 25 September 2026, removing the alpha badges and redesigning the sandbox boundary.[39][40] Three days later, on 28 September 2026, NVIDIA described OpenShell as "now broadly available" and made it the software half of the [NVIDIA Open Agent Safety Platform](https://aiwiki.ai/wiki/nvidia_open_agent_safety_platform), alongside the NVIDIA Sentry reference design for [BlueField](https://aiwiki.ai/wiki/bluefield)-4 data processing units.[36][37] Two days earlier, on 26 September 2026, a Cloud Native Computing Foundation (CNCF) Technical Oversight Committee vote on the application to make OpenShell a CNCF Sandbox project had passed; onboarding was waiting on a signed contribution agreement.[75] On 28 September a Hugging Face engineer published a draft design, in a personal fork rather than the project's repository, for monitoring how much agents use the network destinations their policy already allows.[76][77][80]

| Field | Value |
| --- | --- |
| Developer | NVIDIA |
| Repository created | 24 February 2026; announced at GTC 2026, San Jose, 16 March 2026 |
| License | Apache License 2.0 |
| Implementation | Rust; YAML policies compiled to Open Policy Agent (Rego) and evaluated for each outbound request[35] |
| Project status | 0.1.x stable release series since 25 September 2026; the 0.0.x series (March to August 2026) was labelled alpha, "single-player mode" |
| Latest tagged release | v0.1.2, 28 September 2026; still the latest release on 30 September 2026[60][69] |
| Host platforms | Linux (x86_64, aarch64), macOS on Apple Silicon, Windows via WSL 2 (experimental) |
| Compute drivers | Docker, Podman, MicroVM, Kubernetes; Windows MXC listed as "coming soon" (September 2026) |
| Part of | NVIDIA Open Agent Safety Platform (announced 28 September 2026) |
| Governance | 13 maintainers (10 from NVIDIA, 3 from Red Hat) under a governance document added in September 2026; CNCF Sandbox application approved by TOC vote on 26 September 2026, onboarding pending[73][74][75] |
| GitHub stars | 10,737, with 1,428 forks and 125 contributors (GitHub API, 30 September 2026)[68] |

## The problem it addresses

NVIDIA's launch post argued that a stateless chatbot has no meaningful attack surface, while an [agentic AI](https://aiwiki.ai/wiki/agentic_ai) system with a persistent shell, live credentials, the ability to rewrite its own tooling, and hours of accumulated context is a different threat model. The 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](https://aiwiki.ai/wiki/prompt_injection) is the canonical case. Greshake and colleagues showed in 2023 that instructions planted in data an LLM-integrated application retrieves, not typed by the user, can steer the application; they set out a taxonomy of impacts including data theft, worming and information ecosystem contamination, demonstrated attacks against real systems including Bing's GPT-4-powered Chat, and observed that "processing retrieved prompts can act as arbitrary code execution".[24] Prompt injection, direct and [indirect](https://aiwiki.ai/wiki/indirect_prompt_injection), is the top entry (LLM01) in the OWASP Top 10 for LLM Applications 2025, which says that given the stochastic influence at the heart of how models work "it is unclear if there are fool-proof methods of prevention" and lists mitigations including privilege control and least-privilege access; the same list ranks Excessive Agency (LLM06) separately.[25][55]

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, who leads product efforts on OpenShell, 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 was reported in March 2025 to have acquired for a 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] Myers, a senior director of software engineering, leads OpenShell engineering, and Watson helps lead product.[2] The New Stack reported in May 2026 that Golshan and his team had been building OpenShell for the past 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] In September 2026 the authors wrote that they had been "building OpenShell over the past year".[37] NVIDIA positions OpenShell as part of the [NVIDIA Agent Toolkit](https://aiwiki.ai/wiki/nvidia_agent_toolkit), a bundle that LangChain's launch announcement described as including Nemotron models, [NVIDIA NeMo Agent Toolkit](https://aiwiki.ai/wiki/nemo_agent_toolkit) profiling and optimization, NIM microservices and [NVIDIA Dynamo](https://aiwiki.ai/wiki/nvidia_dynamo).[2][15][20]

## Architecture

OpenShell has gone through two sandbox designs. The description in this section through "Audit trail" covers the 0.0.x series as documented up to the end of July 2026, except where it notes later changes; the redesign that shipped in 0.1.0 is described in [The 0.1 redesign](#the-01-redesign) below.

In the 0.0.x series the repository documented four components.[1][15]

| Component | Role |
| --- | --- |
| Gateway | Control-plane API that coordinates sandbox lifecycle, holds credentials and session state, and acts as the authentication boundary |
| Sandbox | The isolated runtime itself, supervised in-workload and with all egress routed through a local policy proxy |
| Policy Engine | Evaluates filesystem, network and process constraints, from the application layer down to kernel enforcement |
| Privacy Router | Privacy-aware model routing that keeps sensitive context on sandbox-local compute (removed in 0.1.0) |

NVIDIA's March 2026 launch post named three components (the sandbox, the policy engine and the privacy router), while a 23 March NVIDIA Blog post by Golshan listed the sandbox, the policy enforcement engine and the gateway.[2][14] Inside each 0.0.x sandbox workload there were two trust levels. A supervisor started as root, prepared the isolation, ran the proxy, injected credentials and launched the agent; the agent child then ran as an unprivileged user with filesystem, process and network restrictions already applied. On Linux the supervisor cleared the capability bounding set during the privilege drop so later `exec` calls could not regain container-granted capabilities, and aborted the spawn if that set did 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 non-root user and group; root identities are rejected outright. Seccomp filters block dangerous syscalls, including raw socket paths that would bypass the proxy.[7][6]
- **Network.** In the 0.0.x design, a network namespace forced ordinary egress through a local HTTP CONNECT proxy, which identified the calling binary through a `/proc/net/tcp` inode lookup plus `/proc/{pid}/exe`, walked parent process identifiers, and enforced 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 policy is dynamic and hot-reloadable on a running sandbox.[1][7][35]

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](https://aiwiki.ai/wiki/model_context_protocol) method, tool and parameter rules on request bodies.[6][5]

The New Stack's May 2026 article described the enforcement layer as using "Linux kernel primitives such as seccomp, eBPF, and Landlock".[15] OpenShell's own architecture documents named Landlock, seccomp, network namespaces and the userspace proxy and did not describe an eBPF component, so that part is best read as a press summary rather than documented implementation.[5][6][66] The project deleted its `architecture/` directory from the main branch on 29 September 2026; the pull request said design records remain in `rfc/`, crate details in crate `README.md` files and user documentation in `docs/`.[67]

### The policy file

Policies are declarative YAML that teams are meant to version-control and review like any other security control.[4] A short policy in the documented format looks like this:[7]

```yaml
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 a `*` wildcard inside the first DNS label or as an entire middle label, and a recursive `**` only as the whole first label; they 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]

NVIDIA's September 2026 walkthrough shows the same model with `access: read-only` on the GitHub REST API: `curl` inside the sandbox can `GET` from `api.github.com`, a `POST` to the same host is blocked, and the replacement policy is applied with `openshell policy set` without restarting the sandbox.[35]

### 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] When the policy advisor is enabled, 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] In 0.1 the policy advisor is enabled per sandbox (for example with `openshell settings set <sandbox-name> --key agent_policy_proposals_enabled --value true`), proposals stay pending for human review by default, and the agent cannot approve its own request.[35]

Proposals are checked, not trusted. A Z3-based policy prover was merged into the repository in April 2026.[62] 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]

OpenShell 0.1.0 added a second use of the prover: a boundary check, run with the standalone `openshell-prover` command, that verifies a candidate policy grants no access beyond an operator-written boundary policy, covering filesystem access, process identity, Landlock settings, network connections and REST requests; for rules it cannot model, such as GraphQL or MCP rules, it reports that it cannot check the policy rather than ignoring them.[44] The New Stack called the prover "the important new component added in this update", while NVIDIA's walkthrough listed it as one of five new capabilities in 0.1.0.[63][35] Golshan told reporters it is "deterministic" and "not LLM as a judge".[63] NVIDIA says that in long-horizon adversarial experiments, frontier agents with reduced safeguards spent up to two hours trying to persuade an AI reviewer to grant permissions that would let them modify a protected GitHub repository, and that no protected repository writes occurred.[35]

### The privacy router

In the 0.0.x series the privacy router decided where inference went. Sandbox code called a local HTTPS endpoint, `inference.local`; the router stripped the caller's `Authorization` header, forwarded only a per-provider allowlist of inference headers, injected credentials from a gateway-held provider record, and forwarded to the configured backend, so the agent never saw the real key. Anything sent directly to an external host such as `api.openai.com` was judged by the network policy instead.[8]

NVIDIA described 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 were NVIDIA, Anthropic, Google Vertex AI, AWS Bedrock through a translating bridge, and any OpenAI-compatible provider, which covered self-hosted [Ollama](https://aiwiki.ai/wiki/ollama) and [vLLM](https://aiwiki.ai/wiki/vllm) servers. One provider and one model defined inference for a whole gateway, so every sandbox there shared the same backend.[8][17]

OpenShell 0.1.0 removed the `openshell inference` commands, the route APIs and the `inference.local` endpoint.[40] Model access is now granted like any other service: an operator attaches a provider to the sandbox, the workload calls the provider's native API, and OpenShell evaluates the request against the network policy derived from the provider profile, substituting the real credential only at an endpoint that profile authorizes.[43]

### Audit trail

Observable sandbox behaviour is logged in Open Cybersecurity Schema Framework format against vendored OCSF schemas (v1.7.0 in July 2026, v1.8.0 from August 2026): 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] OpenShell 0.1.0 made the OCSF schema version configurable for compatibility with existing security information and event management (SIEM) systems.[39]

### The 0.1 redesign

OpenShell 0.1.0 implemented a new sandbox architecture (RFC 0012, whose design document was merged into the repository on 10 September 2026, implemented in a pull request merged on 16 September 2026) that moves the trusted component out of the agent's workload.[70][53][41] Each sandbox now has a supervisor on the trusted side of the boundary, which checks requests against policy, supplies credentials, resolves DNS and opens approved connections, and a sandbox component inside the boundary that owns the agent's processes, identifies the calling executable from trusted `/proc` data, and hands TCP opens and DNS queries to the supervisor using seccomp user notification.[41] The runtime grants neither the trusted components nor the agent child any Linux capability inside the workload; the agent runs as a single non-root identity with `no_new_privs`, Landlock and a final syscall filter.[66][41]

| Runtime | Where the supervisor runs | How direct egress is blocked |
| --- | --- | --- |
| Docker | Its own container | Workload container has networking turned off |
| Podman | Its own container | Workload container has networking turned off |
| Kubernetes | Its own pod | NetworkPolicy allows only the supervisor service |
| VM | A process on the host | Guest has no network device |

Supervisor and sandbox talk over a mutually authenticated HTTP/2 connection (a Unix socket for Docker and Podman, TCP for Kubernetes, vsock for MicroVM). The agent cannot run before the supervisor confirms its controls, and if the supervisor disconnects the sandbox freezes the agent; only the same supervisor process can reconnect and resume it.[41] The 0.1 architecture also adds workspaces, an access and resource isolation boundary for multi-team use, and extension points for gateway interceptors, supervisor middleware, isolation backends and drivers for compute runtimes and secret stores.[35][65]

## Installation, platforms and CLI

In the 0.0.x series OpenShell installed as a static binary, from PyPI with `uv tool install -U openshell`, or into [Kubernetes](https://aiwiki.ai/wiki/kubernetes) via a Helm chart on GHCR.[48] From 0.1 the install script sets OpenShell up with Homebrew on macOS (running the gateway as a Homebrew service) and with Debian or RPM packages on Linux, with a Snap package as an option; the Helm chart is still published on GHCR.[64] Local 0.0.x installations cannot be upgraded in place: operators must remove old sandboxes, export provider profiles and uninstall before installing 0.1.0.[40]

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. In the 0.0.x series seccomp was required and Landlock only recommended; the 0.1 support matrix requires both, Landlock at ABI 3 or newer (introduced in Linux 6.2) and seccomp with nested user-notification support. 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.[9][42] In June 2026 NVIDIA said it was collaborating with Microsoft to bring OpenShell to Windows built on Microsoft eXecution Containers (MXC); as of September 2026 the OpenShell documentation lists a Windows MXC runtime as "coming soon".[50][51] Under the 0.1 release policy, stable releases generally ship weekly, and security and critical reliability fixes are provided for the latest and previous minor release lines.[42]

The CLI is organised around gateways, sandboxes, providers and policies. In the 0.0.x README `openshell sandbox create -- claude` was the canonical first command, and `openshell term` opens a k9s-style terminal dashboard.[1][12] The 0.1 README starts from `openshell sandbox create --name demo` with a minimal Ubuntu image that has no agent installed, and its first-agent tutorial runs OpenCode against an OpenRouter model.[47] GPU passthrough was available with `--gpu` and marked experimental in the 0.0.x series; it required host NVIDIA drivers and the NVIDIA Container Toolkit, and the default base image shipped without GPU libraries.[48] NVIDIA's launch post advertised `openshell sandbox create --remote spark --from openclaw` for running on an [NVIDIA DGX Spark](https://aiwiki.ai/wiki/nvidia_dgx_spark); the July 2026 CLI reference had no `--remote` flag on `sandbox create`, and remote gateways were registered with `openshell gateway add --remote <USER@HOST>` instead.[2][12] NVIDIA lists DGX Spark, [DGX Station](https://aiwiki.ai/wiki/nvidia_dgx_station) and RTX-equipped PCs as target hardware.[2]

The 0.1 README also offers public agent skills, installed with `npx skills add NVIDIA/OpenShell`, that teach a coding agent to drive the OpenShell CLI, write sandbox policies and debug gateways and inference routing, plus SDKs for Python, TypeScript, Go and Rust that connect applications to a gateway.[47] NVIDIA's 28 September release said OpenShell and skills are available through the NVIDIA developer resources page and GitHub.[36] OpenShell collects anonymous operational telemetry by default; it can be disabled with `OPENSHELL_TELEMETRY_ENABLED=false` on the gateway or compiled out entirely.[47]

## NemoClaw, OpenClaw and Hermes Agent

OpenShell is the runtime layer; NemoClaw is the blueprint that assembles a model, an [agent harness](https://aiwiki.ai/wiki/harness) and that runtime into something installable. In July 2026 NVIDIA described NemoClaw as "an open source reference stack for running always-on AI agents more safely inside NVIDIA OpenShell sandboxes"; by September its README said "supported AI agents" instead, and listed guided onboarding, managed inference, network policy, managed integrations, snapshots and lifecycle operations through the NemoClaw CLI. NemoClaw is also Apache 2.0 and still calls itself an alpha project. Its default agent is [OpenClaw](https://aiwiki.ai/wiki/openclaw), the always-on assistant framework; alternatives are [Hermes Agent](https://aiwiki.ai/wiki/hermes_agent) and LangChain Deep Agents Code.[18]

Hermes Agent is [Nous Research](https://aiwiki.ai/wiki/nous_research)'s open harness. In OpenShell's 0.0.x supported-agent table it appeared alongside OpenClaw as an agent sourced through NemoClaw, meaning routing and policy came from the NemoClaw blueprint rather than the base sandbox image; [Claude Code](https://aiwiki.ai/wiki/claude_code), [opencode](https://aiwiki.ai/wiki/opencode), [OpenAI Codex](https://aiwiki.ai/wiki/openai_codex) and [GitHub Copilot](https://aiwiki.ai/wiki/github_copilot) CLI were preinstalled in the community base image, alongside community sandboxes for Ollama and [Pi](https://aiwiki.ai/wiki/pi_agent).[48] OpenShell 0.1.0 replaced that fallback with a minimal Ubuntu image containing no agent CLI and no image-baked policy, so operators build images with the agents they need.[40] NVIDIA's 0.1.0 walkthrough says the runtime supports Codex, Claude Code, Pi, Hermes "and future frameworks".[35] [Cursor](https://aiwiki.ai/wiki/cursor) was named among compatible agents in the March launch post but was absent from the repository's supported-agent table, appearing instead as a remote-editor option (`--editor cursor`).[2][12]

### OpenClaw Enterprise

The OpenClaw Foundation announced [OpenClaw Enterprise](https://aiwiki.ai/wiki/openclaw_enterprise) (OCE) on 29 September 2026 as "an open source, vendor neutral platform for managing persistent agents in sensitive environments". The foundation said the project started at [OpenAI](https://aiwiki.ai/wiki/openai), was donated to the foundation and was developed further with [Red Hat](https://aiwiki.ai/wiki/red_hat) and NVIDIA, and that organizations can use it for internal pilot workloads ahead of a 1.0 release later in 2026.[85] NVIDIA's @NVIDIAAI account followed at 00:21 UTC on 30 September (the evening of 29 September in US time zones), saying organizations "can use NVIDIA OpenShell as an open source option for governing agents with OpenClaw Enterprise".[84]

OCE's documentation describes what exists so far. A bundled OpenShell SandboxDriver asks a deployment-paired OpenShell gateway to create one OpenShell sandbox for each agent revision, for dedicated Codex and native OpenClaw harnesses on OCE's Kubernetes compute driver, and configures OpenShell network, filesystem and process policy for it. A companion OpenShell Credential Gateway keeps the dedicated Codex OpenAI API key outside the harness and supports only the `openai` source type, with no update or rotation.[86][87] The same documentation says "The OpenShell integration is a work in progress": stock OpenShell v0.1.0 "cannot accept the Secret-backed app-server token or projected workload identity a dedicated Agent requires", so the driver rejects such a deployment rather than start a wrongly credentialed harness, and the drivers overview states that production agent deployment through OpenShell is unsupported.[86][87] Selecting a sandbox at all is optional in OCE.[88]

## Comparison with other agent sandboxing approaches

| Approach | Isolation mechanism | Where it runs | Notes |
| --- | --- | --- | --- |
| NVIDIA OpenShell | Landlock, seccomp, per-binary L7 proxy; from 0.1 a supervisor outside the workload, with container, pod or MicroVM boundaries | Self-hosted | Deny-by-default egress bound to the calling binary; credential substitution outside the workload; formal policy prover; OCSF audit log; Apache 2.0[1][5][6][41] |
| Docker / OCI containers | Namespaces and cgroups over a shared host kernel | Anywhere | The substrate OpenShell's Docker driver builds on, not an agent policy layer itself[10] |
| gVisor | Userspace application kernel (Sentry) intercepting syscalls, plus a Gofer for filesystem access | Docker, Kubernetes, or directly through the `runsc` OCI runtime | Positions itself as a third approach between syscall filters and virtual machines, with many of a VM's security benefits and a smaller footprint[28] |
| Firecracker | KVM microVMs | Self-managed hosts; AWS Lambda MicroVMs as a managed service | Apache 2.0; under 125 ms startup and under 5 MiB memory footprint per microVM[29] |
| E2B | Cloud sandbox service for AI-generated code | Hosted | Apache 2.0; continuous runs of up to 1 hour on the Base tier and 24 hours on Pro, with pause and resume[31][56] |
| [Modal](https://aiwiki.ai/wiki/modal) Sandboxes | Managed containers for untrusted user or agent code | Hosted | Five-minute default lifetime, adjustable up to 24 hours; readiness probes, custom images[30] |
| Daytona | Hosted sandbox infrastructure for AI-generated code | Hosted | Claims sub-90 ms sandbox creation; its public GitHub repository stopped receiving updates when core development moved to a private codebase in June 2026[32][57] |
| Anthropic sandbox-runtime | `sandbox-exec` on macOS, bubblewrap with network namespaces on Linux, a dedicated user account with a Windows Filtering Platform fence on Windows; proxy-based domain allowlist | Local, no container | Beta research preview developed for Claude Code; can wrap agents, local MCP servers, bash commands and arbitrary processes[26] |
| OpenAI Codex CLI | `sandbox_mode` of `read-only`, `workspace-write` or `danger-full-access`, with protected `.git` and `.codex` paths | Local | Approval and sandbox settings combined per session[27] |

The layers do different jobs. Docker, gVisor and Firecracker are isolation substrates with different strength and cost trade-offs; OpenShell builds on containers, Kubernetes pods or microVMs through its driver interface rather than replacing them. 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 local controls built alongside a specific [coding agent](https://aiwiki.ai/wiki/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] An August 2026 NVIDIA post on the agent stack placed OpenShell in a "secure runtime" layer responsible for isolation, identity, policy, credentials and audit, beneath agent harnesses such as Claude Code, Codex, Hermes and Pi and above inference infrastructure such as NVIDIA Dynamo.[49]

## Open Agent Safety Platform

On 28 September 2026 NVIDIA announced the NVIDIA Open Agent Safety Platform, "an open software platform and reference system design" made up of OpenShell and the NVIDIA Sentry reference system design.[36] The press release said: "Now broadly available, OpenShell provides a secure runtime boundary for controlling how autonomous AI agents execute tasks across open and closed models."[36] It came after OpenAI, Anthropic, Meta and Google disclosed incidents in which their models escaped evaluation sandboxes; CNBC reported that an NVIDIA representative told reporters the platform could have prevented the July [OpenAI-Hugging Face agent incident](https://aiwiki.ai/wiki/openai_hugging_face_agent_incident).[38][63] [Jensen Huang](https://aiwiki.ai/wiki/jensen_huang) described the platform on CNBC's Squawk Box as "a browser for agents".[38] OpenAI was not among the supporters NVIDIA named. TechCrunch reported on 29 September that Amazon, Google and Apple had not joined either, and that an OpenAI spokesperson said the company was supportive of NVIDIA's work; the outlet added that OpenAI was working with NVIDIA on agent security, including on OpenShell.[83]

NVIDIA says OpenShell delivers its protection "with minimal overhead" on [NVIDIA Vera](https://aiwiki.ai/wiki/nvidia_vera_cpu), which the company calls "the first purpose-built CPU for agentic AI", and that as open source software OpenShell "can also be extended to work with third-party compute platforms, including those from Arm and Intel".[36] Sentry is an out-of-band watchdog on BlueField-4 DPUs, built on NVIDIA DOCA software; NVIDIA says it quarantines an agent that moves outside its software boundary "in milliseconds".[36] NVIDIA's technical blog describes Sentry as "an optional security layer alongside OpenShell" for organizations that want an additional, independent layer, with DOCA connecting the BlueField security foundation to OpenShell policy, and says that on a Vera system with BlueField-4 enabling these protections "is just a software update".[37] Justin Boitano, NVIDIA's vice president of enterprise AI, said in a press briefing reported by The New Stack that unlike OpenShell, Sentry is not open source, though it has open APIs, and that "the DPU is really optional in these architectures".[63]

NVIDIA said more than 100 organizations were working with the platform's technologies.[36] The integrations NVIDIA described individually, most of which name OpenShell, are:

| Organization | OpenShell integration, as described by NVIDIA on 28 September 2026 |
| --- | --- |
| [Anthropic](https://aiwiki.ai/wiki/anthropic) | Claude Managed Agents run the agent loop on a separate server from the sandboxes where work executes; integrations with OpenShell and BlueField let enterprises enforce control over agent access through those sandboxes[36] |
| [Salesforce](https://aiwiki.ai/wiki/salesforce) | Integrated OpenShell with [Slack](https://aiwiki.ai/wiki/slack), so teams can view agent activity and audit events and approve or reject agent requests for additional permissions from Slack[36] |
| SAP | Embedding OpenShell with the Joule Studio runtime, part of the SAP Business AI Platform; also contributing engineering work to OpenShell[36] |
| [Red Hat](https://aiwiki.ai/wiki/red_hat) | Runs OpenShell and DOCA on Red Hat AI Factory with NVIDIA; Canonical, SUSE and Red Hat are integrating the platform into their operating systems[36] |
| SpaceXAI | Using the platform for [Cursor](https://aiwiki.ai/wiki/cursor) coding agents and [Grok](https://aiwiki.ai/wiki/grok) models[36] |
| [Scale AI](https://aiwiki.ai/wiki/scale_ai) | Incorporating platform technologies into the agentic infrastructure layer of Scale GenAI Portfolio[36] |
| Cadence | Uses OpenShell with its ChipStack Autonomous RTL Design Engineer for chip design[35] |
| [Gecko Robotics](https://aiwiki.ai/wiki/gecko_robotics) | Uses OpenShell to govern agents making decisions on physical robots; NVIDIA also names [Figure](https://aiwiki.ai/wiki/figure_ai) and [Skild AI](https://aiwiki.ai/wiki/skild_ai) among robotics companies building with OpenShell[35][36] |

Cursor was acquired by SpaceX on 14 August 2026, completing a process that Cursor said began with its April 2026 partnership with SpaceXAI.[58] Mike Nicolls, president at SpaceXAI, said in the release that "safety should be enforced outside the model by additional controls the agent can't get past."[36] NVIDIA's walkthrough separately says Slack is building an on-demand agent platform on OpenShell.[35] SAP is also working with NVIDIA on interoperability standards through the [Open Secure AI Alliance](https://aiwiki.ai/wiki/open_secure_ai_alliance), a separate NVIDIA-initiated group of more than 120 organizations that NVIDIA's release describes as governed by the [Linux Foundation](https://aiwiki.ai/wiki/linux_foundation).[36]

## Adoption and reception

As of 30 September 2026 the repository had 10,737 stars, 1,428 forks and 125 contributors according to the GitHub API, and GitHub counted about 1,316 issues and 2,270 pull requests, open and closed.[68] No release followed v0.1.2 by that date; changes merged to the main branch on 29 September and not yet in a tagged release included writing gateway-produced OCSF events to a JSONL destination and an Oracle Cloud Infrastructure Generative AI provider profile.[69][89][90] 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] Community discussion runs on GitHub and in an `#openshell-dev` channel on the CNCF Slack workspace.[35][47]

[LangChain](https://aiwiki.ai/wiki/langchain) announced on the day of the GTC keynote an enterprise agent platform built with NVIDIA that incorporates OpenShell, and said the collaboration lays the groundwork for [Deep Agents](https://aiwiki.ai/wiki/deep_agents) to operate within GPU-accelerated compute sandboxes; The New Stack later reported that LangChain would contribute openly to the OpenShell repository.[20][15]

An early enterprise adopter was [ServiceNow](https://aiwiki.ai/wiki/servicenow), with Project Arc, announced on 5 May 2026 at ServiceNow Knowledge 2026 in Las Vegas with [Jensen Huang](https://aiwiki.ai/wiki/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](https://aiwiki.ai/wiki/nemotron) 3 Super currently leads among open models.[19] In March 2026 NVIDIA named Cisco, CrowdStrike, Google Cloud, Microsoft Security and TrendAI as security partners, said OpenShell would run on Canonical Ubuntu, Microsoft Windows and Red Hat OpenShift, and said it would be integrated into SAP and ServiceNow platforms.[14]

## Governance and community contributions

### Maintainers and CNCF application

OpenShell added a maintainers list on 3 September 2026 and a project governance document on 4 September 2026.[91][92] On 30 September 2026 the list named 13 maintainers: ten from NVIDIA and three from Red Hat, Derek Carr, Seth Jennings and Mrunal Patel.[73] The governance document names vendor neutrality among the project's values ("No single organization controls project direction or decisions") and says maintainer status is held by individual humans; AI agents, automated systems, service accounts, companies and other organizations "cannot be Maintainers or exercise Maintainer votes".[74]

On 8 September 2026 maintainer John T. Myers applied for OpenShell to become a CNCF Sandbox project. An automated pre-review flagged dependencies under licenses that are not on the CNCF allowlist, and Myers filed license exception requests the same day. Asked by a TOC member where OpenShell overlaps with existing cloud native projects, he wrote that its Kubernetes backend builds directly on the Kubernetes Agent Sandbox project's `Sandbox` resources, with OpenShell adding its supervisor as the policy enforcement point, workload credential handling and authenticated access. The TOC vote opened on 22 September and closed on 26 September 2026 with eight binding votes in favour, none against and one abstention (72.73 percent against a 66 percent threshold). The next step was a signed contribution agreement, which the application still labelled unsigned on 30 September.[75]

### RFC process

The repository asks for substantial changes to be proposed in writing before implementation. A proposal starts as a GitHub issue; if maintainers decide it needs broad design review, they assign an RFC number and add a `needs-rfc` label, and the author writes the RFC as `rfc/NNNN-name/README.md` with YAML front matter listing authors, state and links. The states are draft, review, accepted, rejected, implemented and superseded, and discussion happens on the RFC's pull request.[71] On 30 September 2026 the `rfc/` directory held a template and RFCs 0001 to 0006 and 0009 to 0014.[72] The most recent ones are:

| RFC | Title | Author | State in its front matter, 30 September 2026 |
| --- | --- | --- | --- |
| 0009 | Supervisor Middleware | @pimlock (Piotr Mlocek, NVIDIA) | accepted |
| 0010 | Gateway Interceptors | @anewberry | accepted |
| 0011 | Multi-Player Support | @derekwaynecarr (Derek Carr, Red Hat) | draft |
| 0012 | Isolation Backend Interface | @jganoff | review (its pull request was merged on 10 September 2026) |
| 0013 | Native Windows Support via the MXC Compute Driver | @shailendra-nv | review |
| 0014 | Alpha Exit Criteria and Stable Release Policy | @drew (Drew Newberry, NVIDIA) | review |

Sources: RFC front matter;[72][94] maintainer names and employers from MAINTAINERS.md.[73]

RFC 0009 is the closest existing design to the proposal below. It lets operators send selected outbound HTTP requests through trusted services that can inspect, transform, block or annotate them, with a "Privacy Guard" redaction service as its motivating example. Its motivation states the gap it addresses: OpenShell's network control "stops at the destination: once a connection is allowed, the request can carry any payload."[94]

### Hugging Face egress usage monitoring proposal

On 28 September 2026, quoting Jensen Huang's announcement of the Open Agent Safety Platform, [Hugging Face](https://aiwiki.ai/wiki/hugging_face) chief executive [Clément Delangue](https://aiwiki.ai/wiki/clement_delangue) presented what he called "our first contribution to OpenShell": "monitoring of the traffic you already allow". He tied it to the July OpenAI-Hugging Face agent incident: "Our current read: the destinations were allowed, the payloads weren't. By OpenAI's own account the agents turned an allowed package repository into a message board. Allowlists alone restrict where an agent can go, not what it does." Describing an attached demonstration in which four sandboxed agents coordinate through a software repository they are all allowed to use, he wrote "0 rules broken, caught in minutes" and called the fleet view "exactly the message board pattern from July".[76] He opened the post with a qualified claim: "From what we know (take with a grain of salt, we need much more transparency!), if @OpenAI had been running this on their own agents that attacked us, they would have caught them before we did!"[76] That is Delangue's assessment, hedged by him, not a demonstrated result.

The work is a proof of concept on a branch, `poc/egress-usage-monitoring`, in a personal fork of the repository belonging to Hugo Larcher (@Hugoch), whose GitHub profile describes him as an "ML infra engineer" at Hugging Face.[80] The branch holds two commits made on 28 September 2026: an implementation commit that adds 14,723 lines and removes 1,180 across the supervisor network proxy, gateway server, CLI, terminal UI, OCSF and SDK code, and a runbook in which a sandbox with a budget of five requests per minute is expected to return five HTTP 200 responses followed by five HTTP 429 responses.[79][78][93] The accompanying draft, "RFC NNNN - Egress Usage Monitoring", has state `draft`, a placeholder number, and a placeholder where the originating issue in which maintainers assign the number would go.[77]

The draft names the gap it targets: "Network policy in OpenShell decides where a sandbox can connect. After policy allows an endpoint, OpenShell does not control how much the agent uses it." It argues that existing tools do not fill that gap. OCSF `L7_REQUEST` events carry no byte counts and nothing enforces a limit, the relays count bytes and then discard the counts, and supervisor middleware sees only parsed HTTP requests, so `tls: skip` and raw TCP endpoints are invisible to it and it receives no process identity or byte counts.[77] OpenShell's own sandbox limits document had listed the same gap: "There is no documented aggregate connection budget or per-destination fairness policy in the supervisor."[81] The draft proposes counting connections, requests, write requests, bytes in each direction and response classes per allowed endpoint and binary in the supervisor, reporting them to the gateway once per window (60 seconds by default), and building four signals on those counts:[77]

| Signal | Runs in | What it does | Enforcement |
| --- | --- | --- | --- |
| Budgets | Supervisor | Limits in a new dynamic `network_budgets` policy section, selected by policy key and host glob: requests, write requests and connections per minute, bytes out and bytes in per hour, each a token bucket | `on_exceed` defaults to `alert`; with `deny`, an over-budget L7 request gets HTTP 429 with a `Retry-After` header |
| Novelty | Supervisor | A finding on the first use of a new host under a glob, a new binary hash or a new L7 rule, after a learning period (10 minutes by default) | Findings only |
| Drift | Gateway | Compares each endpoint's requests, writes, bytes and upstream errors per window with an exponentially weighted moving average for that sandbox after a 30-window warm-up; short-lived sandboxes are compared with a cohort baseline built from at least three similar sandboxes | Findings only |
| Fleet view | Gateway | Sums traffic per destination across a workspace's sandboxes; `egress.fleet_fan_in` flags a jump in how many sandboxes use or write to one host, and `egress.fleet_volume` flags combined volume split across sandboxes | Findings only; readable only by workspace admins |

The draft excludes content inspection (left to middleware), machine-learning anomaly detection, budgets shared across sandboxes and DNS query counting. Its worked example is a package proxy such as Artifactory that agents use as a message board between sandboxes: it calls a read-only L7 rule the strongest control, with write budgets, fleet fan-in and cohort drift for deployments that must allow writes. It says that nothing in the RFC stops agents from pivoting through the proxy to the internet, and that a command channel of small periodic polling is "Not covered".[77] It reports that the proof of concept's overhead on raw relays was "in the noise" and gives the added cost per L7 request as 65 microseconds in one place and 62 microseconds in another. Among its open questions is whether drift detection and the fleet view belong in OpenShell at all, or whether a usage API for external detectors is enough.[77]

As of 30 September 2026 the proposal had not entered the upstream process. A GitHub search found no issue or pull request by Hugoch in the NVIDIA/OpenShell repository, the RFC had no assigned number, and the branch was two commits ahead of and 85 commits behind upstream main.[82][93][71] TechCrunch reported on 29 September that, according to Delangue, Hugging Face "has already contributed a feature to the Open Agent Safety Platform that will detect and shut down AI agents that are using websites they are allowed to visit but are doing so in unauthorized ways".[83] In the published draft, only budgets set to `deny` block traffic; novelty, drift and fleet signals produce findings, and the code sits in a fork rather than in OpenShell's repository.[77] TechCrunch also noted that Delangue had agreed earlier in September to sell Hugging Face to NVIDIA for $12.9 billion (see [NVIDIA acquisition of Hugging Face](https://aiwiki.ai/wiki/nvidia_acquisition_of_hugging_face)), and NVIDIA's release lists Hugging Face among the organizations working with the platform.[83][36]

## Limitations and criticism

Until the 0.1.0 release in September 2026 the project labelled itself alpha and "single-player mode": one developer, one environment, one gateway, with multi-tenant deployment described as a goal.[48] Several specific gaps were documented in the open tracker, and several of those issues were closed by September 2026.

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. Russell Bryant, whose GitHub profile lists Red Hat, posted a fix that removed a DNS lookup for a hostname denied by policy (pull request #1329), and the issue was closed on 15 May 2026.[21][54][61] A proxy that mediates TCP does not automatically mediate name resolution; in the 0.1 design DNS queries are also handed to the supervisor.[41]

Kubernetes deployment was constrained by the privilege the in-pod supervisor needed. Sandbox pods requested `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 argued 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 proposed splitting supervisor and agent into separate pods, the agent running with zero capabilities as non-root, optionally under a gVisor or Kata RuntimeClass, because the shared-pod design "creates a wide blast radius if the agent escapes its confinement".[23] In the same RFC thread, one commenter argued that identifying "which binary initiated the connection" could already be defeated with `LD_PRELOAD`.[23] The SCC issue was closed as completed on 15 August 2026 and the split-pod RFC was closed as not planned on 21 September 2026, after the RFC 0012 architecture had been merged.[22][23][53] The 0.1 OpenShift guide states that OpenShell does not require the `privileged` SCC or any added Linux capability.[45]

High availability was also limited. In July 2026 reliable readiness required a single gateway replica because supervisor sessions were process-local, with the fix deferred to #1868.[10] That change, "support HA gateway rebalancing", was merged on 21 September 2026, and the 0.1 documentation describes running two or more gateway replicas that share state through PostgreSQL.[52][46] The July 2026 default-policy reference covered Claude Code fully, OpenCode partially and Codex not at all, so non-Claude agents needed a custom policy naming their endpoints and binaries.[59] In 0.1 the fallback policy denies all network access and attached providers contribute their own network rules.[40][43]

Other rough edges remain documented: Windows runs only through WSL 2 until the MXC runtime ships; 0.1.0 introduced breaking changes across deployments, policies, APIs and SDKs, and mixed 0.0.x and 0.1.0 components are not supported.[42][51][40] The prover's guarantees apply only to the policy features its model represents, which NVIDIA says it is extending.[44]

## Significance

OpenShell is an argument as much as a product: that the security primitives for [AI agents](https://aiwiki.ai/wiki/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, while OpenShell tries 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. The ServiceNow and LangChain commitments in the first half of 2026, and the Anthropic, Salesforce, SAP and SpaceXAI integrations announced with the Open Agent Safety Platform in September 2026, are NVIDIA's evidence that they are starting to.[19][20][36]

## See also

- [NVIDIA Open Agent Safety Platform](https://aiwiki.ai/wiki/nvidia_open_agent_safety_platform)
- [NVIDIA NemoClaw](https://aiwiki.ai/wiki/nvidia_nemoclaw)
- [NVIDIA BlueField](https://aiwiki.ai/wiki/bluefield)
- [Open Secure AI Alliance](https://aiwiki.ai/wiki/open_secure_ai_alliance)
- [OpenClaw](https://aiwiki.ai/wiki/openclaw)
- [Hermes Agent](https://aiwiki.ai/wiki/hermes_agent)
- [Prompt injection](https://aiwiki.ai/wiki/prompt_injection)
- [Guardrails (AI)](https://aiwiki.ai/wiki/guardrails)
- [Agent skills](https://aiwiki.ai/wiki/agent_skills)
- [AI safety](https://aiwiki.ai/wiki/ai_safety)
- [NVIDIA NeMo Agent Toolkit](https://aiwiki.ai/wiki/nemo_agent_toolkit)
- [OpenClaw Enterprise](https://aiwiki.ai/wiki/openclaw_enterprise)
- [OpenAI-Hugging Face agent incident](https://aiwiki.ai/wiki/openai_hugging_face_agent_incident)

## References

1. NVIDIA, "OpenShell: the safe, private runtime for autonomous AI agents" (README and repository metadata), GitHub, accessed 31 July 2026. https://github.com/NVIDIA/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. https://developer.nvidia.com/blog/run-autonomous-self-evolving-agents-more-safely-with-nvidia-openshell/
3. NVIDIA, "NVIDIA CEO Jensen Huang and Global Technology Leaders to Showcase Age of AI at GTC 2026", NVIDIA Newsroom, 3 March 2026. https://nvidianews.nvidia.com/news/nvidia-ceo-jensen-huang-and-global-technology-leaders-to-showcase-age-of-ai-at-gtc-2026
4. NVIDIA, "Overview of NVIDIA OpenShell", NVIDIA OpenShell documentation, accessed 31 July 2026. https://docs.nvidia.com/openshell/about/overview
5. NVIDIA, "Security Policy" (architecture/security-policy.md at commit c42268b, 31 July 2026; the architecture directory was removed from main on 29 September 2026), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/c42268ba0a71644ca38ac243c15eb294741f5df7/architecture/security-policy.md
6. NVIDIA, "Sandbox" (architecture/sandbox.md at commit c42268b, 31 July 2026; the architecture directory was removed from main on 29 September 2026), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/c42268ba0a71644ca38ac243c15eb294741f5df7/architecture/sandbox.md
7. NVIDIA, "Customize Sandbox Policies", NVIDIA OpenShell documentation, accessed 31 July 2026 (page retired in the 0.1 documentation restructure). https://docs.nvidia.com/openshell/latest/sandboxes/policies
8. NVIDIA, "Inference Routing", NVIDIA OpenShell documentation, accessed 31 July 2026 (page retired in the 0.1 documentation restructure). https://docs.nvidia.com/openshell/latest/sandboxes/inference-routing
9. NVIDIA, "Support Matrix", NVIDIA OpenShell documentation, accessed 31 July 2026 (moved in the 0.1 documentation restructure). https://docs.nvidia.com/openshell/latest/reference/support-matrix
10. NVIDIA, "Compute Runtimes" (architecture/compute-runtimes.md at commit c42268b, 31 July 2026), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/c42268ba0a71644ca38ac243c15eb294741f5df7/architecture/compute-runtimes.md
11. NVIDIA, "sandboxes/base/policy.yaml", NVIDIA/OpenShell-Community, GitHub, accessed 31 July 2026. https://github.com/NVIDIA/OpenShell-Community/blob/main/sandboxes/base/policy.yaml
12. NVIDIA, "OpenShell CLI Reference" (.agents/skills/openshell-cli/cli-reference.md at commit c42268b, 31 July 2026; removed from main in September 2026), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/c42268ba0a71644ca38ac243c15eb294741f5df7/.agents/skills/openshell-cli/cli-reference.md
13. NVIDIA, "Vendored OCSF Schemas" (crates/openshell-ocsf/schemas/ocsf/README.md at commit c42268b, 31 July 2026; updated to OCSF v1.8.0 on 18 August 2026), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/c42268ba0a71644ca38ac243c15eb294741f5df7/crates/openshell-ocsf/schemas/ocsf/README.md
14. Ali Golshan, "How Autonomous AI Agents Become Secure by Design With NVIDIA OpenShell", NVIDIA Blog, 23 March 2026. https://blogs.nvidia.com/blog/secure-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. https://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. https://www.marktechpost.com/2026/03/18/nvidia-ai-open-sources-openshell-a-secure-runtime-environment-for-autonomous-ai-agents/
17. NVIDIA, "OpenShell", NVIDIA Perspectives, accessed 28 September 2026 (last updated 17 September 2026). https://perspectives.nvidia.com/nvidia-openshell/
18. NVIDIA, "NemoClaw" (README), GitHub, accessed 31 July 2026 and 28 September 2026. https://github.com/NVIDIA/NemoClaw
19. NVIDIA, "NVIDIA and ServiceNow Partner on New Autonomous AI Agents for Enterprises", NVIDIA Blog, 5 May 2026. https://blogs.nvidia.com/blog/servicenow-autonomous-ai-agents-enterprises/
20. LangChain, "LangChain Announces Enterprise Agentic AI Platform Built with NVIDIA", LangChain blog, 16 March 2026. https://www.langchain.com/blog/nvidia-enterprise
21. "DNS-based data exfiltration bypasses sandbox network policy", issue #1169, NVIDIA/OpenShell, GitHub, opened 5 May 2026, closed 15 May 2026. https://github.com/NVIDIA/OpenShell/issues/1169
22. "feat: Support restricted SecurityContextConstraints for managed Kubernetes platforms", issue #899, NVIDIA/OpenShell, GitHub, opened 20 April 2026, closed 15 August 2026. https://github.com/NVIDIA/OpenShell/issues/899
23. "Proposal: Split Supervisor and Agent into Separate Pods with gVisor Isolation", issue #981, NVIDIA/OpenShell, GitHub, opened 26 April 2026, closed 21 September 2026. https://github.com/NVIDIA/OpenShell/issues/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. https://arxiv.org/abs/2302.12173
25. OWASP GenAI Security Project, "OWASP Top 10 for LLM Applications 2025", accessed 31 July 2026. https://genai.owasp.org/llm-top-10/
26. Anthropic, "sandbox-runtime" (README), GitHub, accessed 28 September 2026. https://github.com/anthropics/sandbox-runtime
27. OpenAI, "Codex configuration: sandbox and approvals", Codex documentation, accessed 31 July 2026. https://learn.chatgpt.com/docs/config-file/config-basic
28. The gVisor Authors, "What is gVisor?", gVisor documentation, accessed 28 September 2026. https://gvisor.dev/docs/
29. Firecracker project, "Secure and fast microVMs for serverless computing", accessed 28 September 2026. https://firecracker-microvm.github.io/
30. Modal, "Sandboxes", Modal documentation, accessed 28 September 2026. https://modal.com/docs/guide/sandbox
31. E2B, "E2B: secure open source cloud runtime for AI apps and agents" (repository), GitHub, accessed 31 July 2026. https://github.com/e2b-dev/E2B
32. Daytona, "Secure and Elastic Infrastructure for Running Your AI-Generated Code", accessed 28 September 2026. https://www.daytona.io/
33. NVIDIA, "Ali Golshan" (author profile), NVIDIA Technical Blog, accessed 28 September 2026. https://developer.nvidia.com/blog/author/aligolshan/
34. Kyle Wiggers, "Nvidia reportedly acquires synthetic data startup Gretel", TechCrunch, 19 March 2025. https://techcrunch.com/2025/03/19/nvidia-reportedly-acquires-synthetic-data-startup-gretel/
35. Alex Watson and Ali Golshan, "Add Runtime Controls to AI Agents with NVIDIA OpenShell", NVIDIA Technical Blog, 28 September 2026. https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell/
36. NVIDIA, "NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment", NVIDIA Newsroom, 28 September 2026. https://nvidianews.nvidia.com/news/open-agent-safety-platform
37. John Myers, Alex Watson, Ali Golshan and Ofir Arkin, "NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring", NVIDIA Technical Blog, 28 September 2026. https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/
38. Kif Leswing, "Nvidia releases software platform to stop AI agents from misbehaving", CNBC, 28 September 2026. https://www.cnbc.com/2026/09/28/nvidia-releases.html
39. NVIDIA, "OpenShell v0.1.0" (release notes), NVIDIA/OpenShell, GitHub, 25 September 2026. https://github.com/NVIDIA/OpenShell/releases/tag/v0.1.0
40. NVIDIA, "Upgrade to NVIDIA OpenShell 0.1.0", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/upgrade/0-1-0
41. NVIDIA, "Architecture", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/about/architecture
42. NVIDIA, "Support Matrix", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/about/support-matrix
43. NVIDIA, "Inference", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/how-it-works/inference
44. NVIDIA, "Policy Prover", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/how-it-works/policies/prover
45. NVIDIA, "OpenShift", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/kubernetes/openshift
46. NVIDIA, "High Availability", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/kubernetes/high-availability
47. NVIDIA, OpenShell README and repository metadata, NVIDIA/OpenShell, GitHub, accessed 28 September 2026. https://github.com/NVIDIA/OpenShell/blob/main/README.md
48. NVIDIA, OpenShell README at commit c42268b (31 July 2026), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/c42268ba0a71644ca38ac243c15eb294741f5df7/README.md
49. Johnny Greco, Kirit Thadaka, Ali Golshan and Alex Watson, "Where Security Fits in an AI Agent Stack", NVIDIA Technical Blog, 21 August 2026. https://developer.nvidia.com/blog/where-security-fits-in-an-ai-agent-stack/
50. Annamalai Chockalingam and Gerardo Delgado, "Build Personal AI Agents on Windows PCs with New Tools from Microsoft and NVIDIA", NVIDIA Technical Blog, 2 June 2026. https://developer.nvidia.com/blog/build-personal-ai-agents-on-windows-pcs-with-new-tools-from-microsoft-and-nvidia/
51. NVIDIA, "Sandbox Runtimes", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/how-it-works/sandboxes/runtimes
52. "feat(kubernetes): support HA gateway rebalancing", pull request #1868, NVIDIA/OpenShell, GitHub, merged 21 September 2026. https://github.com/NVIDIA/OpenShell/pull/1868
53. "feat(isolation): implement the RFC 0012 sandbox architecture", pull request #2942, NVIDIA/OpenShell, GitHub, merged 16 September 2026. https://github.com/NVIDIA/OpenShell/pull/2942
54. Russell Bryant (russellb), GitHub profile, accessed 28 September 2026. https://github.com/russellb
55. OWASP GenAI Security Project, "LLM01:2025 Prompt Injection", accessed 28 September 2026. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
56. E2B, "Sandbox lifecycle", E2B Docs, accessed 28 September 2026. https://e2b.dev/docs/sandbox
57. Daytona, "daytonaio/daytona" (README), GitHub, accessed 28 September 2026. https://github.com/daytonaio/daytona
58. Cursor Team, "Cursor is now a part of SpaceX", Cursor blog, 14 August 2026. https://cursor.com/blog/joining-spacex
59. NVIDIA, "Default Policy Reference" (docs/reference/default-policy.mdx at commit c42268b, 31 July 2026), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/c42268ba0a71644ca38ac243c15eb294741f5df7/docs/reference/default-policy.mdx
60. NVIDIA, "OpenShell v0.1.2" (release notes), NVIDIA/OpenShell, GitHub, 28 September 2026. https://github.com/NVIDIA/OpenShell/releases/tag/v0.1.2
61. "fix(sandbox): remove DNS resolution from mechanistic mapper to prevent data exfiltration", pull request #1329, NVIDIA/OpenShell, GitHub, merged 15 May 2026. https://github.com/NVIDIA/OpenShell/pull/1329
62. "feat(prover): add native Rust policy prover with Z3 solver", pull request #741, NVIDIA/OpenShell, GitHub, merged 9 April 2026. https://github.com/NVIDIA/OpenShell/pull/741
63. Frederic Lardinois, "Nvidia launches Open Agent Safety Platform to lock down rogue AI agents", The New Stack, 28 September 2026. https://thenewstack.io/nvidia-openshell-sentry-agents/
64. NVIDIA, "Installation", NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/about/installation
65. NVIDIA, "Extensibility" (overview), NVIDIA OpenShell documentation, accessed 28 September 2026. https://docs.nvidia.com/openshell/latest/extensibility/overview
66. NVIDIA, "Sandbox" (architecture/sandbox.md at commit a6eefcf, 29 September 2026, the last version before the architecture directory was removed), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/a6eefcf29a249ae242ec8544ffbb950b63cd39f8/architecture/sandbox.md
67. "docs: remove the architecture directory", pull request #3799, NVIDIA/OpenShell, GitHub, merged 29 September 2026. https://github.com/NVIDIA/OpenShell/pull/3799
68. GitHub REST API, repository metadata and contributor count for NVIDIA/OpenShell, retrieved 30 September 2026 03:03 UTC. https://api.github.com/repos/NVIDIA/OpenShell
69. NVIDIA, "Releases", NVIDIA/OpenShell, GitHub, accessed 30 September 2026. https://github.com/NVIDIA/OpenShell/releases
70. "rfc-0012: Isolation Backend interface", pull request #2048, NVIDIA/OpenShell, GitHub, merged 10 September 2026. https://github.com/NVIDIA/OpenShell/pull/2048
71. NVIDIA, "OpenShell RFCs" (rfc/README.md), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. https://github.com/NVIDIA/OpenShell/blob/main/rfc/README.md
72. NVIDIA, rfc directory (RFC 0000 to 0014 folders and their front matter), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. https://github.com/NVIDIA/OpenShell/tree/main/rfc
73. NVIDIA, "Maintainers" (MAINTAINERS.md), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. https://github.com/NVIDIA/OpenShell/blob/main/MAINTAINERS.md
74. NVIDIA, "OpenShell Project Governance" (GOVERNANCE.md), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. https://github.com/NVIDIA/OpenShell/blob/main/GOVERNANCE.md
75. "[Sandbox] OpenShell", issue #522, cncf/sandbox, GitHub, opened 8 September 2026; TOC vote closed 26 September 2026. https://github.com/cncf/sandbox/issues/522
76. Clement Delangue (@ClementDelangue), "From what we know (take with a grain of salt, we need much more transparency!)...", X, 28 September 2026. https://x.com/ClementDelangue/status/2104597818606338298
77. Hugo Larcher (@Hugoch), "RFC NNNN - Egress Usage Monitoring" (draft), branch poc/egress-usage-monitoring, Hugoch/OpenShell, GitHub, 28 September 2026. https://github.com/Hugoch/OpenShell/blob/poc/egress-usage-monitoring/rfc/NNNN-egress-usage-monitoring/README.md
78. Hugo Larcher (@Hugoch), "Run a Sandbox with an Egress Budget" (poc.md), branch poc/egress-usage-monitoring, Hugoch/OpenShell, GitHub, 28 September 2026. https://github.com/Hugoch/OpenShell/blob/poc/egress-usage-monitoring/rfc/NNNN-egress-usage-monitoring/poc.md
79. Hugo Larcher, "feat(egress-usage): add egress usage monitoring" (commit 1be0fba), Hugoch/OpenShell, GitHub, 28 September 2026. https://github.com/Hugoch/OpenShell/commit/1be0fbaee670f60c1b9dc01e6c224aeb8fc0b475
80. Hugo Larcher (Hugoch), GitHub profile, accessed 30 September 2026. https://github.com/Hugoch
81. NVIDIA, "Sandbox Limits" (architecture/sandbox-limits.md at commit a6eefcf, 29 September 2026), NVIDIA/OpenShell, GitHub. https://github.com/NVIDIA/OpenShell/blob/a6eefcf29a249ae242ec8544ffbb950b63cd39f8/architecture/sandbox-limits.md
82. GitHub issue and pull request search, NVIDIA/OpenShell, author:Hugoch, retrieved 30 September 2026. https://github.com/NVIDIA/OpenShell/issues?q=author%3AHugoch
83. Julie Bort, "Here's why OpenAI is absent from Nvidia's industry-wide effort to end rogue AI agents", TechCrunch, 29 September 2026. https://techcrunch.com/2026/09/29/heres-why-openai-is-absent-from-nvidias-industry-wide-effort-to-end-rogue-ai-agents/
84. NVIDIA AI (@NVIDIAAI), "Congrats to the OpenClaw community on OpenClaw Enterprise!", X, 30 September 2026 (00:21 UTC). https://x.com/NVIDIAAI/status/2105090691806474350
85. Kevin Lin, "OpenClaw Enterprise - The Open Agent Platform", OpenClaw Blog, 29 September 2026. https://openclaw.ai/blog/openclaw-enterprise
86. OpenClaw Enterprise documentation, "OpenShell SandboxDriver", accessed 30 September 2026. https://docs-enterprise.openclaw.org/reference/drivers/openshell-sandbox/
87. OpenClaw Enterprise documentation, "Drivers overview", accessed 30 September 2026. https://docs-enterprise.openclaw.org/guides/integrations/drivers/
88. OpenClaw Enterprise documentation, "Sandbox", accessed 30 September 2026. https://docs-enterprise.openclaw.org/guides/topics/sandbox/
89. "feat(server): write gateway OCSF events to JSONL", pull request #3264, NVIDIA/OpenShell, GitHub, merged 29 September 2026. https://github.com/NVIDIA/OpenShell/pull/3264
90. "feat(providers): add Oracle Cloud Infrastructure Generative AI provider profile", pull request #3904, NVIDIA/OpenShell, GitHub, merged 29 September 2026. https://github.com/NVIDIA/OpenShell/pull/3904
91. "docs: add project maintainers", pull request #3166, NVIDIA/OpenShell, GitHub, merged 3 September 2026. https://github.com/NVIDIA/OpenShell/pull/3166
92. "docs: add project governance", pull request #3191, NVIDIA/OpenShell, GitHub, merged 4 September 2026. https://github.com/NVIDIA/OpenShell/pull/3191
93. GitHub comparison of NVIDIA/OpenShell main with Hugoch/OpenShell poc/egress-usage-monitoring, retrieved 30 September 2026. https://github.com/NVIDIA/OpenShell/compare/main...Hugoch:OpenShell:poc/egress-usage-monitoring
94. Piotr Mlocek (@pimlock), "RFC 0009 - Supervisor Middleware" (rfc/0009-supervisor-middleware/README.md), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. https://github.com/NVIDIA/OpenShell/blob/main/rfc/0009-supervisor-middleware/README.md