How OpenSheaf relates to OpenShell
OpenSheaf is Sheaf's own build of OpenShell, the open-source sandbox runtime from NVIDIA. OpenShell fences what an agent may reach and never reads what it sends. OpenSheaf keeps that fence and adds one thing inside it: the Sheaf check, which reads every tool call before it leaves the sandbox, holds it when it does not add up, and records it. Policies and images written for OpenShell run unchanged. OpenShell is an NVIDIA product under the Apache 2.0 licence; OpenSheaf and Sheaf are independent of NVIDIA.
In one sentence: OpenShell is the fence, Sheaf is the check, and OpenSheaf is the one runtime that has both. Sheaf keeps its build current with OpenShell's releases and publishes what it changed.
The fence and the check, side by side
The two parts of OpenSheaf. Both are needed; neither replaces the other.
| The fence (from OpenShell) | The check (from Sheaf) | |
|---|---|---|
| What it decides | Whether an agent may reach a file, a network endpoint, a tool or a credential. | Whether the action an agent is about to take holds together with the facts, the rules and what the other agents concluded. |
| Where it sits | Around the agent: a sandbox with kernel-level isolation. It allows or refuses each connection. | Inside the sandbox, on the way out: it reads each tool call before the connection the fence allows carries it. |
| What it can see | The endpoint, the protocol, the binary making the call. Not the tool name or its arguments; by NVIDIA's own description it works below that level. | The tool name, the arguments, and the reasoning the agents gave. That is what it measures. |
| How it is proven | Policies written in YAML are compiled to formal logic and checked by a prover, so the permissions granted are exactly the permissions intended. | The check is a measurement from published mathematics, with its central theorems formalised in Lean and checked by machine. The proofs are public. |
| When it says no | The request is blocked and the agent gets a descriptive error. | The action is held, with the contradiction in plain words, until a named person releases or refuses it. |
| What it records | An audit trail of decisions in the Open Cybersecurity Schema Framework. | Every check, hold and release, signed and timestamped by an independent authority, and written in the same audit format so both sit on one timeline. |
| What it does not do | Judge whether an allowed action makes sense. | Isolate the agent from the machine. That is the fence's job, and the check relies on it. |
The failure each one catches
An agent reaches for something it should not.
It tries a network endpoint, a file, or a credential that is outside its policy. The fence refuses the connection at the kernel. The check never sees it, and does not need to.
An agent does something it is allowed to do, on reasoning that does not add up.
It has permission to approve a remortgage, and approves one where two of its own checks used two different incomes for the same customer. The fence allows it; the endpoint is in policy. The check reads the call, finds the contradiction, and holds it inside the sandbox for a person.
How they run together
A policy, not a rewrite. The agent does not change.
- The fence sets the doors. The sandbox policy names the addresses the agent may reach. For an agent made in the Sheaf builder that is one address, Sheaf itself. The fence enforces it at the kernel, so the agent cannot reach anything else.
- The check reads every call on its way out. Harmless calls go through at once. A call that matters is decided first: against your rules, and where the rules cannot settle it, by a panel of models whose agreement is measured. A call the check holds never leaves the sandbox. It waits for a person, who releases it or turns it down, and a release executes exactly what was parked, never anything the agent re-supplies.
- The agent never holds your key. On Sheaf, the program in the sandbox carries a short-lived token for that one run. On your own machine, the policy carries the key and the sandbox cannot send it anywhere but Sheaf.
- One record. The fence's decisions and the check's decisions are written in the same audit format, so the connection that was allowed, the action that was checked, and the person who released it appear on one timeline.
# the check, attached to a sandbox policy: every call to the agent's tool server is decided before it leaves network_middlewares: sheaf: middleware: sheaf/gate config: key: sk_pod_… # the Sheaf key of the agent's account gate: 2b1c… # a gate from the console, for an agent that reaches tool servers directly on_error: fail_closed endpoints: include: ["tools.example.com"]
An agent made in the builder needs no gate id: its calls go through Sheaf and the account's own tool rules decide each one. To run one on your own machine, the console gives one command; Get Sheaf has it.
See it
The same agent twice.
First on the fence alone: the agent approves a remortgage whose own checks contradict each other, and the approval goes through, in policy. Then on OpenSheaf: the same approval is held inside the sandbox, the contradiction named, and a person decides. The demo below runs the second half on Sheaf's live gate.