English 
NVIDIA OpenShell needs a 6.2 kernel, not NVIDIA silicon
On September 28, 2026, NVIDIA announced the Open Agent Safety Platform. The press release describes two halves. NVIDIA OpenShell is “open source software”, a runtime that “sets boundaries for agents running on CPUs”; the release calls it “Now broadly available”.
NVIDIA Sentry is a “reference system design”: an “out-of-band watchdog that runs on NVIDIA BlueField-4 DPUs” and “can quarantine agents that attempt to move outside their boundaries in milliseconds”. The company counts “over 100 organizations” working with the platform’s technologies.
The release’s summary names eighteen of them, from Anthropic and Microsoft to SAP and SpaceXAI.
This piece separates the software from the hardware design and puts the NVIDIA OpenShell release history next to the announcement. It then runs version 0.1.4 on an Intel desktop with no Vera CPU and no BlueField DPU, and sets it beside the agent-permission format Docker took to the CNCF four days earlier.
Advertisements
OpenShell is the half you can download, and it is more than seven months old
The OpenShell repository on GitHub is Apache 2.0, written in Rust, and dates from February 24, 2026. NVIDIA announced it on March 23, 2026, in a blog post that called it “in early preview” and “Part of NVIDIA Agent Toolkit”, and described it as the “browser tab” model for agents.
Between the first entry on the releases page, v0.0.6 on March 16, and v0.1.4 on October 13, the project’s releases page gained 101 entries, two of them marked as prereleases. Of those entries, 98 came before the announcement day. Version 0.1.0 came out on September 25, three days before the announcement.
Version 0.1.2 landed at 03:58 UTC on September 28, the announcement day. The figure shows the sequence.
What changed with 0.1 is the release model. The v0.1.0 notes list a change that reads “remove daily minor release automatic workflow”. The support matrix now says “Tagged stable releases generally go out every week”, with Tuesday as the target, and that fixes go to the latest minor and the one before it. The jump also broke compatibility: the upgrade guide says “Local OpenShell 0.0.x installations cannot be upgraded in place” and that 0.1.0 “introduces breaking changes for deployments, sandboxes, policies, APIs, and SDKs”. You have to recreate every 0.0.x sandbox.
Advertisements
The same-day engineering post on NVIDIA’s technical blog is about “NVIDIA OpenShell 0.1.0”, and places it as “the runtime layer of the broader NVIDIA Open Agent Safety Platform”.
What NVIDIA OpenShell does, by its own docs
The architecture page describes three parts. A gateway is “the control plane” that “manages the lifecycle of sandboxes”. Each sandbox gets a supervisor on the trusted side of the boundary, and “The supervisor is trusted and makes the decisions. The sandbox shares the boundary with the untrusted agent, so it never makes policy decisions.”
Inside the boundary, “the workload uses one non-root identity and no Linux capabilities. Landlock limits filesystem access; seccomp user notification stages network operations.” The workload container has networking turned off; every TCP connection and DNS lookup is handed to the supervisor, which checks it against policy and, if allowed, opens the real connection itself. If the supervisor disconnects, “the sandbox freezes the agent”.
Advertisements
Policies are YAML files that, per the engineering post, are “compiled to OPA/Rego”. The post’s example grants one binary read access to one API:
YAML
network_policies:
github_api:
name: github-api-readonly
endpoints:
- host: api.github.com
port: 443
protocol: rest
enforcement: enforce
access: read-only
binaries:
- path: /usr/bin/curlWith protocol: rest, the supervisor inspects the HTTP requests, “allowing reads while blocking writes”; the post says the same inspection covers GraphQL and Model Context Protocol traffic, and that decisions go to an OCSF audit trail. Credentials never enter the sandbox: the agent sees a placeholder, and the supervisor substitutes the real credential only on requests to the endpoints a provider profile allows.
A policy advisor and a prover sit in the gateway
Two more pieces sit in the gateway. A policy advisor turns an agent’s denied requests into a proposed rule, which “remains pending for human review by default, and the agent cannot approve its own request”. A policy prover “uses formal logic to check the permissions granted by the policy” before anyone approves a change. NVIDIA reports adversarial runs in which “frontier agents with reduced safeguards spent up to two hours trying to persuade an AI reviewer to grant permissions”, and says “no protected repository writes occurred in these tests”.
Advertisements
NVIDIA positions the runtime under existing coding agents rather than replace them. The OpenShell product page lists “Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw, OpenCode, and others”, and answers its own question, “Is OpenShell an agent framework?”, with “No. OpenShell is not another agent framework.” Anthropic’s post of the same day says OpenShell can be “the runtime for that sandbox”, the self-hosted sandbox of Claude Managed Agents, and that it “blocks everything unless a rule allows it”.
Sentry is a reference design for BlueField-4, and Vera is a claim
The press release ties the software to two NVIDIA chips. OpenShell “delivers this protection with minimal overhead on NVIDIA Vera, the first purpose-built CPU for agentic AI”. Sentry runs “on NVIDIA BlueField-4 DPUs”, is built on NVIDIA’s DOCA software, and provides “in-silicon security enforcement”.
The second technical post of the day places it: “In an NVIDIA Vera Rubin POD, each compute tray includes a BlueField-4 data processing unit on the node’s only path to the model.” Sentry is “an optional security layer alongside OpenShell”, and “For anyone already running on an NVIDIA Vera system with BlueField-4, enabling these protections is just a software update.” The post gives no download, version or price for Sentry, and neither does the press release; the word both use is “reference”.
Advertisements
The platform page settles the dependency question in its FAQ: “Does OpenShell require BlueField-4?” “No. OpenShell can run on supported local, on-premises, cloud, and Kubernetes infrastructure without BlueField-4.” The same page carries the Vera number: “Vera achieves up to 80% faster sandbox performance than traditional CPU infrastructure”. NVIDIA says it; the page cites no measurement.
The two other CPU vendors in the release speak for themselves. Arm’s post says “NVIDIA OpenShell brings secure agent execution to this broad Arm CPU ecosystem”, a list on which it puts Graviton, Axion, Cobalt and Vera. It describes BlueField-4 as “powered by NVIDIA Grace with 64 Arm Neoverse V2 cores”. Intel’s post says OpenShell is “now available as an optional component” of the Intel AI for Enterprise Agent Toolkit, “off by default”, creating its sandboxes “through the Kubernetes Agent Sandbox API” on the toolkit’s existing controller.
We ran OpenShell 0.1.4 on an Intel desktop: the gate is the kernel, not the CPU
To find out where that gate sits, we ran OpenShell 0.1.4 on the desktop this news section is written on. It has an Intel Core i5-13600KF and a GeForce GPU, and runs Ubuntu 24.04 under WSL 2 with Docker Desktop, the one host the support matrix lists as “Experimental”. It has no Vera CPU and no BlueField DPU, and the sandbox asked for no GPU.
Advertisements
We installed nothing system-wide. The CLI and the gateway came from the release assets on GitHub, with their SHA-256 checked against the release’s checksum files, and ran from a temporary directory with the Docker driver and telemetry off. The gateway read this file:
Output
[openshell]
version = 2
[openshell.gateway]
compute_driver = "docker"
disable_tls = true
[openshell.gateway.auth]
# local single-user escape hatch, per the gateway configuration docs
allow_unauthenticated_users = trueThe last setting is there for a reason. Once openshell-gateway generate-certs had written its signing bundle, the gateway refused the CLI with “missing authorization header”. The configuration docs call the option “an unsafe local-development and trusted-proxy escape hatch”. The packaged installer, which we did not use, starts the gateway over TLS on its own. After openshell gateway add, one command:
Terminal (bash)
openshell sandbox create --name demo --no-auto-providers -- /bin/trueThe workload died in the second it started
The gateway started, pulled the default sandbox image, and created the two containers of a sandbox, workload and supervisor, on an x86-64 machine with no NVIDIA CPU or DPU. The workload exited within the same second. The CLI reported:
Advertisements
Output
Error: × sandbox entered error phase while provisioning:
│ ControlSupervisorStartFailed: Docker sandbox exited before supervisor
│ became readyThat message names the symptom. The cause was in the workload container’s log, which the Docker driver deletes along with the container moments later; we attached docker logs -f to the container the instant it appeared to catch it:
Output
Error: × Landlock ABI probe
╰─▶ Landlock ABI v3 or newer (Linux 6.2+) is required, but Landlock is
available (ABI v1)The machine’s kernel is 5.15.167.4, the one WSL 2.4.11 ships, and a probe of landlock_create_ruleset from Python on that kernel returns ABI version 1. The v0.1.4 release notes include the change that produced the readable message, “name Landlock ABI in startup error”. Tested with: OpenShell 0.1.4 (CLI and gateway from the v0.1.4 release assets), Docker Desktop with Engine 29.7.2, Ubuntu 24.04.2 under WSL 2.4.11 with kernel 5.15.167.4, Intel Core i5-13600KF, on October 15, 2026, UTC. Not tested: any kernel at 6.2 or newer, including the 6.6 and 6.18 kernels of newer WSL releases; Docker Desktop’s host-networking setting; the Podman, MicroVM and Kubernetes drivers.
The support matrix lists the kernel facilities, and 6.2 is the floor
The support matrix says as much up front. Its kernel requirements are the part of the page to read before the quickstart:
Advertisements
| Kernel facility | What OpenShell requires, per the support matrix |
|---|---|
| Landlock LSM | “ABI 3 or newer, introduced in Linux 6.2, with Landlock enabled” |
| seccomp | “Nested user-notification filters and atomic SECCOMP_IOCTL_NOTIF_ADDFD with SECCOMP_ADDFD_FLAG_SEND” |
| Task-memory access | the broker “must be able to read a same-UID, dumpable workload child’s memory through process_vm_readv or /proc/<pid>/mem” |
| Socket device binding | every workload socket bound to loopback “with SO_BINDTODEVICE, without added capabilities” |
The page adds that “A kernel version alone does not establish support. A disabled Landlock LSM or a runtime profile that blocks the required seccomp operations causes launch to fail closed”, and that on macOS “these kernel modules run inside the Docker Desktop Linux VM, not on the host kernel”.
Landlock itself, by the kernel documentation, “was first introduced in Linux 5.13”; the ABI version is what the sandbox probes.
The supervisor logged a second gap
The supervisor container’s own log carried three lines of “log push connect failed: failed to connect to OpenShell server”. The runtimes page says “Docker Desktop must have host networking enabled”, and a reader who clears the kernel gate may meet that one next.
Advertisements
For WSL 2 the fix is a newer WSL, not a CPU
Microsoft has shipped a 6.6 kernel in stable WSL releases at least since 2.5.7 of April 24, 2025 (“Update Linux kernel to 6.6.87.1-1”). A 6.18 kernel has shipped since 2.7.8 of June 6, 2026 (“Update kernel to 6.18.33.1-1”). The current 3.0.3 of October 9 carries 6.18.54.1, whose x86 config sets CONFIG_SECURITY_LANDLOCK=y. The 5.15 kernel on this machine is the one WSL 2.4.11 ships, older than all of those. By the number in OpenShell’s error, any of them clears “Linux 6.2+”; whether the sandbox then starts is on the untested list above.
OpenShell and Docker’s Sandbox Kit Spec are not the same layer
Four days before NVIDIA’s announcement, on September 24, 2026, Docker announced that its Sandbox Kit Spec was “open source under Apache 2.0” and that it was “bringing the spec to CNCF”. A Kit “carries three things in one image: the agent, its tools, and a typed list of everything it asks to reach, such as hosts, credentials, and volumes”. | | NVIDIA OpenShell, per its docs | Docker Sandbox Kit Spec, per its README and blog |
| — | — | — |
|---|---|---|
| Where the rules live | YAML policy files, “compiled to OPA/Rego”, applied by the supervisor | inside the image, under the same digest as the content |
| Who enforces | OpenShell itself, through Landlock, seccomp and the supervisor | a conforming runtime; “Docker Sandboxes is the first runtime that enforces it” |
| Governance | NVIDIA’s repository; discussion on CNCF Slack | brought to the CNCF; a final version “targeted for” “Q4 2026” |
| Status | 0.1.4, weekly stable releases, Apache 2.0 | “experimental”, Apache 2.0; repository created September 16, 2026 |
| Mentions the other | no | no |
The two could compose, and nobody says they will
The last row is from a search of both repositories’ trees, cloned on October 15. No file in OpenShell’s tree contains “sandbox kit” in any spelling; no file in the spec’s tree contains “openshell” or “nvidia”. GitHub’s code search gave the same zero for four queries. By our reading, a Kit says what an agent asks for, and the spec’s README states that “The grammar declares; runtimes behave”. Its conformance suite is open to other runtimes: “A runtime is tested through an adapter: an executable implementing seven verbs”. Neither project’s README says anyone is building that adapter. Docker’s blog post makes the case for the split in its own words: “A standard for deciding what an agent may do is worth a good deal less if it belongs to whoever sells you the runtime.”
Advertisements
What changes for you
What follows is our reading, not NVIDIA’s.
If you run agents on a Linux machine, the docs put OpenShell within reach without NVIDIA hardware. The FAQ’s answer is that it “can run on supported local, on-premises, cloud, and Kubernetes infrastructure without BlueField-4”. The floor is “Docker Desktop or Docker Engine 28.0” or “Linux with Podman 5.x, cgroups v2, and an active Podman user socket”, on a kernel that passes the probes above. The installer puts a .deb, .rpm or snap on Linux and a Homebrew formula on macOS, and starts the gateway as a user service on port 17670. The default sandbox image is “minimal Ubuntu with no agent installed”; the first-agent tutorial runs OpenCode against a free OpenRouter model.
If you are on WSL 2 with the 5.15 kernel, the sandbox fails closed the way ours did, and the message to look for is in the workload container’s log, not in the CLI’s. Updating WSL is the path, and it has been open since the spring of 2025. OpenShell’s documentation mentions WSL on three pages. They are the “Experimental” row of the support matrix, a GPU fallback note for “WSL2 all-only runtimes”, and /usr/lib/wsl as a read-only path in the default policy. None of the three names a kernel version or a WSL version.
The performance question has no answer yet
On Hacker News, a reader of OpenShell’s formal-methods write-up in September asked “What are the performance implications?”. The thread we read on October 15 has no reply, and the only number NVIDIA gives, Vera’s “up to 80% faster”, is the vendor’s.
Advertisements
Sentry has no date for becoming more than a reference. The “Windows MXC” runtime that the runtimes page marks “Coming soon” already has a configuration section. It says the driver “runs Windows workloads through wxc-exec“; what that means for the one host marked “Experimental” is the open question for Windows users. Whether OpenShell ever reads the Kits Docker is standardizing, whose final version is “targeted for” “Q4 2026”, has no answer in either repository. For a reader with a machine in front of them, the first question is the one the sandbox asks: which Landlock ABI the kernel reports.
Related posts:
A New DeepSeek Paper Highlights the Growing Push for More Efficient AI Training
GPT-6.1 Sol: what changed from GPT-6 Sol and what a task costs
Gemini 4 Argon: announced at $2 and $10, not in the API yet
Meta Enterprise Platform: who runs it and what you can use today
Linux kernel AGENTS.md patch is still unmerged after 22 messages
curl 8.23.0 fixes 24 CVEs, 20 of them found with AI tooling
