From Data Classification to NVIDIA OpenShell Policy: Compiling Confidential Rules into Filesystem and Network Controls

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:

1. Translate each requirement into the runtime's native control.
2. 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 unsupported as "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.