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 the credentials it uses may be 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. 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, alongside the NVIDIA Sentry reference design for 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]

The problem it addresses

NVIDIA's launch post argued that a stateless chatbot has no meaningful attack surface, while an 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 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, 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, a bundle that LangChain's launch announcement described as including Nemotron models, NVIDIA NeMo Agent Toolkit profiling and optimization, NIM microservices and 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 below.

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

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 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]

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 and 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]

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 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; 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 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 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, 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 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, opencode, OpenAI Codex and GitHub Copilot CLI were preinstalled in the community base image, alongside community sandboxes for Ollama and Pi.^[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 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 (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, was donated to the foundation and was developed further with 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

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. 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.^[38][63] 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, 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:

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, a separate NVIDIA-initiated group of more than 120 organizations that NVIDIA's release describes as governed by the Linux Foundation.^[36]

On 13 October 2026 NVIDIA announced a five-year compute donation valued at $250 million, or $50 million in compute access a year, for agentic safety and security research in the United Kingdom. Most of it is to support the wider UK AI safety and security research community, with a proportion going to work with the British Open-Ended Learning and Discovery Lab (BOLD, led by the University of Oxford), the Science of Fundamental AI Research Lab (SOFAIR, led by UCL) and Imperial College London. Access is to be delivered through UK-based NVIDIA Cloud Partners, with provider selection, technical architecture and commercial terms still to be agreed. NVIDIA said the research programs would cover secure agents, open-model security and real-world threat mitigations, including research conducted using OpenShell and the NVIDIA Sentry reference design.^[98]

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 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 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, with 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] 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]

OpenWorker, the open-source desktop agent announced by Andrew Ng, merged an optional OpenShell sandbox provider into its main branch on 24 September 2026. The provider is pinned to OpenShell 0.0.116 rather than the 0.1 series, and as of 30 September it had not shipped in a tagged OpenWorker release, the latest being v0.2.1 from August.^[95][96][97]

While red-teaming its own SPACE sandbox, Perplexity's Secure Intelligence Institute also tested the network-policy enforcement of ten third-party sandbox platforms, including OpenShell, against HTTP and HTTPS techniques in which an allowlisted hostname on shared CDN or cloud infrastructure is used to reach an unlisted one. In its report "Escaping SPACE: Part I" (23 September 2026), which published results for nine of the ten, neither bypass succeeded against OpenShell or Cloudflare Sandbox, while the other seven showed at least one. The tests ran directly against the product versions and configurations available on 31 August and 1 September 2026, without LLM agents.^[99]

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:

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 chief executive Clément 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]

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), 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 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
• NVIDIA NemoClaw
• NVIDIA BlueField
• Open Secure AI Alliance
• OpenClaw
• Hermes Agent
• Prompt injection
• Guardrails (AI)
• Agent skills
• AI safety
• NVIDIA NeMo Agent Toolkit
• OpenClaw Enterprise
• OpenAI-Hugging Face agent incident

References

