What NVIDIA announced
On October 21, 2026, at its GTC Berlin developer conference, NVIDIA launched the NVIDIA OpenShell Reference Architecture for running AI agents safely. It pairs the open-source OpenShell runtime, which runs an agent inside a controlled sandbox, with NVIDIA hardware, including optional BlueField data processing units (DPUs) running a security framework called NVIDIA Sentry. (NVIDIA Sentry is not Sentry.io, the error-monitoring service.)
NVIDIA's technical walkthrough describes four OpenShell components:
- Gateway: the control plane that manages sandbox lifecycles and policies.
- Sandbox: isolates the agent workload and restricts filesystem and process access.
- Supervisor: runs separately from the sandbox, checks outbound requests against policy and mediates access to credentials.
- Policy prover: formally checks whether a policy's permissions stay inside a boundary policy the organization defines.
The walkthrough calls the hardware layer an optional safeguard for deployments that need more protection. NVIDIA Sentry runs on BlueField-4 and routes agent traffic through a network proxy that takes its allow-or-deny decisions from Open Policy Agent (OPA), an open-source engine that evaluates requests against written rules. NVIDIA plans to make Sentry available in early 2027.
The press release names organizations including Anthropic, IBM, Microsoft, OpenAI and Siemens as working with the architecture. That is NVIDIA's list of collaborators, not evidence of production adoption.
The walkthrough positions OpenShell as governance placed outside the agent's reach. On October 15, NVIDIA chief technology officer (CTO) Michael Kagan told AI Magazine that slowing AI down is the wrong response: "You need to accelerate AI development to make it safe." He described OpenShell as a sandbox where you specify what is and is not allowed. Take the speed argument at face value and it carries a requirement: if agents ship changes faster, the checks on those changes have to run as often as the changes do.
What OpenShell policy governs
OpenShell's sandbox policy is a YAML document (version: 1) with five optional sections. The descriptions below are from the v0.1.5 documentation, the default version on October 22, 2026:
| Section | Controls | When it applies |
|---|---|---|
filesystem_policy | Readable and writable paths, enforced by Landlock (a Linux kernel access-control module) | Fixed at sandbox start |
landlock | Whether the sandbox still starts if the filesystem rules cannot be applied | Fixed at sandbox start |
process | The user and group that sandbox processes run as | Fixed at sandbox creation |
network_policies | Which destinations each program in the sandbox can reach, and which requests it can send | Updatable while the sandbox runs |
network_middlewares | Inspection, transformation or blocking of traffic the network rules allow | Updatable while the sandbox runs |
Egress is default-deny: the sandbox cannot open an outbound connection unless a network rule allows it. Network rules can also be finer than a host name: for representational state transfer (REST) endpoints they can allow or deny a specific method on a specific path, such as blocking deletes on one path while allowing reads.
Providers are connections to outside services, such as GitHub, that you attach to a sandbox with their credentials. Each can add the network rules its service needs, so the policy a sandbox enforces (its effective policy) is the base policy plus provider rules.
Which policy applies is its own question. In v0.1.5, a gateway administrator can set a global policy that replaces every sandbox's own policy while it is active, rather than capping it. Without one, OpenShell uses the sandbox's saved policy, then a policy in the sandbox image, then a restrictive default. To see what a sandbox enforces, compare openshell policy get <sandbox> --base with --full, which adds provider rules. While a global policy is active, both show the global policy.
What the prover proves
The policy prover uses a satisfiability modulo theories (SMT) solver to check that a candidate policy allows nothing beyond a boundary policy. In v0.1.5 it models five things: filesystem read and write paths, process identity, the Landlock compatibility setting, which programs can reach which hosts and ports, and REST method and path rules. Anything outside that model, such as GraphQL or Model Context Protocol (MCP) rules, comes back as unsupported rather than passing.
NVIDIA's documentation is careful about the limits. A pass does not mean the policy is as narrow as it could be, that it is safe for a particular task, or that a running sandbox enforces it.
That is rigorous work on a well-defined question: can this workload reach more than we allowed? It is a different question from does this change respect what we decided?
The gap: an allowed write that breaks a decision
Take a sandbox whose filesystem policy lets the agent write under src/handlers/. The team has an architectural decision: request handlers reach the database only through the approved storage adapter, never through a database driver directly.
The agent adds a handler that imports the driver and opens its own connection. Every OpenShell control passes. The path is writable, the process identity is correct, and no network rule is involved because nothing has run yet. The violation lives in the content of the change, and OpenShell's documented policy model does not look at the content of files.
A second example sits closer to OpenShell's strengths. An agent has network access to an internal deployment API so it can roll out services. It sends a request that allocates compute the team never approved. Here OpenShell has real options:
- A REST rule in
network_policiescan deny the allocation endpoint's path and method outright, and the prover can check that rule. - Supervisor middleware can inspect the body of an allowed request and deny one that asks for more than the approved amount.
Both work only for the request shapes someone wrote rules for. If the agent instead edits an infrastructure manifest in the repository that requests the same compute, the action is a file write, and the allocation happens later in a pipeline outside the sandbox. No network rule fires. The decision ("no new compute allocation without approval") is the same in both cases; only one path crosses the boundary OpenShell watches.
OpenShell is doing its job in both cases. Access policy says what a workload may touch. An architectural decision says what a change must respect. An earlier piece argues that runtime and architectural governance answer different questions, and OpenShell gives that split a documented example. NVIDIA's prover documentation states the limit on its side: a passing policy is not necessarily safe for a particular task.
Where the two could meet
OpenShell's extension points are the places where decision-aware checks could attach. Each has a specific reach:
- Gateway interceptors are external services the gateway calls on selected changes to OpenShell itself, such as creating a sandbox or changing its configuration. Only operations on an explicit allowlist can be intercepted. Before a change is committed, an interceptor can rewrite or reject it; afterwards it can only record it. Interceptors never see the agent's file writes.
- Supervisor middleware inspects, transforms or denies HTTP and WebSocket traffic that the access policy already allowed.
- Open Cybersecurity Schema Framework (OCSF) events: OpenShell maps sandbox events to OCSF v1.8.0 classes and can write them as JSON records for a security information and event management (SIEM) system.
None of these is a universal seam for file writes. A decision about code content still needs a check where the code change happens: the agent's own write path, and continuous integration (CI). Mneme, the open-source tool made by the team that publishes this site, runs at those two points. Checks there run on each supported agent write and on every pull request, so they keep pace with the agent instead of a review queue.
What platform teams should do
- Keep two artifacts with two owners. Access policy belongs to the platform and security teams. Architectural decisions belong to the engineers who own the system. Do not encode one as the other.
- Map each decision to the boundary that enforces it. For every decision you care about, write down whether a sandbox rule, middleware, a code-change check or CI catches it. "The agent runs in OpenShell under a proven policy" covers the access column only.
- Test the violation, not the configuration. Have an agent make a forbidden change through each path it has: a direct edit, a shell command, an API call. Record which boundary stopped it, and which did not.
The zero trust argument for agents applies here: verifying the agent is necessary, and verifying the diff is a separate job.
Where Mneme fits
Mneme describes itself as a decision and control layer for agentic software development. It works on the decision side, inside the repository, and does not enforce infrastructure policy, provision cloud resources or manage identity and access.
In mneme-hq 0.10.0, the current release, decisions with an active typed rule (a machine-checkable rule attached to the decision) are enforced deterministically. For the storage-adapter decision above, a FORBID_LITERAL rule, which forbids an exact string, placed on the driver's import and scoped by path to src/handlers/, returns FAIL and names the decision.
Mneme checks writes made through an agent's built-in file tools before they land: Edit, Write and MultiEdit in Claude Code (Anthropic's coding agent), apply_patch in Codex CLI (OpenAI's terminal coding agent), and file writes in Kiro CLI 3.0 (Amazon Web Services' terminal coding agent). Writes made through shell commands usually reach the disk before Mneme sees them. Claude Code and Codex CLI check those when the agent finishes its turn, and other agents rely on CI.
In CI, a FAIL exits with code 2 and fails the job when the check runs in strict mode; in warn mode it reports the violation without failing the job. The Decision Index, Mneme's persisted, versioned record of decisions, keeps each decision's versions, lifecycle status and source. It does not record who approved a decision. Which decisions govern a change, and why, is the question of engineering decision governance.
No supported or released Mneme integration with OpenShell exists. A narrowly scoped example integration, covering only the file-write tool of OpenCode (an open-source terminal coding agent) in an OpenShell setup, is proposed in draft design documents in Mneme's open-source repository. No implementation has been merged, released or supported. Running a Mneme check behind a gateway interceptor or supervisor middleware, mapping OCSF events to Mneme evidence, and translating decisions into OPA or NVIDIA Sentry policy are conceptual. No adapter for any of them exists. The NVIDIA OpenShell integration page tracks this status, alongside separate pages for OPA and NVIDIA Sentry.