[Sandbox] OpenShell

### Project summary

OpenShell provides secure, policy-enforced sandboxed runtimes for autonomous AI agents.

### Project description

OpenShell is an open source platform for securely running autonomous AI agents in isolated, policy-enforced environments. It provides sandboxed runtimes across local containers, Kubernetes, virtual machines, and other compute backends, with consistent controls for filesystem access, network communication, process execution, credentials, and inference routing.

AI agents increasingly write and execute code, install software, access services, and interact with sensitive data. Traditional application security controls were not designed for workloads that make dynamic decisions and perform open-ended actions. OpenShell addresses this gap by placing enforceable security boundaries around agent workloads while preserving the flexibility agents need to accomplish useful work.

OpenShell combines a gateway control plane, pluggable compute and credential drivers, runtime supervision, structured security telemetry, and policy verification. Its backend-neutral architecture lets organizations apply common governance across developer laptops, clusters, and specialized infrastructure. By making secure agent execution portable and observable, OpenShell helps developers and operators adopt autonomous agents without relying on unrestricted host access or bespoke sandboxing systems.

### Project vs Reference Architecture/Implementation

- [x] This is a reusable open source project designed for broad adoption, not a reference architecture, reference implementation, or demonstration of patterns

### Org repo URL (provide if all repos under the org are in scope of the application)

N/A

### Project repo URL in scope of application

https://github.com/NVIDIA/OpenShell

### Additional repos in scope of the application

_No response_

### Website URL

https://github.com/NVIDIA/OpenShell

### Roadmap

https://github.com/orgs/NVIDIA/projects/233

### Roadmap context

OpenShell’s roadmap is centered on building a security-first, extensible platform for running autonomous agents. Development to date has emphasized refining security topologies: including isolation boundaries, policy enforcement, credential handling, network controls, and auditable sandbox behavior. Adopters have a strong foundation they can adapt to their own requirements.

From that foundation, the project is expanding support for varied compute environments, pluggable middleware and control plane governance hooks, and adopter-provided authentication and identity systems. These extension points allow organizations to integrate OpenShell into their existing infrastructure and address different security and operational use cases without the project prescribing a single architecture.

The next major area of investment is scaling sandbox density across compute drivers. OpenShell aims to support large numbers of short-lived, high-density sandbox workloads while maintaining consistent security properties across different execution environments.

The project will continue balancing this flexibility with practical day-zero capabilities: an individual developer should be able to install OpenShell, start a secure sandbox, and evaluate it without first assembling a production infrastructure stack. This creates a progression from straightforward local evaluation to customized, multi-user, and high-density production deployments. The linked project board reflects the current priorities and ongoing community work toward this direction.

### Contributing guide

https://github.com/NVIDIA/OpenShell/blob/main/CONTRIBUTING.md

### Code of Conduct (CoC)

https://github.com/NVIDIA/OpenShell/blob/main/CODE_OF_CONDUCT.md

### Adopters

_No response_

### Maintainers file

https://github.com/NVIDIA/OpenShell/blob/main/MAINTAINERS.md

### Security policy file

https://github.com/NVIDIA/OpenShell/blob/main/SECURITY.md

### Standard or specification?

N/A

### Business product or service to project separation

This project is unrelated to any product or service.

### Why CNCF?

The CNCF can provide OpenShell with a vendor-neutral home, transparent governance, and a community invested in the secure operation of cloud-native workloads. OpenShell sits at the intersection of workload isolation, policy, identity, networking, and observability. These are areas already represented by mature CNCF projects and standards.

CNCF participation would help OpenShell remain infrastructure-neutral, build interoperable integrations, broaden its maintainer and adopter communities, and mature its security, release, and project-health practices. In return, OpenShell can provide the ecosystem with an extensible security and runtime layer for autonomous agents. We see CNCF as the right environment for the project to earn long-term trust through open development and shared technical ownership.

### Benefit to the landscape

OpenShell benefits the landscape by providing a security and runtime layer designed specifically for autonomous agents. Existing cloud-native projects offer strong foundations for orchestration, isolation, identity, policy, networking, and observability, but adopters must still assemble these capabilities into a cohesive environment for agents that execute code, access credentials, call tools, and communicate with models and external services.

