OpenShell is NVIDIA's "secure, private runtime for autonomous AI agents." It is positioned as a controlled execution environment for large numbers of autonomously operating AI agents, allowing agents to have real capabilities without granting them full access to user data, keys, and networks.
I. Purpose and Core Approach Agents are most useful when they can read files, install software packages, call APIs, and use credentials. OpenShell's approach is for users to declare, through "policies," the scope of resources each agent can touch, and then for OpenShell to enforce that policy at runtime. In this way, agents gain capabilities, but access boundaries are strictly defined by policy.
II. Enforcement Mechanism OpenShell governs agent behavior in two ways:
- Kernel-level enforcement: policy is enforced at runtime for every file access, system call, and network connection. Each agent runs in an isolated sandbox, and kernel controls restrict the files it can access and the system calls it can make; every network connection must pass a policy check before leaving the sandbox. Agents do not see real credentials; OpenShell only adds credentials to requests sent to approved endpoints.
- Formally verified policy changes: before a policy change is approved, OpenShell uses formal verification to flag high-risk new access that the change would grant, such as using credentials to access a new host or calling a new API method; such changes await human review. In addition, the documentation provides an architecture description (Architecture) explaining how the gateway, supervisor, and sandbox work together.
III. Runtime Environment and Installation Running OpenShell requires: Linux, macOS on Apple Silicon, or Windows with WSL 2 (experimental), as well as Docker, Podman, or host virtualization; see the Support Matrix for details. The installer sets up the CLI and a local gateway. The default sandbox image is a minimal Ubuntu with no agent installed. To run a real agent, follow the "Run Your First Agent" tutorial: it uses OpenCode with a free OpenRouter model and demonstrates how to approve new access when an agent needs it.
IV. AvailableFeature Areas
The documentation lists the following directions for further exploration:
- Sandboxes: images, runtime, GPU, and lifecycle.
- Policies: filesystem, network, and process rules, with an advisor and prover for reviewing changes.
- Providers: credentials that take effect only at approved endpoints, including inference.
- Gateways: the control plane for sandboxes, policies, and access.
- Kubernetes: deploy the gateway using Helm; the CNI must enforce NetworkPolicy.
- Extensibility: middleware, interceptors, and compute drivers.
- Tutorials: step-by-step policy and agent walkthroughs.
- Prerelease and development builds: try upcoming releases or the latest commit on the main branch.
V. gRPC API Testing
The gateway provides the gRPC reflection v1 protocol. After starting a local plaintext gateway, you can use grpcurl directly without checking out or providing proto files; the service list includes the public openshell.v1.OpenShell API. Reflection does not broadcast the gateway's internal compute-driver, credential-driver, interceptor, or middleware services. For a TLS gateway, remove -plaintext and provide the CA and client certificate options required by the deployment.
VI. Skills for Coding Agents
Public OpenShell skills can be installed for your coding agent to use. These skills teach agents to drive the OpenShell CLI, write sandbox policies, and debug gateways and inference routing. They are located in the skills/ directory and can be used without checking out the OpenShell source code.
VII. SDK and Versions
The SDK is used to connect applications to the OpenShell gateway, but does not install the CLI. The SDK and gateway should use the same OpenShell version whenever possible.
VIII. Community and Feedback Channels
- Questions and discussions: GitHub Discussions
- Bug reports and feature requests: GitHub Issues, and use the issue template
- Security vulnerabilities: follow SECURITY.md, do not open a GitHub Issue
- Roadmap: OpenShell Roadmap and RFC board
- Cloud trial: Brev Launchable
IX. Development Approach and Telemetry
OpenShell is built using an "agent-first" approach: it is developed using the same agent-driven workflows that it enables. CONTRIBUTING.md provides development environment setup and contribution processes, and AGENTS.md provides repository coding standards. OpenShell collects anonymous telemetry data, limited to operational categories and counts, to improve the project. It does not collect sandbox names, hostnames, file paths, prompts, credentials, provider or model names, or user content. It can be disabled by setting OPENSHELL_TELEMETRY_ENABLED=false on the gateway, or by setting server.telemetryEnabled=false in a Helm installation; telemetry can also be compiled out entirely. See Telemetry and the community telemetry report for details.
X. Statements and Disclaimers
This software automatically retrieves, accesses, or interacts with external materials. Retrieved materials are not distributed with this software and are subject only to their own separate terms, conditions, and licenses. Users are responsible for finding, reviewing, and complying with all applicable terms, conditions, and licenses, and for verifying the safety, integrity, and suitability of retrieved materials for their specific use cases. This software is provided "AS IS", without warranties of any kind. The authors make no representations or warranties regarding retrieved materials and assume no liability for any loss, damage, liability, or legal consequences arising from the use of or inability to use this software or retrieved materials. Use this software and retrieved materials at your own risk. The project is licensed under the Apache License 2.0.
(Note: The above is a product introduction compiled from the provided materials; features, fees, prices, or usage effects not mentioned in the materials are not provided at this time.)
