7 min read

NVIDIA OpenShell governs reachability. Dtwo governs meaning.

Security
Denis Knjazihhin

On September 28 NVIDIA announced OpenShell: an Apache-licensed runtime that puts each AI agent in a kernel-isolated sandbox and routes every connection it opens through a supervisor that checks policy before anything is allowed through. What OpenShell does not do is judge the request itself. It controls which systems an agent can reach, not what the agent does with them. The docs say an allowed tool “can receive any arguments accepted by the server,” and the supervisor evaluates each request on its own. That is where agent incidents live, and OpenShell leaves a middleware hook for it. Dtwo sits in that hook. If you run agents in OpenShell, you still need that second layer.

What OpenShell does

OpenShell is part of NVIDIA’s Open Agent Safety Platform. An agent inside OpenShell cannot open a network connection. It can only ask. The sandbox intercepts every TCP connection and DNS lookup at the kernel, identifies which program made the request, and forwards it to a supervisor that lives on the trusted side of the boundary. The supervisor checks the request against a YAML policy. If the policy allows it, the supervisor opens the real connection and relays the traffic. If not, the request never leaves.

The policy is specific. It lists the files the agent can read and write. It lists the hosts and ports each binary can connect to. For inspected protocols it goes one level deeper, detailing HTTP methods and paths, GraphQL operations, MCP methods and tool names. A rule can allow GET on an API and deny POST. It can allow an MCP server’s read_status tool and deny its delete_resource. Everything not explicitly allowed is denied.

Benefits of OpenShell’s reachability policies

Reachability policies are deterministic. The same request gets the same answer every time, and because the rules are formal, a prover can check that a proposed change stays inside the boundary the operator set before it takes effect. They are also cheap enough to run on every connection. The agent never sees the policy, only the denial, and since enforcement sits outside its process there is nothing for the model to talk its way around.

Any agent that can run code or open a socket benefits from exactly the kind of sandbox OpenShell provides.

Limitations of OpenShell’s policies

OpenShell’s documentation is candid about the edge of its model. On MCP rules it says: “Tool argument matching is not supported, so an allowed tool can receive any arguments accepted by the server.” OpenShell decides whether a tool may be called, not what it may be called with.

Argument matching may arrive in a later release. What will not change is the shape of the check. The supervisor evaluates each request on its own, with no record of what the agent did in another system a minute ago and no notion of the person the agent is acting on behalf of.

Say a policy allows an agent to read customer records from Salesforce and also allows Slack’s send_message tool. Each rule is reasonable on its own. Reading customer A’s record and posting it to customer B’s channel is still an incident, and a rule that sees one request at a time cannot catch it, however closely it inspects that one request. Agents complete tasks by chaining dozens of actions, and the risk is in how those actions combine. Catching the combination requires a check that remembers.

The middleware hook OpenShell leaves open

OpenShell’s own documentation points to where that check belongs. The supervisor has a middleware hook that runs after the reachability check and before credentials are added, and its stated purpose is to “inspect, block, or change the content that an agent sends and receives.” NVIDIA’s Technical Blog describes it as the place where “trusted middleware outside the sandbox can connect identity services and add application-specific checks.” That hook is where meaning gets governed, and it is where Dtwo sits.

What Dtwo does

Dtwo is a security control plane for agents. Agents connect to Dtwo instead of to each system, so every tool call passes through it on the way out and every result passes through it on the way back. Inside OpenShell, the supervisor holds that position and hands each allowed request to Dtwo; that flow is described below. On each call, Dtwo evaluates a set of policies against a structured record of the request: who the principal is, including the claims from their identity token; what action they are taking; which resource, down to the tool name; and the full context, meaning the arguments going in or the data coming back. A policy answers allow or deny with a reason. It can also return transforms that redact or rewrite the payload before it continues, so a response can arrive with the account numbers stripped out rather than not arrive at all.

What makes this layer different is that it remembers. Dtwo keeps track of what a user’s agent has done across every system in a session, so a policy can reason about the sequence as well as the call in front of it. That is what makes a rule like “if this session read privileged customer data, nothing goes to an external recipient” possible: the policy guarding Slack never has to learn anything about Salesforce, because Dtwo tells it what already happened. And that memory is not the agent’s to edit. Only a person can clear it, through a fresh sign-in at the company’s identity provider.

How Dtwo connects to OpenShell