OpenShell builds on those foundations by combining sandbox lifecycle management with policy-enforced network access, credential handling, inference routing, and auditable runtime behavior. Its compute drivers, middleware, and interceptors allow adopters to integrate their preferred infrastructure without prescribing a single deployment model. This complements existing CNCF projects while giving the ecosystem a reusable platform for safely operating increasingly autonomous workloads.

### Cloud native 'fit'

OpenShell extends established cloud-native principles: automation, portability, composability, least privilege, and operational visibility to the emerging challenge of running autonomous agents safely at scale. The project is portable across compute environments through pluggable drivers, including Kubernetes and local container or virtualized runtimes. Its middleware, interceptors, authentication, and observability interfaces are designed to integrate with existing platform infrastructure rather than replace it.

### Cloud native 'integration'

OpenShell directly depends on or integrates with several CNCF projects. Kubernetes (and Agent Sandbox) is a supported compute backend, where OpenShell creates and manages sandbox workloads using Pods, Secrets, persistent storage, RuntimeClasses, RBAC, and NetworkPolicies. Helm charts provide installation and lifecycle management for Kubernetes deployments. OpenShell uses gRPC for its control-plane, compute-driver, middleware, and interceptor APIs; exports traces using OpenTelemetry and OTLP; and exposes Prometheus-compatible metrics.

OpenShell also provides optional integrations with cert-manager for certificate lifecycle management, Envoy Gateway and the Kubernetes Gateway API for external access, and SPIFFE/SPIRE for workload identity and short-lived token acquisition. Its declarative network policies are evaluated using Rego, complementing the policy model established by Open Policy Agent without requiring an external OPA service. These integrations allow OpenShell to assemble existing cloud-native capabilities into a secure execution platform for autonomous agents rather than recreating them.

### Cloud native overlap

K8s Agent Sandbox and kagent. Both provide capabilities to run sandboxes on Kubernetes. OpenShell also overlaps with OPA and Kyverno for declarative policy enforcement. KubeVirt and Confidential Containers for isolated workload execution.

### Similar projects

See previous for within CNCF. Outside of CNCF: E2B, Agent Substrate (we are working with them on joint customers), microsandbox, Daytona, Modal, and Blaxel.

### Landscape

No

### Insights

https://insights.linuxfoundation.org/project/openshell

### Trademark and accounts

- [x] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

### IP policy

- [x] If the project is accepted, I agree the project will follow the CNCF IP Policy

### Will the project require a license exception?

N/A - Project uses Apache 2.0

### Does the project utilize any dependencies with licenses not on the allowlist or an approved exception?

OpenShell uses the following dependencies under permissive licenses that are not currently on the CNCF allowlist and for which we did not identify an applicable approved exception:
- Unicode-3.0: icu_collections 2.2.0, icu_locale_core 2.2.0, icu_normalizer 2.2.0, icu_normalizer_data 2.2.0, icu_properties 2.2.0, icu_properties_data 2.2.0, icu_provider 2.2.0, litemap 0.8.2, potential_utf 0.1.5, tinystr 0.8.3, writeable 0.6.3, yoke 0.8.2 and 0.8.3, yoke-derive 0.8.2, zerofrom 0.1.7 and 0.1.8, zerofrom-derive 0.1.7, zerotrie 0.2.4, zerovec 0.11.6, and zerovec-derive 0.11.3.
- (MIT OR Apache-2.0) AND Unicode-3.0: unicode-ident 1.0.24.
- CC0-1.0: notify 8.2.0.
- CDLA-Permissive-2.0: webpki-root-certs 1.0.7 and webpki-roots 1.0.7.
- Public-domain dedication: pyelftools 0.32, used only as development/build tooling.
- Unlicense: robust-predicates 3.0.3, used transitively by Mermaid documentation lint tooling.
These are permissive or public-domain-style licenses; we have not identified restrictive, source-available, or copyleft licensing among these dependencies.

### Project "Domain Technical Review"

N/A

### Application contact email(s)

jomyers@nvidia.com

### Contributing or sponsoring entity signatory information

| Name | Address | Type (e.g., Delaware corporation) | Signatory name and title | Email address |
| ---- | ------- | --------------------------------- | ------------------------ | ------------- |
| NVIDIA Corporation | 2788 San Tomas Expressway, Santa Clara, CA 95051, USA | Delaware corporation | John Myers, Senior Director | jomyers@nvidia.com |

### CNCF contacts

_No response_

### Additional information

_No response_