OpenShell puts a supervisor between agents and the network

The agent chooses; the runtime checks

An agent can decide to read a file, launch a command, or contact an API. Those decisions come from its model and tool loop. NVIDIA OpenShell 0.1.0 places controls around that existing workload: a Gateway supplies sandbox configuration, a runtime driver constructs its boundary, and a Supervisor mediates outbound connections. The distinction matters because policy enforcement can constrain an action without making the agent's reasoning reliable.¹²³

This walkthrough follows one illustrative task: read a project README and request a page of GitHub issues over the public API, while denying a write request. It is a source-based trace, not a test run. It shows which component gets a chance to reject each operation, and what the trace cannot establish about the agent or the remote API.

GitHub records the v0.1.0 release on September 25, 2026. The tag pins the implementation discussed here to commit 496ebba293f5cc2bb2753444dddd534f0b4aeb6a. That avoids importing behavior from later releases or the moving development branch.¹

The Gateway sets policy; the Supervisor decides egress

The Gateway owns sandbox state and policy delivery. A compute driver creates the outer workload boundary using a configured runtime. Inside that boundary, the agent and its tools run alongside an OpenShell Supervisor. The sandbox routes DNS and TCP through the protected Supervisor channel. The outer fence is intended to prevent the workload from opening a direct route around that channel; the Supervisor evaluates the request and opens an approved upstream connection.²⁴

That makes the Gateway a control-plane owner, not the decision point for each packet. In the v0.1.0 implementation, the Supervisor's network service evaluates policy through OPA. The bundled Rego policy defaults allow_network to false and matches endpoint and calling binary. An allowed destination alone does not imply that every process in the sandbox may use it.⁵⁶

Policy composition affects the result. The versioned policy guide lists global, saved, image, and restrictive default policies. An active global policy replaces the sandbox policy and suppresses provider-contributed rules. A reviewer should therefore inspect the effective policy that reached the sandbox, not infer permissions from one YAML fragment in isolation.³

The 0.1.0 installation guide describes Docker, Podman, and MicroVM runtimes, with host-specific prerequisites. OpenShell does not require BlueField hardware for these software paths.⁷

Landlock narrows files; seccomp helps route network calls

For local files, OpenShell's Linux sandbox installs Landlock restrictions before launching the workload. Landlock is a Linux security module that lets a process add restrictions to its own filesystem access. In the example, the project directory is granted read-only access and no writable project path is configured. A write under that directory should therefore fail at the kernel boundary, assuming the configured rules are active and the process remains inside the sandboxed path.⁴⁸⁹

There are two different failure modes to check. The mandatory private /.openshell self-protection baseline requires Landlock ABI v3. User filesystem rules can instead use best_effort; the tagged implementation may continue without those optional restrictions and emit a finding. Operators who depend on a particular project-path rule should check the effective mode and runtime evidence, or require that rule, rather than treating every filesystem setting as fail-closed.⁴⁸

Seccomp has a narrower role than a complete syscall allowlist. The v0.1.0 filter sets no_new_privs and applies a default-allow filter with targeted blocks and compatibility allowances. For supported Internet sockets, seccomp user notification can hand a connect decision to a userspace Supervisor. The Linux manual cautions that user notification alone is not a security-policy mechanism. OpenShell combines it with the Supervisor's policy check and an outer network fence; none of those layers should be described as an independent guarantee by itself.¹⁰¹¹⁴

A read request passes a binary, endpoint, and method check

The following policy illustrates a narrow rule for one executable, one host, and one HTTP method/path. The project name and executable path are examples. An operator would need to verify that the selected image actually places curl at this path. The public GitHub endpoint needs no credential in this example.

version: 1
filesystem_policy:
  include_workdir: false
  read_only:
    - /workspace/project
  read_write: []
network_policies:
  github_issues:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        rules:
          - allow:
              method: GET
              path: /repos/acme/widget/issues
    binaries:
      - path: /usr/bin/curl

