NVIDIA OpenShell 0.1.0 Adds Runtime Controls to AI Agents Without Rewrites

NVIDIA has released OpenShell 0.1.0, an open-source runtime that defines and enforces which systems and data an AI agent can access, without requiring teams to rewrite the agent. According to NVIDIA, it combines sandboxed execution, controlled service access, credential management and formal policy analysis.
- NVIDIA OpenShell 0.1.0 is an open-source runtime that enforces which systems and data AI agents can access.
- Controls sit outside the agent workload and use a Gateway, Supervisor and Sandbox with kernel-level restrictions.
- The supervisor can inspect HTTP, GraphQL and MCP traffic, allowing reads while blocking writes.
- Real credentials stay outside the agent and are bound only to authorized endpoints.
- Cadence, Slack and Gecko Robotics are named as adopters.
Why agent access needs enforcement
NVIDIA describes agents as systems that can be given a goal, write code, use tools and keep working as new information becomes available. That opens the door to applications that investigate software failures, run experiments and carry out business-critical actions and research over days or weeks.
Useful agents need access to workspaces, compute resources, data, credentials and external services. According to NVIDIA, broader access also creates more consequential failure modes, from changing production data or exposing confidential information to acting beyond the assigned task. OpenShell is meant to let teams grant the capabilities a task requires while the permissions are enforced outside the agent workload.
NVIDIA says OpenShell supports Codex, Claude Code, Pi, Hermes and future frameworks. It is the runtime layer of the broader NVIDIA Open Agent Safety Platform, which extends protection across the application, runtime and infrastructure layers.
How OpenShell is built
Three components provide the control. The OpenShell Gateway manages the lifecycles and policies of many sandboxes. The OpenShell Supervisor is paired with each sandbox, runs outside the agent workload and checks outbound requests against policy. The OpenShell Sandbox runs the workload with kernel-level controls over its filesystem and processes, and has no network path except through the supervisor.
The sandbox uses operating-system kernel controls to limit which files a workload can read or change and to prevent it from acquiring additional system privileges. For network access, the supervisor can inspect configured HTTP, GraphQL and Model Context Protocol (MCP) traffic. That allows, for example, a data query to pass while a write through the same API is blocked.
According to NVIDIA, these controls stay in place when the agent starts a shell, runs generated code, launches child processes or proposes task delegation to sub-agents. Policy decisions are recorded in an Open Cybersecurity Schema Framework (OCSF) audit trail. When a request is blocked, OpenShell can return a descriptive error that helps the agent decide what to do next.
- Multi-tenant platform support, with separate workspaces, permissions and service access on shared infrastructure.
- Formal policy verification, showing human and AI reviewers whether requested permissions stay within defined security boundaries.
- Extensible security and governance, connecting third-party security services, governance systems and custom checks.
- Credential-protected service access, where real credentials remain outside the agent workload and are bound to authorized requests.
- CPU and GPU execution across containers, VMs and Kubernetes environments.
A policy demo with GitHub's API
NVIDIA walks through an example using curl and an unauthenticated endpoint in the GitHub REST API, so no API key or language model is needed. A sandbox is first created with a no-network policy, and a request to the public endpoint fails. Logs on the host show which program made the request and why it was blocked.
The sandbox policy is then replaced, without restarting the sandbox, by one that permits read-only access to the GitHub REST API. Policies are authored in YAML and compiled to OPA/Rego, which OpenShell evaluates for each outbound request. With the rest protocol setting, OpenShell inspects HTTP requests, allowing reads while blocking writes. A GET request succeeds and a POST is blocked, and NVIDIA says an agent running the same commands would meet the same restrictions.
On credentials, NVIDIA says OpenShell authorizes access to model APIs or private services while keeping the real credentials outside the agent workload. The real credential is substituted outside the workload and only for an authorized endpoint. Both network access and credential binding must permit the request, and authorization for one service does not make the credential available to another.
Adoption and what it means
NVIDIA names three adopters. Cadence uses OpenShell for chip design with its ChipStack Autonomous RTL Design Engineer. Slack is building an on-demand agent platform on OpenShell to automate tasks. Gecko Robotics uses it to govern agents making decisions on physical robots.
NVIDIA also says the policy prover uses formal logic to verify that modeled permissions remain within defined boundaries and to identify actions that cross them. Teams can build locally with a sandbox and then deploy into shared infrastructure using workspaces, compute drivers for Docker and Kubernetes, and trusted middleware for identity services.
For teams running long-lived agents, the pitch is a way to restrict API operations, protect credentials and review permission changes without modifying the agent itself. NVIDIA points developers to a quickstart, the GitHub repository and the CNCF Slack #openshell-dev channel.
NVIDIA Developer: Add Runtime Controls to AI Agents with NVIDIA OpenShell


