The open-source release controls files, processes, network requests, credentials, and policy changes outside the agent itself.
NVIDIA has announced OpenShell 0.1.0, an open-source runtime for controlling what an AI agent can access while it works. The software targets agents that write code, use tools, and continue tasks for days or weeks.
The practical idea is simple: let the agent make decisions, but keep its permissions under a separate control layer. NVIDIA says OpenShell can add these controls around an existing agent without requiring developers to rewrite it.
That matters because useful agents need access to workspaces, data, computing resources, credentials, and outside services. The same access can let an agent change production data, expose confidential information, or move beyond its assigned task.
How OpenShell limits an agent
OpenShell divides the work among three parts. The Gateway manages the lifecycles and policies of multiple sandboxes. A sandbox is an isolated environment where the agent runs. The Supervisor sits beside each sandbox, outside the agent’s workload, and checks outgoing requests against policy.
The sandbox uses operating-system kernel controls to limit which files the agent can read or change. It also controls processes and prevents the workload from gaining additional system privileges. The sandbox has no direct network path except through the Supervisor.
This arrangement is meant to prevent an agent from escaping its rules simply by starting a shell, running generated code, launching another process, or asking a second agent to act for it. The restrictions stay in place across those actions.
The Supervisor can inspect configured HTTP, GraphQL, and Model Context Protocol traffic. That allows a policy to permit a data query while blocking a write through the same service. In ordinary terms, an agent might be allowed to read from an application programming interface but denied permission to change anything.
NVIDIA’s example uses a read-only policy for the GitHub application programming interface. A request to read data is allowed, while a request using the same service to make a change is blocked. OpenShell records the decision in an audit trail and can return an explanation that helps the agent choose another action.
Credentials stay outside the workload
OpenShell also separates an agent from the real passwords or access keys needed by private services. A provider profile defines the approved service, endpoints, and programs. OpenShell supplies the real credential only for an authorized request.
A credential approved for one service cannot automatically be used at another destination. OpenShell can also block a write request even when the underlying credential technically has permission to write.
That creates two separate checks: the service decides what the credential can do, while OpenShell decides how the agent may use it.
When an agent encounters a blocked request, it can propose a narrowly limited policy change. The proposal remains pending for human review by default, and the agent cannot approve its own request. Network and file-policy changes can then be loaded into a running sandbox, while basic filesystem and process controls require a new sandbox.
OpenShell also includes a policy prover. This formal-logic tool checks whether a policy grants more access than an operator intended, including access added through service credentials. It can identify a concrete action that crosses the defined boundary instead of relying on the agent’s own explanation.
NVIDIA reports that, in adversarial experiments lasting up to two hours, agents with reduced safeguards tried to persuade an artificial-intelligence reviewer to grant access to a protected GitHub repository. The company says the combined review and runtime controls allowed useful access and produced no protected-repository writes in those tests.
What remains to be tested
OpenShell is an announced 0.1.0 release, so teams will need to validate it in their own environments. NVIDIA’s developer documentation says it supports several agent frameworks and can run workloads across containers, virtual machines, and Kubernetes. The documentation points users to a support matrix for current requirements.
The available sources do not establish independent testing, deployment scale, customer results, inspection overhead, or false-positive rates. Those details matter to teams running long-lived agents, where an overly strict policy could interrupt legitimate work.
NVIDIA places OpenShell within a broader Open Agent Safety Platform. TechCrunch reports that the platform also includes Sentry, a monitoring system intended to run on a separate processor and provide an independent view of agent activity. NVIDIA says that combination can quarantine agents that cross their boundaries, but the available reporting does not provide independent measurements of that process.
For developers, the immediate next step is to start with a local sandbox, define the smallest set of files, services, and credentials an agent needs, and test blocked actions before expanding access. That turns agent safety from a promise inside the model into a set of enforceable rules around it.