NVIDIA ships OpenShell 0.1.0 to enforce agent runtime permissions outside the workload, allowing reads while blocking writes and keeping credentials out of the agent

OpenShell 0.1.0 moves permission enforcement outside the agent workload through three components: the Gateway manages the lifecycles and policies of many sandboxes, the Supervisor is paired with each sandbox and checks outbound requests against policy from outside the workload, and the Sandbox runs the workload with kernel-level controls over filesystem and processes and no network path except through the supervisor. Rather than embedding security constraints in the agent's own logic or prompts, the enforcement point sits outside the workload, so controls remain in place when the agent starts a shell, runs generated code, launches child processes, or proposes task delegation to sub-agents. The post describes component responsibilities and shows example commands, and states that policy decisions are recorded in an OCSF audit trail; no performance or throughput figures are given.

Network policy can distinguish reads from writes on the same API: policies are authored in YAML and compiled to OPA/Rego, which OpenShell evaluates for each outbound request; in the example, protocol: rest makes the supervisor inspect HTTP requests, allowing reads to api.github.com while blocking a POST to the same endpoint, and the replacement policy is applied without restarting the sandbox. Compared with merely allowing or denying a connection to a service, the control granularity moves to the request-semantics level, and the post states the supervisor can inspect HTTP, GraphQL, and MCP traffic. The example uses curl and an unauthenticated endpoint in the GitHub REST API so each policy decision is visible without an API key or a language model; the post states an agent issuing the same requests encounters the same restrictions.

Credentials stay outside the agent workload and are bound to authorized requests: authorization for one service does not make the credential available to another, and if the placeholder is sent to a destination outside the credential's approved endpoints OpenShell rejects the request; the receiving service still enforces the permissions attached to the real credential, and OpenShell adds a separate control over how the agent can use it, so an inspected read-only API policy can block write requests even when the credential itself has write access. Credential custody is layered with request-level policy, so permission control no longer rests solely on the downstream service's authorization scope for the credential. The post defines credentials, endpoints, and permitted programs through a provider profile and shows commands attaching a GitHub provider named github to a new sandbox and launching Codex.

The policy prover uses formal logic to check the permissions a policy grants, including provider-contributed access, and can prove modeled permissions remain within an operator-defined boundary or identify a concrete action that crosses it; because the result comes from the policy model, an agent's explanation cannot change it. The post reports that in long-horizon adversarial experiments frontier agents with reduced safeguards spent up to two hours trying to persuade an AI reviewer to grant permissions that would let them modify a protected GitHub repository, that formal policy analysis gave the reviewer evidence of what those permissions allowed, and that no protected repository writes occurred in these tests. Permission review shifts from relying on reviewer judgment to using the policy model as the source of evidence, so a verifiable permission boundary remains available even when agents attempt to manipulate the reviewer. The result comes from the long-horizon adversarial experiments described in the post, with no number of runs, sample size, or statistic given; the authors also state that policy analysis across multiple agents is ongoing work.

The runtime targets teams that need to give agents real access to systems and data: internal agent fleets, long-horizon research, chip design, enterprise automation, accelerated computing, and robotics and edge systems. The path is to start with a local sandbox while building an application and defining its permissions, then follow the workspaces and access guide and use the SDK to create and manage sandboxes for multiple users, with each workload having its own policy and attached providers; trusted middleware outside the sandbox can connect identity services and add application-specific checks. The policy advisor lets an agent propose a narrowly scoped network or file policy change after a request is blocked, the proposal remains pending for human review by default and the agent cannot approve its own request, and after approval the new rule loads into the running sandbox so the agent can retry without restarting; filesystem and process restrictions are established when the sandbox starts, and changing those controls requires a new sandbox.

The adversarial experiments are described only qualitatively, with no number of runs, number of participating agents, or statistical measure, so 'no protected repository writes occurred' should be read as an observation within that set of tests rather than a general guarantee. Policy analysis across multiple agents is ongoing work, and how the permissions of the system they form together are checked when one agent's access combines with another's has no conclusion yet. The prover checks modeled permissions, and whether paths the model does not cover could escape proof is not addressed. In addition, filesystem and process restrictions are fixed when the sandbox starts and require a new sandbox to change, and the post does not quantify the operational cost of that for long-horizon tasks.