1. ^1 ^2 ^3 ^4 ^5 ^6 ^7NVIDIA, "OpenShell: the safe, private runtime for autonomous AI agents" (README and repository metadata), GitHub, accessed 31 July 2026. github.com/...OpenShell
2. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12Ali 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, 3 March 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. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9NVIDIA, "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. github.com/...security-policy.md
6. ^1 ^2 ^3 ^4 ^5 ^6 ^7NVIDIA, "Sandbox" (architecture/sandbox.md at commit c42268b, 31 July 2026; the architecture directory was removed from main on 29 September 2026), NVIDIA/OpenShell, GitHub. github.com/...sandbox.md
7. ^1 ^2 ^3 ^4 ^5NVIDIA, "Customize Sandbox Policies", NVIDIA OpenShell documentation, accessed 31 July 2026 (page retired in the 0.1 documentation restructure). docs.nvidia.com/...policies
8. ^1 ^2NVIDIA, "Inference Routing", NVIDIA OpenShell documentation, accessed 31 July 2026 (page retired in the 0.1 documentation restructure). docs.nvidia.com/...inference-routing
9. ^NVIDIA, "Support Matrix", NVIDIA OpenShell documentation, accessed 31 July 2026 (moved in the 0.1 documentation restructure). docs.nvidia.com/...support-matrix
10. ^1 ^2NVIDIA, "Compute Runtimes" (architecture/compute-runtimes.md at commit c42268b, 31 July 2026), NVIDIA/OpenShell, GitHub. github.com/...compute-runtimes.md
11. ^1 ^2NVIDIA, "sandboxes/base/policy.yaml", NVIDIA/OpenShell-Community, GitHub, accessed 31 July 2026. github.com/...policy.yaml
12. ^1 ^2 ^3NVIDIA, "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. github.com/...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. github.com/...README.md
14. ^1 ^2Ali 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. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8Darryl 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, accessed 28 September 2026 (last updated 17 September 2026). perspectives.nvidia.com/nvidia-openshell
18. ^NVIDIA, "NemoClaw" (README), GitHub, accessed 31 July 2026 and 28 September 2026. github.com/...NemoClaw
19. ^1 ^2 ^3NVIDIA, "NVIDIA and ServiceNow Partner on New Autonomous AI Agents for Enterprises", NVIDIA Blog, 5 May 2026. blogs.nvidia.com/...tonomous-ai-agents-enterprises
20. ^1 ^2 ^3LangChain, "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. ^1 ^2"feat: Support restricted SecurityContextConstraints for managed Kubernetes platforms", issue #899, NVIDIA/OpenShell, GitHub, opened 20 April 2026, closed 15 August 2026. github.com/...899
23. ^1 ^2 ^3"Proposal: Split Supervisor and Agent into Separate Pods with gVisor Isolation", issue #981, NVIDIA/OpenShell, GitHub, opened 26 April 2026, closed 21 September 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), GitHub, accessed 28 September 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 28 September 2026. gvisor.dev/docs
29. ^Firecracker project, "Secure and fast microVMs for serverless computing", accessed 28 September 2026. firecracker-microvm.github.io
30. ^Modal, "Sandboxes", Modal documentation, accessed 28 September 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 28 September 2026. daytona.io
33. ^1 ^2NVIDIA, "Ali Golshan" (author profile), NVIDIA Technical Blog, accessed 28 September 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
35. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12Alex Watson and Ali Golshan, "Add Runtime Controls to AI Agents with NVIDIA OpenShell", NVIDIA Technical Blog, 28 September 2026. developer.nvidia.com/...ents-with-nvidia-openshell
36. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13 ^14 ^15 ^16 ^17 ^18NVIDIA, "NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment", NVIDIA Newsroom, 28 September 2026. nvidianews.nvidia.com/...open-agent-safety-platform
37. ^1 ^2 ^3John 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. developer.nvidia.com/...n-silicon-agent-monitoring
38. ^1 ^2Kif Leswing, "Nvidia releases software platform to stop AI agents from misbehaving", CNBC, 28 September 2026. cnbc.com/...nvidia-releases
39. ^1 ^2NVIDIA, "OpenShell v0.1.0" (release notes), NVIDIA/OpenShell, GitHub, 25 September 2026. github.com/...v0.1.0
40. ^1 ^2 ^3 ^4 ^5 ^6NVIDIA, "Upgrade to NVIDIA OpenShell 0.1.0", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...0-1-0
41. ^1 ^2 ^3 ^4 ^5 ^6NVIDIA, "Architecture", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...architecture
42. ^1 ^2 ^3NVIDIA, "Support Matrix", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...support-matrix
43. ^1 ^2NVIDIA, "Inference", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...inference
44. ^1 ^2NVIDIA, "Policy Prover", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...prover
45. ^NVIDIA, "OpenShift", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...openshift
46. ^NVIDIA, "High Availability", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...high-availability
47. ^1 ^2 ^3 ^4NVIDIA, OpenShell README and repository metadata, NVIDIA/OpenShell, GitHub, accessed 28 September 2026. github.com/...README.md
48. ^1 ^2 ^3 ^4NVIDIA, OpenShell README at commit c42268b (31 July 2026), NVIDIA/OpenShell, GitHub. github.com/...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. developer.nvidia.com/...-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. developer.nvidia.com/...-from-microsoft-and-nvidia
51. ^1 ^2NVIDIA, "Sandbox Runtimes", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...runtimes
52. ^"feat(kubernetes): support HA gateway rebalancing", pull request #1868, NVIDIA/OpenShell, GitHub, merged 21 September 2026. github.com/...1868
53. ^1 ^2"feat(isolation): implement the RFC 0012 sandbox architecture", pull request #2942, NVIDIA/OpenShell, GitHub, merged 16 September 2026. github.com/...2942
54. ^Russell Bryant (russellb), GitHub profile, accessed 28 September 2026. github.com/russellb
55. ^OWASP GenAI Security Project, "LLM01:2025 Prompt Injection", accessed 28 September 2026. genai.owasp.org/...llm01-prompt-injection
56. ^E2B, "Sandbox lifecycle", E2B Docs, accessed 28 September 2026. e2b.dev/...sandbox
57. ^Daytona, "daytonaio/daytona" (README), GitHub, accessed 28 September 2026. github.com/...daytona
58. ^Cursor Team, "Cursor is now a part of SpaceX", Cursor blog, 14 August 2026. cursor.com/...joining-spacex
59. ^NVIDIA, "Default Policy Reference" (docs/reference/default-policy.mdx at commit c42268b, 31 July 2026), NVIDIA/OpenShell, GitHub. github.com/...default-policy.mdx
60. ^NVIDIA, "OpenShell v0.1.2" (release notes), NVIDIA/OpenShell, GitHub, 28 September 2026. github.com/...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. github.com/...1329
62. ^"feat(prover): add native Rust policy prover with Z3 solver", pull request #741, NVIDIA/OpenShell, GitHub, merged 9 April 2026. github.com/...741
63. ^1 ^2 ^3 ^4Frederic Lardinois, "Nvidia launches Open Agent Safety Platform to lock down rogue AI agents", The New Stack, 28 September 2026. thenewstack.io/nvidia-openshell-sentry-agents
64. ^NVIDIA, "Installation", NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...installation
65. ^NVIDIA, "Extensibility" (overview), NVIDIA OpenShell documentation, accessed 28 September 2026. docs.nvidia.com/...overview
66. ^1 ^2NVIDIA, "Sandbox" (architecture/sandbox.md at commit a6eefcf, 29 September 2026, the last version before the architecture directory was removed), NVIDIA/OpenShell, GitHub. github.com/...sandbox.md
67. ^"docs: remove the architecture directory", pull request #3799, NVIDIA/OpenShell, GitHub, merged 29 September 2026. github.com/...3799
68. ^1 ^2GitHub REST API, repository metadata and contributor count for NVIDIA/OpenShell, retrieved 30 September 2026 03:03 UTC. api.github.com/...OpenShell
69. ^1 ^2NVIDIA, "Releases", NVIDIA/OpenShell, GitHub, accessed 30 September 2026. github.com/...releases
70. ^"rfc-0012: Isolation Backend interface", pull request #2048, NVIDIA/OpenShell, GitHub, merged 10 September 2026. github.com/...2048
71. ^1 ^2NVIDIA, "OpenShell RFCs" (rfc/README.md), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. github.com/...README.md
72. ^1 ^2NVIDIA, rfc directory (RFC 0000 to 0014 folders and their front matter), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. github.com/...rfc
73. ^1 ^2 ^3NVIDIA, "Maintainers" (MAINTAINERS.md), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. github.com/...MAINTAINERS.md
74. ^1 ^2NVIDIA, "OpenShell Project Governance" (GOVERNANCE.md), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. github.com/...GOVERNANCE.md
75. ^1 ^2 ^3"[Sandbox] OpenShell", issue #522, cncf/sandbox, GitHub, opened 8 September 2026; TOC vote closed 26 September 2026. github.com/...522
76. ^1 ^2 ^3Clement Delangue (@ClementDelangue), "From what we know (take with a grain of salt, we need much more transparency!)...", X, 28 September 2026. x.com/...2104597818606338298
77. ^1 ^2 ^3 ^4 ^5 ^6 ^7Hugo Larcher (@Hugoch), "RFC NNNN - Egress Usage Monitoring" (draft), branch poc/egress-usage-monitoring, Hugoch/OpenShell, GitHub, 28 September 2026. github.com/...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. github.com/...poc.md
79. ^Hugo Larcher, "feat(egress-usage): add egress usage monitoring" (commit 1be0fba), Hugoch/OpenShell, GitHub, 28 September 2026. github.com/...fbaee670f60c1b9dc01e6c224aeb8fc0b475
80. ^1 ^2Hugo Larcher (Hugoch), GitHub profile, accessed 30 September 2026. github.com/Hugoch
81. ^NVIDIA, "Sandbox Limits" (architecture/sandbox-limits.md at commit a6eefcf, 29 September 2026), NVIDIA/OpenShell, GitHub. github.com/...sandbox-limits.md
82. ^GitHub issue and pull request search, NVIDIA/OpenShell, author:Hugoch, retrieved 30 September 2026. github.com/...issues
83. ^1 ^2 ^3Julie Bort, "Here's why OpenAI is absent from Nvidia's industry-wide effort to end rogue AI agents", TechCrunch, 29 September 2026. techcrunch.com/...de-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). x.com/...2105090691806474350
85. ^Kevin Lin, "OpenClaw Enterprise - The Open Agent Platform", OpenClaw Blog, 29 September 2026. openclaw.ai/...openclaw-enterprise
86. ^1 ^2OpenClaw Enterprise documentation, "OpenShell SandboxDriver", accessed 30 September 2026. docs-enterprise.openclaw.org/...openshell-sandbox
87. ^1 ^2OpenClaw Enterprise documentation, "Drivers overview", accessed 30 September 2026. docs-enterprise.openclaw.org/...drivers
88. ^OpenClaw Enterprise documentation, "Sandbox", accessed 30 September 2026. docs-enterprise.openclaw.org/...sandbox
89. ^"feat(server): write gateway OCSF events to JSONL", pull request #3264, NVIDIA/OpenShell, GitHub, merged 29 September 2026. github.com/...3264
90. ^"feat(providers): add Oracle Cloud Infrastructure Generative AI provider profile", pull request #3904, NVIDIA/OpenShell, GitHub, merged 29 September 2026. github.com/...3904
91. ^"docs: add project maintainers", pull request #3166, NVIDIA/OpenShell, GitHub, merged 3 September 2026. github.com/...3166
92. ^"docs: add project governance", pull request #3191, NVIDIA/OpenShell, GitHub, merged 4 September 2026. github.com/...3191
93. ^1 ^2GitHub comparison of NVIDIA/OpenShell main with Hugoch/OpenShell poc/egress-usage-monitoring, retrieved 30 September 2026. github.com/...egress-usage-monitoring
94. ^1 ^2Piotr Mlocek (@pimlock), "RFC 0009 - Supervisor Middleware" (rfc/0009-supervisor-middleware/README.md), NVIDIA/OpenShell, GitHub, accessed 30 September 2026. github.com/...README.md
95. ^Devika Verma, "Add support for Sandboxing using NVIDIA OpenShell", OpenWorker pull request #684, andrewyng/openworker, GitHub, merged 24 September 2026. github.com/...684
96. ^OpenWorker, OpenShell sandbox provider source (coworker/sandbox/providers/openshell.py, PINNED_VERSION "0.0.116"), andrewyng/openworker, GitHub, main branch, accessed 30 September 2026. github.com/...openshell.py
97. ^OpenWorker, "Releases", andrewyng/openworker, GitHub, accessed 30 September 2026. github.com/...releases
98. ^NVIDIA, "NVIDIA Commits $250 Million to Advance UK Agentic Safety and Security Research Over the Next Five Years", NVIDIA Newsroom, 13 October 2026. nvidianews.nvidia.com/...-over-the-next-five-years
99. ^Perplexity Secure Intelligence Institute, "Escaping SPACE: Part I", Perplexity, 23 September 2026. perplexity.ai/...escaping-space-part-i