First, the Gateway stores and supplies policy while the compute driver creates the sandbox boundary. Global policy or provider rules can change the effective result, so the fragment is not a complete account of policy composition. At startup, the sandbox applies filesystem and process controls; the Supervisor validates its protected position before allowing workload launch, according to the tagged architecture description.²³⁴

Next, the agent asks to read /workspace/project/README.md. Landlock mediates the local file operation against the configured read-only path. An attempted write there has no configured write grant and should be rejected if the expected policy is active. This is file authority: it does not decide whether the contents are true, safe to follow, or suitable to send elsewhere.

For the API call, the agent launches curl with GET https://api.github.com/repos/acme/widget/issues?per_page=5. DNS and TCP are directed through the Supervisor path. The outer fence blocks direct outbound connections, and the Supervisor checks both /usr/bin/curl and api.github.com:443. REST inspection then compares the request method and path with the enforced rule before forwarding it upstream. A POST to the same path lacks a matching allow rule and is denied before forwarding; the documented policy flow returns a policy denial. These are expected steps inferred from source and documentation, not observed output from a run.^12131456

Method filtering does not make GET semantically read-only. An upstream service can attach side effects to a GET, and an allowed response can still contain data the agent should not expose. The documented read-only preset permits GET, HEAD, and OPTIONS; the example above narrows the rule to GET, but neither form proves the API token or endpoint has read-only semantics. HTTP verbs are policy inputs, not a transaction guarantee.¹²

Credentials stay outside only under compatible policy

For supported provider flows, the agent can see a placeholder while the Supervisor substitutes the real credential on the upstream request. The intent is to keep provider secrets out of the workload and scope their use to an approved destination. But the source makes the boundary conditional: credentialed endpoints using only layer-four rules or skipping TLS inspection are rejected unless an explicit escape hatch is enabled. The policy does not prove that a token itself has narrow permissions. Where the provider supports it, use a least-privilege token as a separate control.²¹⁴¹⁵

OpenShell can emit structured events for network decisions, process and filesystem activity, and policy changes. Its v0.1.0 Gateway keeps a bounded recent-log buffer in memory; a restart loses that buffer, and a subscriber whose cursor fell behind can receive a gap indication or an out-of-range response. Operators need to export the event stream to durable storage if they need retention. The default buffer is useful for recent inspection, not evidence of a complete, immutable audit history.¹⁶

Runtime controls cannot establish safe model behavior

The public evidence supports a concrete integration surface: OpenClaw maintains documentation for an OpenShell sandbox backend, delegates lifecycle to the OpenShell CLI, and uses SSH to execute commands. That shows a third-party project has built an integration. It supplies no usage counts, deployment scale, or proof of production adoption by NVIDIA's named Cadence, Slack, and Gecko Robotics examples. Those named claims remain NVIDIA's statements in the available evidence.¹⁷

Keep the launch claims distinct as well: GitHub records the v0.1.0 release on September 25, 2026, and NVIDIA announced general availability on September 28. NVIDIA's Open Agent Safety Platform is a broader effort, while Sentry is a distinct hardware component; these announcements do not make them one deployed product.¹¹⁵¹⁸

Independent launch reporting distinguishes OpenShell from Sentry and quotes an outside computer-science professor asking for case studies to weigh performance tradeoffs. The materials reviewed here contain no independent adversarial evaluation, penetration test, false-positive or false-negative rate, or measured security outcome for v0.1.0. A source review shows where checks are implemented; it does not establish their resistance to kernel/runtime defects, a compromised host, an overbroad policy, or operator error.¹⁸¹⁹

The useful conclusion is specific: OpenShell moves some authority out of an agent's hands by constraining files locally and requiring outbound requests to pass a separate policy decision. That can reduce the reach of a mistaken or manipulated tool call when the runtime, policy, and logging are configured as intended. It does not secure the model's honesty or correctness, decide whether granted access is wise, or prove that an allowed API read has no effect. A trial should evaluate those boundaries against the actual workload and preserve logs outside the Gateway.