Red Hat’s OpenShift Sandboxed Containers Turn AI Agent Isolation Into a One-Line Pod Spec

On July 24, 2026, Red Hat detailed how OpenShift sandboxed containers, a hypervisor-backed isolation layer built on the open source Kata Containers project, now run on Microsoft Azure Red Hat OpenShift (ARO). The pitch, laid out by Red Hat’s Oren Kashi, is that any pod can get its own dedicated kernel inside a lightweight virtual machine, without a platform team having to build or operate the virtualization layer itself.

What makes the post notable is not that OpenShift sandboxed containers exist, but the reason Red Hat is now giving for adopting them: AI agents that generate and execute their own code are outgrowing the isolation guarantees a standard container provides.

What Sandboxed Containers Add on Top of Existing OpenShift Isolation

OpenShift and Red Hat Enterprise Linux already ship with layered container isolation: security context constraints (SCC) restrict what a pod can do, SELinux enforces mandatory access control, cgroups cap resource consumption, and many Linux capabilities are dropped by default. Kashi’s post is direct about this baseline: for most workloads, “these controls are sufficient.”

The gap sandboxed containers close is the kernel itself. In a standard setup, every container on a node shares the same host Linux kernel. Red Hat’s own analogy for the difference is a hostel versus a hotel: in a hostel, one guest’s bad behavior can affect the whole room, since everyone shares the same space. A sandboxed pod is closer to a hotel room with solid walls: you still share the building and the lobby, but what happens inside one room stays contained.

OpenShift sandboxed containers deliver that separation by running each pod inside its own lightweight VM, built on Kata Containers, an open source runtime stewarded by the Open Infrastructure Foundation and licensed under Apache 2.0. Kata Containers has been in development since 2017, when the project merged Intel Clear Containers with Hyper.sh’s RunV, and it now supports multiple hypervisors, including QEMU, Cloud Hypervisor, and Firecracker, while still presenting a standard OCI container interface and integrating with the Kubernetes Container Runtime Interface. If a workload inside a sandboxed pod is compromised, Red Hat says the blast radius stays inside that VM, which starts out with “almost no other software installed” for an attacker to move through, rather than spreading to the host or neighboring pods.

Why AI and Agent Workloads Are the New Reason to Turn It On

Red Hat’s traditional case for sandboxed containers covers untrusted code, unfamiliar libraries a team hasn’t fully audited, and privileged containers that need elevated capabilities on a shared kernel. The July 24 post adds a new category to that list: AI and agent workloads, which it calls “a growing case for sandboxing.” The reasoning Red Hat gives is specific. Agents can generate and execute unreviewed code at runtime, they follow non-deterministic execution paths instead of a fixed program flow, and they can be susceptible to prompt injection attacks that manipulate what code they decide to run in the first place.

None of those three properties describe a typical web application or database container. They describe a category of workload that did not really exist in production at scale until agentic AI tools started writing and running their own code inside a cluster. Naming that category explicitly, next to more familiar risks like untrusted code and privileged containers, is Red Hat treating agent isolation as a standard platform decision rather than a niche one.

Turning It On Is a Three-Step, Declarative Process

Azure Red Hat OpenShift is a fully managed OpenShift service that Microsoft and Red Hat jointly engineer, operate, and support, backed by a 99.95% service-level agreement. Enabling sandboxed containers on top of that managed base does not require standing up separate virtualization infrastructure. According to Red Hat’s post, it comes down to three steps:

1. Install the OpenShift sandboxed containers operator from OperatorHub inside the ARO cluster.
2. Create a KataConfig custom resource to configure the runtime. The operator uses it to configure CRI-O handlers and register the appropriate RuntimeClass, with the whole setup managed declaratively.
3. Add runtimeClassName to the pod spec of any workload that needs the stronger isolation.

From there, the operator provisions what Red Hat calls “peer pod” VMs through the Azure API and manages their lifecycle automatically. Nothing else in the deployment pipeline has to change: the isolation decision lives in a single field of the pod spec, and Red Hat’s own framing of the result is blunt: “That’s it!”

The Tradeoff Red Hat Is Upfront About

Sandboxed containers are not positioned as a new default. Every sandboxed pod runs in its own VM, which is real resource overhead compared to a standard container sharing the host kernel. Red Hat’s guidance is to reserve the feature “for workloads where stronger isolation is genuinely needed” rather than sandboxing a cluster’s workloads across the board. That leaves platform teams with a judgment call: which pods are running code that has not been fully reviewed, need elevated privileges, or are agents acting on their own, and which ones can stay on the existing SCC and SELinux baseline.

Why This Is Becoming a Platform Decision

Kata Containers itself is not a new project: it has been in development since 2017. What is new is a major platform vendor writing AI agent behavior directly into its isolation guidance, in the same breath as untrusted code and privileged containers, rather than treating it as a hypothetical edge case. As agents move from answering questions to generating and executing their own code inside a cluster, the decision about which pods get a dedicated kernel and which ones do not is turning into a standard line item on a platform rollout checklist, not an afterthought bolted on after an incident.