Diagram of two policy layers in series. A tool call leaves the sandboxed agent and reaches OpenShell's supervisor, which asks whether this program may reach this host, method, and tool. An allowed request then passes to Dtwo, which asks whether the call should happen given the arguments and the session so far, and returns allow, deny, or change. Credentials are added only after both layers.Diagram of two policy layers in series. A tool call leaves the sandboxed agent and reaches OpenShell's supervisor, which asks whether this program may reach this host, method, and tool. An allowed request then passes to Dtwo, which asks whether the call should happen given the arguments and the session so far, and returns allow, deny, or change. Credentials are added only after both layers.

Dtwo connects to OpenShell through a supervisor middleware service. The flow for one request:

  1. The agent calls a tool. The sandbox catches the connection at the kernel and hands it to the supervisor.
  2. The supervisor checks reachability: this binary, this host, this method, this tool name. If the policy does not allow it, the request stops here and Dtwo never hears about it.
  3. The supervisor hands the request to Dtwo. Dtwo evaluates the caller, the arguments, and what happened earlier in the session against its policies and answers allow, deny, or change.
  4. If allowed, the supervisor adds the credentials and sends the request. Dtwo never sees them.
  5. The response comes back through the same hook. For the responses OpenShell exposes to middleware, which covers plain HTTP bodies within its size limit, Dtwo inspects or redacts what the agent is about to receive before it reaches the sandbox.

OpenShell blocks traffic by default when a middleware service is unreachable, so a layered system of this design fails closed whether or not the layer above is healthy.

If you use OpenShell, you still need Dtwo

One policy engine would be simpler: a single place to look. That is not available for agents, and the reason is structural rather than a product gap.

The controls that are cheap and certain operate on an attribute: host, port, method, tool name. They can be enforced by the kernel and verified by a prover, and nothing the agent says changes them. But the failures unique to agents are failures of meaning, and meaning is not visible in an attribute. The right tool with the wrong target looks identical, at the network layer, to the right tool with the right target.

The controls that see meaning operate on content and context: what is in the request, and what came before it. The kernel cannot enforce them, because the kernel does not know what a customer is. They need to sit somewhere that sees every system the agent touches and keeps a memory the agent cannot edit.

Put one underneath the other and each layer has one job. OpenShell confines the agent to the systems it was given. Dtwo, with the whole session in view, judges what the agent is doing with them against what the business intended. An OpenShell deployment without that second layer has a precise list of where the agent may go and nothing that can tell the right tool with the right target from the right tool with the wrong one.

Good policy unlocks AI adoption. OpenShell just made the foundation of that policy open and free, and left a hook above it for the checks it does not make. Dtwo sits in that hook.

Try it on your own agents. Start a free trial.

FAQ

What is NVIDIA OpenShell? OpenShell is an open-source runtime for AI agents. Each agent runs in a kernel-isolated sandbox with no direct network access. Every connection it opens passes through a trusted supervisor that checks it against a policy and adds credentials only for approved destinations. Everything not explicitly allowed is denied.

What does OpenShell’s policy control? Which files the agent can read and write, which user it runs as, which hosts and ports each program can reach, and for inspected protocols, which HTTP methods and paths, GraphQL operations, or MCP tools it can call. It is a reachability policy: it governs where requests can go and what shape they may have.

What does OpenShell’s policy not control? The content of the request and the context around it. OpenShell can allow a tool and deny another, but it does not match on tool arguments, and it evaluates each request on its own. A rule that allows an agent to send a Slack message cannot say to whom, about what, or whether the agent just read something that should not leave the company.

How does Dtwo connect to OpenShell? Through OpenShell’s supervisor middleware hook. After OpenShell confirms a request is allowed to reach its destination, and before it adds credentials, it hands the request to Dtwo. Dtwo evaluates it with policies that see the caller, the arguments, and what happened earlier in the session, and answers allow, deny, or change. Dtwo never sees the credentials. OpenShell blocks traffic by default when a middleware service is unreachable, so the layered system fails closed.

I use OpenShell. Do I still need Dtwo? Yes. OpenShell gives you a kernel-isolated sandbox and a network policy the agent cannot talk its way around, and that is a solid foundation. But agent incidents are built from individually permitted actions, and the failures that remain are about meaning: an allowed tool pointed at the wrong recipient, or called right after the agent read data that should not leave the company. OpenShell does not look at that. Its middleware hook is the place NVIDIA points to for identity and application-specific checks, and it is where Dtwo sits.

References

Get in touch

Tell us what you need to govern.

A few lines is plenty — what you're deploying, and what you need control over. We read every one.