Red Hat previews Agent Sandbox for stateful AI-agent workloads on OpenShift

Red Hat has documented a Technology Preview of Red Hat build of Agent Sandbox, a Kubernetes-native control layer for long-lived AI-agent runtimes and development environments on OpenShift. The feature appears in the OpenShift Sandboxed Containers 1.12 documentation and installs as a separate Operator from OperatorHub.

The distinction matters for platform teams: this is not another stateless inference endpoint. Red Hat describes Agent Sandbox as a system for singleton workloads that need a stable identity and persistent state, with lifecycle controls that replace hand-built combinations of StatefulSets, Services and persistent-volume claims.

A sandbox lifecycle API

The Agent Sandbox overview exposes a Sandbox custom resource for creating, retaining or deleting environments and scheduling shutdown times. It also documents hibernation for idle sandboxes, preserving state so a session can resume without rebuilding its environment.

Three extension APIs address repeatable and latency-sensitive provisioning. SandboxTemplate stores a reusable pod definition, SandboxWarmPool keeps a configured number of pods ready, and SandboxClaim allocates one of those prewarmed environments. Red Hat says the warm-pool path can avoid image-pull and virtual-machine startup delays, reducing allocation time to milliseconds.

Networking is centralized through a sandbox router. Instead of creating an external route per environment, clients send the target sandbox, namespace and port in request headers to one OpenShift route. The router resolves the sandbox service over cluster DNS and forwards HTTP traffic to the workload.

Isolation is optional — and costs something

Agent Sandbox can run with the standard container runtime or integrate with OpenShift sandboxed containers. In the latter configuration, each workload runs inside a lightweight virtual machine with its own kernel, creating a stronger boundary for multitenant environments and execution of untrusted or LLM-generated code. Red Hat also warns that this mode adds VM startup latency and resource cost; trusted workloads can stay on the default runtime.

The installation guide requires OpenShift 4.19 or later and cluster-admin access. Hardware-level isolation additionally requires the OpenShift sandboxed containers Operator and an appropriate Kata runtime. The compatibility table lists bare metal, Azure, Azure Red Hat OpenShift, AWS and Google Cloud configurations, with RHEL CoreOS worker nodes required for the sandboxed-container path.

The production boundary

The important qualification is support status. Red Hat labels Agent Sandbox a Technology Preview, says it is not covered by production service-level agreements and does not recommend production use. That makes this an evaluation target rather than a supported runtime commitment.

Still, the design makes Red Hat’s platform direction concrete: agent execution gets its own lifecycle primitive, while warm capacity, persistent state, shared routing and optional VM isolation become cluster services. Platform teams testing agent workloads can now evaluate that model directly, but should keep the preview boundary explicit in capacity, security and rollout decisions.