Agent Sandboxing - Workshop on ARO

Welcome to the Agent Sandboxing workshop. In this hands-on session you will learn what the Red Hat build of Agent Sandbox is, see it in action running AI-generated code, demonstrate a real prompt injection attack, and then lock it down with OpenShift sandboxed containers (Kata Containers).

What is Agent Sandbox?

Red Hat build of Agent Sandbox provides developers with a programmable, Kubernetes-native API for running workloads in isolated environments, without requiring knowledge of the underlying sandboxing technology. Developers request a sandbox, and the platform delivers one. Whether OpenShift sandboxed containers (Kata Containers) or another runtime provides the underlying isolation, the platform administrator makes that choice — not the developer.

Despite its name, Agent Sandbox is not limited to AI agents. While it is a core component of the Red Hat agentic AI stack, it works equally well for any workload that benefits from sandboxed execution: development environments, notebook servers, code runners, build agents, or any application that requires complete isolation with instant provisioning.

Red Hat build of Agent Sandbox is available today on OpenShift Container Platform as a Technology Preview. General Availability is planned for November 2025.

For background reading, see:

Core advantages

Under the hood, Red Hat build of Agent Sandbox is a Kubernetes-native platform and a downstream build of the upstream kubernetes-sigs/agent-sandbox project. It delivers two core advantages:

Security with Kata Containers

Agent Sandbox supports the Kata Containers runtimeClass, which allows sandboxes to execute within lightweight virtual machines (VMs). This provides a hardware-assisted isolation boundary. A platform administrator enables this by setting a single field in the SandboxTemplate — developers and end users are not affected because the API they use remains the same.

Speed with the Warm Pool

By maintaining a pool of pre-prepared environments, the system enables near-instant allocation of sandboxes in milliseconds, effectively eliminating traditional provisioning delays. When a sandbox is claimed, the warm pool releases a ready one and immediately starts provisioning a replacement.

The Sandbox CRDs

Red Hat build of Agent Sandbox introduces four primary custom resource definitions (CRDs) that work together:

CRD interaction flow

  • Sandbox: The core resource — a single, stateful, long-running pod with stable identity. It can optionally include a service and a persistent volume claim (PVC).

  • SandboxTemplate: A reusable blueprint that defines the Sandbox specification: container images, environment settings, and optionally the runtimeClassName (e.g. kata).

  • SandboxWarmPool: Maintains a pool of pre-provisioned sandboxes based on a SandboxTemplate. Eliminates cold-start latency by keeping environments ready.

  • SandboxClaim: Requests a sandbox from a warm pool. Once fulfilled, the claim points to the released sandbox and the pool replenishes itself.

The interaction flow:

  1. The SandboxWarmPool references a SandboxTemplate to pre-provision sandboxes.

  2. The SandboxWarmPool pre-provisions one or multiple Sandbox instances ready to be claimed.

  3. A SandboxClaim is created (either manually or by an application).

  4. The claim requests a ready Sandbox from the SandboxWarmPool.

  5. The pool releases a Sandbox and refills itself with a new one.

  6. The SandboxClaim now references the released Sandbox.

When OpenShift sandboxed containers is enabled, the only change is that each sandbox pod runs inside a dedicated Kata VM:

CRD interaction flow with Kata

Structure of this workshop

This workshop walks you through four modules:

  1. The demo architecture — Understanding the components and how they fit together

  2. Running LLM-generated code — Trying the demo hands-on

  3. Prompt injection attack — Demonstrating why isolation matters

  4. Isolating with Kata Containers — Locking down the sandbox with OpenShift sandboxed containers