How a Confidential data rule maps to NVIDIA OpenShell policy YAML: filesystem, Landlock, process and network_policies, plus controls a policy file can't express.
A data classification says how sensitive a file is. A sandbox policy says what a process may touch. Between them sits a translation step that most teams do by hand: take "Confidential data may be used by agents only in an isolated session with no arbitrary egress" and turn it into a runtime's configuration.
This post walks through that translation for NVIDIA OpenShell, an open-source runtime that executes autonomous agents in sandboxed environments, and points out where a policy file stops being enough.
OpenShell policy at a glance #
OpenShell policies are declarative YAML. According to NVIDIA's documentation and Q&A material, a sandbox policy covers filesystem access, Landlock behavior, process identity and network access, and is created per sandbox or inherited from a default. NVIDIA also recommends treating policy YAML as version-controlled security controls that can be reviewed and audited.
The filesystem and Landlock portion of a policy looks like this (field names as they appear in NVIDIA's public example policies; consult the official Sandbox Policies page for the full schema):
filesystem_policy:
read_only: [/usr, /lib, /app, /etc]
read_write: [/sandbox, /tmp]
include_workdir: true
landlock: best_effort
Network rules are declared separately under network_policies. Each rule names a destination host and port, and can carry a protocol, an enforcement mode, an access level such as read-only, and the binaries allowed to use it.
NVIDIA's docs state that network policies allow only approved destinations and deny other outbound traffic. That default-deny posture is what makes an allowlist a meaningful control.
The rule we want to enforce #
Start from a Confidential rule written in plain language:
Confidential data may be used by an agent only when:
- the requesting user currently has source access;
- the session is isolated;
- input is read-only;
- arbitrary network egress is blocked;
- only an approved model endpoint is reachable;
- nothing persists after the task;
- the decision expires.
Mapping each requirement #
| Requirement | Where it can live in an OpenShell policy | Notes |
|---|---|---|
| Isolated session | One sandbox per task, created with its own policy | A lifecycle choice by whoever launches the sandbox |
| Read-only input | Place the staged file under a read_only path |
Keep the staging directory out of read_write |
| Arbitrary egress blocked | A network_policies allowlist with default-deny behavior |
Allow only the model endpoint |
| Approved model endpoint only | A single network rule for that host and port | Narrow by binary and access mode where supported |
| No persistence | Ephemeral workspace; do not mount durable volumes | Not obviously a policy-file property; verify it |
| Decision expires | Short-lived sandbox and short-lived staged input | Enforced by the orchestrator, not the sandbox |
| User currently has source access | Not in the sandbox at all | Checked before the file is staged |
Read the right-hand column carefully. Roughly half of the requirements are expressed in the policy YAML. The rest belong to how the sandbox is launched, how the input is staged, or what happens before the sandbox exists. A policy generator that emits only YAML would produce a file that looks complete and silently omits the last three rows.
Capability negotiation, not just generation #
This is the point worth taking away. Compiling a rule into a runtime's policy is two jobs:
- Translate each requirement into the runtime's native control.
- Negotiate capability: for each requirement, decide whether the runtime can actually enforce it, and say so.
If a requirement has no enforceable counterpart in the target runtime, the decision should not quietly drop it. It should deny raw content, or release a safer representation such as metadata, and record which guarantee was unavailable. "No silent downgrade" is the property to insist on.
Verifying a candidate policy against a boundary #
OpenShell ships a prover, openshell-prover, that checks a candidate policy against a boundary policy describing the most the sandbox is allowed to do. At the time of writing it is an early 0.1.x release, and NVIDIA's open issues show its model is still being extended: some policy shapes return unsupported instead of a verdict.
That is a useful reminder when you build a pipeline around it:
- Treat
unsupportedas "not verified," never as "passed." - Keep the boundary in version control next to the policy.
- Re-check the release notes when you upgrade; coverage changes between versions.
A negative test you can run today #
A policy that has never been tested against a forbidden action is a hypothesis. For the Confidential rule above, run these from inside the sandbox and expect each to fail:
read a file outside the staged input path -> denied
write to the staged input path -> denied
connect to a host that is not the model endpoint -> blocked
write a file, end the task, start a new sandbox -> file absent
The final post in this series, How to Test Whether an Agent Runtime Enforces a Data Policy, expands this into a repeatable checklist.
Where ContextIQ fits #
ContextIQ Agent Data Policy is an Enterprise Preview aimed at this translate-and-negotiate step: take the source classification and the user's entitlement, apply your agent rule, check what OpenShell can enforce, and return a decision with the generated controls, the limitations, and the evidence. Google Drive to NVIDIA OpenShell is the initial validation path; other runtimes are planned and not supported today. ContextIQ is an independent project and is not endorsed by or affiliated with NVIDIA.
We are working with design partners that have one classified data source and one agent workload to approve. To be one, request an Enterprise Preview demo.
Follow Trango Compute on LinkedIn
We post updates on new tools, context engineering patterns, and LLM cost research.