Why AI Agents Need Isolated Runtime Environments
AI agents do more than just call cloud APIs; they execute shell commands, install packages, read files, and open direct network connections. In many cases, the agent acts on untrusted text fetched from the internet moments prior, making it essentially untrusted code carrying real credentials inside the infrastructure.
The OpenShell project, initiated by NVIDIA and accepted as a CNCF Sandbox project, provides a secure runtime for agents by isolating each agent within a dedicated container. The system relies on a trusted Supervisor outside the isolated environment to control permissions across four main axes defined in YAML files:
- File System: Restricting readable and writable paths using the Landlock technology in the Linux kernel, ensuring paths like /usr and /etc remain read-only.
- Process Management: Stripping the container of root privileges (non-root), dropping all kernel capabilities, and enforcing seccomp rules prior to startup.
- Network Control: Blocking external traffic by default while allowing specific domains based on the executable file name, host, concept, and port.
- Credentials: Hiding actual keys from the agent and replacing them with temporary round-trips handled exclusively by the Supervisor when connecting to authorized endpoints.
How Sandboxing Works in a Kubernetes Environment
At the Kubernetes level, OpenShell does not contain a custom scheduler; instead, it leverages the Agent Sandbox project from the SIG Apps working group. The OpenShell Gateway manages the environment lifecycle, while Agent Sandbox translates these requests into standard Kubernetes resources such as Pods, Services, PVCs, and NetworkPolicies.
The cycle begins by sending an environment creation request via the mTLS protocol to the Gateway, where the caller's identity is verified, policies are translated, and any insecure settings are discarded. Next, network policies are created to block the agent's external traffic and restrict internal communication exclusively to the Supervisor via port 5500. In the following step, the Supervisor must verify the security properties of the created Pod—such as ensuring no root privileges or host namespace sharing are used—before lifting scheduling constraints and launching the AI agent.
Comparison Between OpenShell and Agent Substrate
Another CNCF project offering a similar solution is Agent Substrate. Although both projects aim to isolate AI agents on Kubernetes, they differ fundamentally in infrastructure and use cases:
- Policy Granularity: OpenShell inspects every network request at a dedicated per-environment Supervisor, allowing, for example, reading issues from GitHub while preventing the creation of new issues using the same tool. In contrast, Substrate analyzes traffic at a shared Egress Gateway based on domain and host.
- Kubernetes Visibility: Each isolated environment in OpenShell is considered a set of resources that can be inspected and managed via native Kubernetes tools and RBAC. Conversely, Substrate maintains models and policies within its own PostgreSQL database away from the Kubernetes API server.
- Isolation Model and Scalability: Substrate requires strict isolation technologies like gVisor or Cloud Hypervisor to enable stopping and resuming idle containers for cost savings, while OpenShell offers standard Linux containers with the option to integrate stricter isolation technologies when needed.
Enhancing Security Using the Kyverno Engine
While OpenShell controls the internal behavior of the agent, policy engines like Kyverno ensure that Kubernetes resources themselves are not tampered with upon admission (Admission Control). Kyverno ensures the verification of image digest installations, defines maximum CPU and memory usage limits, and prevents the granting of elevated privileges to the Supervisors' RBAC roles.
Additionally, eBPF-based kernel monitoring tools, such as Runtime for Kyverno, enable the detection of unauthorized AI tools inside clusters, such as running CLI clients or connecting to external models without passing through approved security gateways.
What Practically Changes for Platform Engineers?
Enforcing security on AI applications is no longer limited to securing APIs alone; it extends to the actual runtime context of code inside containers. The OpenShell project gives platform teams the ability to precisely control Layer 7 (L7) for every operation executed by the agent, while integration with Kyverno ensures the preservation of governance standards and structural compliance within Kubernetes environments without operational complexity.