NVIDIA released OpenShell 0.1.0, an open-source runtime that defines and enforces which systems, data, and services an AI agent can access at runtime. The project combines sandboxed execution, controlled service access, credential management, and formal policy analysis so teams can grant necessary capabilities while enforcing permissions outside the agent workload.
Why this matters
Long-running AI agents can pursue goals, write code, use tools, and continue working as new information arrives, enabling tasks such as investigating software failures, running experiments, and performing business-critical or research actions over days or weeks. Those capabilities require access to workspaces, compute, data, credentials, and external services — which raises the risk of consequential failures like modifying production data or exposing confidential information.
What OpenShell 0.1.0 provides
OpenShell enforces runtime controls around existing agents without requiring them to be rewritten. It is the runtime layer of NVIDIA's broader Open Agent Safety Platform, which extends protections across application, runtime, and infrastructure layers. The 0.1.0 release supports sandbox operations, policy verification, governance integration, credential protection, and flexible compute (CPU/GPU across containers, VMs, and Kubernetes).
Core architecture and enforcement
OpenShell separates enforcement from workload with three components:
- OpenShell Gateway: manages lifecycles and policies for many sandboxes.
- OpenShell Supervisor: paired with each sandbox, runs outside the agent workload and checks outbound requests against policy.
- OpenShell Sandbox: runs the workload with kernel-level controls over filesystem and processes, and has no network path except through the supervisor.
The sandbox runtime uses OS kernel controls to restrict which files a workload can read or change and to prevent privilege escalation. For network access the supervisor can inspect HTTP, GraphQL, and Model Context Protocol (MCP) traffic: for example, it can allow a data query while blocking a write through the same API. These controls persist when an agent opens a shell, executes generated code, launches child processes, or delegates tasks to sub-agents. Policy decisions are recorded in an Open Cybersecurity Schema Framework (OCSF) audit trail; when OpenShell blocks an inspected request it can return a descriptive error to help the agent decide next steps.
Example: network policies and GitHub
The release notes show a hands-on example using two policy files (no-network.yaml and github-readonly.yaml) and curl against the unauthenticated GitHub REST endpoint so policy decisions are visible without API keys. After installing OpenShell and placing the example policies in an examples directory, you can create a sandbox with no outbound network:
openshell sandbox create --name policy-demo \
--no-auto-providers \
--policy examples/no-network.yaml
A curl to https://api.github.com/zen from inside that sandbox fails because outbound network is disallowed. Host logs reveal which program was blocked:
openshell logs policy-demo --since 5m
Replacing the policy with one that permits read-only access to the GitHub REST API (compiled from YAML to OPA/Rego) and applying it without restarting the sandbox:
openshell policy set policy-demo \
--policy examples/github-readonly.yaml --wait
The sandbox can then perform GET requests (allowed) while POST requests are blocked; the same restrictions apply to agents that issue the calls.
Credential protection and provider binding
Many agents need model APIs or private services. OpenShell authorizes access while keeping real credentials outside the agent workload. A provider profile defines credentials, endpoints, and permitted programs. OpenShell substitutes a placeholder credential inside the workload and binds the real credential only for authorized endpoints; if the placeholder is sent to an endpoint outside the credential’s approved list, OpenShell rejects the request.
Authorization to use a service does not make the credential available to other services, and OpenShell can add an additional control layer (for example, an inspectable read-only API policy can block write requests even when the credential has write permission). Example sandbox creation attaching a configured GitHub provider and launching Codex:
openshell sandbox create \
--provider github \
-- codex
Dynamic permission requests and policy advisor
If an agent discovers during runtime that it needs access not covered by the current policy, OpenShell records the denial. With policy advisor enabled, the agent can propose narrowly scoped network or file policy changes; proposals remain pending human review by default and an agent cannot approve its own requests. Once approved, OpenShell loads the new rule into the running sandbox so the agent can retry without restarting. Filesystem and process restrictions are fixed at sandbox start and require a new sandbox to change.
Enable policy advisor for a sandbox:
openshell settings set <sandbox-name> \
--key agent_policy_proposals_enabled \
--value true
Formal policy verification (policy prover)
OpenShell includes a policy prover that uses formal methods to check the permissions granted by policies, including provider-contributed access. It can prove that modeled permissions stay within an operator-defined boundary or produce a concrete action that crosses it. Because the result is derived from the policy model, an agent’s explanation cannot alter that outcome.
The release notes report that in long-horizon adversarial experiments, frontier agents with reduced safeguards spent up to two hours attempting to persuade an AI reviewer to grant permissions that would allow modification of a protected GitHub repository; OpenShell's formal analysis provided reviewers evidence of what those permissions would enable, and no protected repository writes occurred in those tests. Ongoing work aims to extend policy analysis across multiple agents to evaluate combined system permissions.
Adoption, integrations and where to start
OpenShell is open source and intended for enterprise adoption across a partner ecosystem. Reported adopters and use cases include:
- Cadence: using OpenShell for chip design with its ChipStack Autonomous RTL Design Engineer.
- Slack: building an on-demand agent platform on OpenShell to automate tasks.
- Gecko Robotics: governing agents that make decisions on physical robots.
Trusted middleware can integrate identity services and application-specific checks; compute drivers connect OpenShell to Docker, Podman, MicroVM, and Kubernetes (see the support matrix for requirements). Developers can join #openshell-dev on CNCF Slack, explore and contribute on GitHub, and follow OpenShell dev notes. For upgrades, consult the 0.1.0 migration notes. To begin, the quickstart walks through running an agent with OpenShell and configuring the services it may access.
