NVIDIA OpenShell and the case for agent controls outside the harness

Most of the controls teams rely on for coding agents live inside the agent: the model's own refusals, the harness's approval prompts, the instructions in a system prompt. On 28 September 2026 NVIDIA announced the Open Agent Safety Platform, whose central argument is that these are not enough on their own and that the enforceable boundary has to sit outside the model and the harness. The open-source part, OpenShell, is available now. This article looks at what it does, what is still a reference design, and which of its ideas are worth adopting whatever runtime you use.

What NVIDIA announced

The NVIDIA press release describes the platform as two pieces:

• OpenShell, open-source runtime software that sets boundaries for agents running on CPUs. NVIDIA says it is now broadly available and runs with minimal overhead on its Vera CPUs, and that as open source it can be extended to third-party compute platforms including those from Arm and Intel.
• Sentry, part of a reference system design. It is an out-of-band watchdog running on BlueField-4 data processing units that monitors agent behaviour from an isolated trust domain. NVIDIA says it can quarantine an agent that tries to move outside its software boundary in milliseconds; that is a vendor claim.

The release names more than 100 organisations working with the platform's technologies. It also carries the usual caution that many of the products and features described "will be offered on a when-and-if-available basis". OpenShell and related skills are available through NVIDIA's developer resources and GitHub; Sentry is a design that depends on specific hardware, not a download.

NVIDIA frames the motivation in one sentence: across recent incidents, "the agent circumvented security controls at the application layer to complete its assigned task".

How OpenShell 0.1.0 works

NVIDIA's technical blog post describes OpenShell 0.1.0 as a runtime that enforces which systems and data an agent can reach, without rewriting the agent. It supports Codex, Claude Code, Pi and Hermes. Three components do the work:

• Gateway manages the lifecycles and policies of many sandboxes.
• Supervisor is paired with each sandbox, runs outside the agent workload and checks outbound requests against policy.
• Sandbox runs the workload with kernel-level controls over files and processes, and no network path except through the supervisor.

Several details are worth noting.

Protocol-aware network rules. The supervisor can inspect configured HTTP, GraphQL and MCP traffic, so a policy can allow a read and block a write through the same API. The post's example lets curl read from a public REST API and blocks a POST to the same host. Policies are written in YAML and compiled to OPA/Rego.

Credentials stay outside. The agent sees a placeholder; the real credential is substituted outside the workload and only for approved endpoints. A read-only policy can block writes even if the credential itself allows them.

Changes need a human by default. With the policy advisor turned on, an agent that hits a block can propose a narrow network or file policy change. The proposal stays pending for human review by default, and the agent cannot approve its own request. Filesystem and process limits are fixed when the sandbox starts; changing them needs a new sandbox.

Policies can be checked formally. A policy prover checks what a policy actually grants, including access contributed by providers, and either proves it stays within a defined boundary or shows an action that crosses it. NVIDIA describes adversarial tests in which agents tried for up to two hours to persuade an AI reviewer to grant write access to a protected repository, with no protected writes occurring. Those are NVIDIA's own tests.

Auditing and deployment. Policy decisions are recorded in an Open Cybersecurity Schema Framework (OCSF) audit trail. Compute drivers cover Docker, Podman, MicroVM and Kubernetes.

How this lines up with public guidance

The design follows the direction of the UK NCSC's interim advice on managing the cyber risk of agentic AI, published on 20 August 2026. The NCSC warns that safety controls built into models may "be bypassed" and recommends additional safeguards where the consequences of failure are above tolerance. It suggests denying network traffic by default with allowlists, using protocol- or service-aware proxies, and using a proxy that injects credentials into requests so the agent never holds them. Its compute isolation scale runs from no isolation (level 1) through containers (level 2) and virtualisation (level 3) to dedicated hardware (level 4).

On that scale, OpenShell running on its container drivers would broadly correspond to level 2, and on its MicroVM driver to level 3; the NCSC does not assess OpenShell itself. Sentry's out-of-band approach aims further, but it is the reference design rather than the shipping software.

What it means for engineering and security leaders

The useful idea here is not one product. It is a layering principle: decide which controls must hold even if the model is persuaded and the harness is misconfigured, and put those outside both. Approval prompts in an agent are valuable, but an agent that can open a shell can also find other routes to the same action. A supervisor on the only network path cannot be bypassed in the same way.

Three practical questions follow for any runtime:

• Where do credentials live? If agents hold real long-lived tokens, any route out is a route to misuse. Credential substitution outside the workload is worth copying.
• Can the network policy see methods, not just hosts? Allowing a host often allows writes too. Method-level or tool-level rules close that gap.
• Who can widen a policy mid-task? If an agent can ask for more access, the request should wait for a person, and the agent should never approve itself.

OpenShell is at version 0.1.0. That is early for software that sits on the critical path of every agent request, so evaluate it in a contained environment first and read its migration notes and support matrix before relying on it. For a broader comparison of agent sandboxes, see sandboxing coding agents, and for the policy background, what NIST is saying about AI agent security.

Practical takeaways

• List the controls that currently live only in the model or the harness, and decide which must also be enforced outside them.
• Route agent network traffic through a single, policy-checking path, and deny everything else by default.
• Keep real credentials out of agent workloads; inject them per request for approved endpoints only.
• Prefer rules that distinguish reads from writes over host-level allowlists.
• Require human approval for any policy change an agent requests, and log the decision.
• Treat OpenShell 0.1.0 as early software and Sentry as a reference design, not a product you can deploy today.