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

NVIDIA OpenShell, an open-source runtime that executes autonomous agents in sandboxed environments, enforces Confidential data rules through declarative YAML policies covering filesystem access, Landlock behavior, process identity and network access, with network_policies defaulting to deny all outbound traffic except approved destinations. A walkthrough of translating a Confidential rule into OpenShell policy found that roughly half of the requirements map to the policy file, while the remaining three — no persistence, expiring decisions and verifying the requesting user currently has source access — must be handled by the orchestrator, input staging or pre-sandbox checks. The post argues that compiling a rule into a runtime's policy requires both translating each requirement into a native control and negotiating whether the runtime can express it at all, since a generator that emits only YAML would produce a file that looks complete and silently omits those controls.

From Data Classification to NVIDIA OpenShell Policy: Compiling Confidential Rules into Filesystem and Network Controls 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 https://docs.nvidia.com/openshell/latest/about/overview.html , 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: php 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 https://contextiq.trango-compute.com/blog/how-to-test-whether-agent-runtime-enforces-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 https://contextiq.trango-compute.com/agent-data-policy . Follow Trango Compute on LinkedIn We post updates on new tools, context engineering patterns, and LLM cost research. Follow on LinkedIn https://www.linkedin.com/company/trango-compute