Red Hat Build of Agent Sandbox

Complete modules 01–05 before attempting this module. The kata node pool from module 02 and the OpenShift Sandboxed Containers operator from module 03 must be installed and healthy.

Value Proposition

Red Hat build of Agent Sandbox is a Kubernetes-native API layer that abstracts sandboxing technology from developers. Platform admins choose the runtime — including Kata Containers for VM-level isolation — and developers simply request a sandbox via a SandboxClaim. They never interact with pods, PVCs, or runtime classes directly.

Without OpenShift Sandboxed Containers, Agent Sandbox delivers lifecycle management and fast provisioning. With Kata Containers enabled in the SandboxTemplate, every sandbox runs in a dedicated KVM guest VM. The same threat model from module 05 applies: a malicious AI agent executing a tool call, an injected build script, a rogue notebook — all are contained inside the VM. The host kernel and adjacent tenants are unreachable.

Learning Objectives

By the end of this module you will be able to:

Describe the four Agent Sandbox CRDs and how they relate to each other
Create a SandboxTemplate that provisions kata-backed sandboxes
Create a SandboxWarmPool for near-instant sandbox allocation
Request a sandbox via SandboxClaim and execute workloads inside it
Demonstrate that the kata VM boundary contains agent-level attack patterns
Explain the difference between Agent Sandbox with and without OpenShift Sandboxed Containers

Section 1 — Agent Sandbox Architecture

Agent Sandbox introduces four CRDs:

CRD Purpose

CRD	Purpose
`SandboxTemplate`	Reusable blueprint: container image, runtime class, environment, networking policy. Platform admins own this.
`SandboxWarmPool`	Maintains N pre-provisioned sandboxes from a template. Replenishes automatically when a sandbox is claimed.
`SandboxClaim`	A request for a sandbox from a warm pool. Supports TTL and auto-shutdown. Developers and agents create these.
`Sandbox`	The running instance: a pod with stable identity, optional PVC and service. Managed by the controller.

SandboxTemplate

Reusable blueprint: container image, runtime class, environment, networking policy. Platform admins own this.

SandboxWarmPool

Maintains N pre-provisioned sandboxes from a template. Replenishes automatically when a sandbox is claimed.

SandboxClaim

A request for a sandbox from a warm pool. Supports TTL and auto-shutdown. Developers and agents create these.

Sandbox

The running instance: a pod with stable identity, optional PVC and service. Managed by the controller.

Lifecycle Flow

SandboxTemplate ──► SandboxWarmPool (maintains N ready Sandboxes)
                           │
              SandboxClaim ◄─ developer/agent requests sandbox
                           │
              WarmPool releases Sandbox → replenishes pool
                           │
              SandboxClaim now references the running Sandbox

The warm pool eliminates cold-start latency. A SandboxClaim acquires a pre-warmed VM in milliseconds rather than waiting for a new kata pod to start.

Section 2 — Install the Operator

Create the operator namespace:
```
oc new-project agent-sandbox-operator
```

Create an OperatorGroup scoped to all namespaces:

oc apply -f - <<'EOF'
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: agent-sandbox-operator-group
  namespace: agent-sandbox-operator
spec: {}
EOF

Create the Subscription:

oc apply -f - <<'EOF'
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: agent-sandbox-operator
  namespace: agent-sandbox-operator
spec:
  channel: preview-0.9
  name: agent-sandbox-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
EOF

Wait for the CSV to reach Succeeded:

oc wait csv/agent-sandbox-operator.v0.9.0 \
  -n agent-sandbox-operator \
  --for=jsonpath='{.status.phase}'=Succeeded \
  --timeout=300s

Confirm the CRDs are registered:
```
oc get crd | grep sandbox
```
Expected output includes sandboxtemplates, sandboxwarmpools, sandboxclaims, and sandboxes.

Section 3 — Create a kata-backed SandboxTemplate

Create a namespace for the agent workloads:
```
oc new-project agent-sandbox
```

Create a SandboxTemplate that pins the runtime class to kata:

oc apply -f - <<'EOF'
apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxTemplate
metadata:
  name: kata-agent-executor
  namespace: agent-sandbox
spec:
  podTemplate:
    spec:
      runtimeClassName: kata
      tolerations:
      - key: kata
        value: "true"
        effect: NoSchedule
      containers:
      - name: executor
        image: registry.access.redhat.com/ubi9/ubi-minimal
        command: ["sleep", "infinity"]
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
EOF

The runtimeClassName: kata field inside podTemplate.spec is the single control point for the platform admin. Developers requesting sandboxes from this template automatically get kata VM isolation — with no knowledge of the runtime class themselves.

Confirm the template is accepted:

oc get sandboxtemplate kata-agent-executor -n agent-sandbox

Section 4 — Create a SandboxWarmPool

Create a warm pool of three pre-provisioned kata sandboxes:

oc apply -f - <<'EOF'
apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxWarmPool
metadata:
  name: agent-pool
  namespace: agent-sandbox
spec:
  replicas: 3
  sandboxTemplateRef:
    name: kata-agent-executor
EOF

Watch the warm pool provision the sandboxes:
```
oc get sandboxwarmpool agent-pool -n agent-sandbox -w
```
Wait until the ready count matches replicas (3). Each ready sandbox is a running kata pod — a KVM guest VM waiting to be claimed. Press Ctrl+C when the pool is full.

Confirm three sandboxes are running under the kata runtime:

oc get sandboxes -n agent-sandbox \
  -o custom-columns='NAME:.metadata.name,PHASE:.status.phase,NODE:.status.nodeName'

Section 5 — Request and Use a Sandbox

Simulate an AI Agent Requesting a Sandbox

Create a SandboxClaim with a 30-minute TTL — as an AI agent orchestrator would at the start of a session:

oc apply -f - <<'EOF'
apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxClaim
metadata:
  name: agent-session-01
  namespace: agent-sandbox
spec:
  warmPoolRef:
    name: agent-pool
  lifecycle:
    ttlSecondsAfterFinished: 1800
EOF

Wait for the claim to be fulfilled:

oc wait sandboxclaim agent-session-01 -n agent-sandbox \
  --for=condition=Ready --timeout=60s

Confirm the warm pool immediately replenished:
```
oc get sandboxwarmpool agent-pool -n agent-sandbox
```
The pool is already back to 3 ready sandboxes. The next claim is fulfilled in milliseconds from the pre-warmed inventory.

Identify the sandbox backing this claim:

SANDBOX_NAME=$(oc get sandboxclaim agent-session-01 -n agent-sandbox \
  -o jsonpath='{.status.sandbox.name}')
echo "Sandbox: $SANDBOX_NAME"

Capture the node the sandbox is running on:

KATA_NODE=$(oc get sandbox $SANDBOX_NAME -n agent-sandbox \
  -o jsonpath='{.status.nodeName}')
echo "Kata node: $KATA_NODE"

Section 6 — Security: Agent Tool Calls Inside the Kata Boundary

This section executes the same attack patterns from module 05 — this time from inside an Agent Sandbox claim. The kata VM boundary applies identically.

Scenario: Prompt Injection → Code Execution Attempt

The article’s threat model: a user sends a prompt that injects malicious instructions, the LLM generates a dangerous tool call, the agent executes it inside the sandbox. Without Kata Containers this breaks out to the host. With kata, it stays in the VM.

Attempt to write to the sysrq interface from inside the sandbox:

oc exec -n agent-sandbox $SANDBOX_NAME -- \
  sh -c 'echo h > /proc/sysrq-trigger && echo "sysrq write accepted" || echo "sysrq write blocked"'

Expected output: sysrq write blocked — Read-only file system. The default SandboxTemplate does not grant privileged: true, so the guest kernel denies the write at the filesystem level. The host node is not involved at all.

This is a stronger result than module 05, where privileged: true was explicitly set to simulate a worst-case build runner. In the default Agent Sandbox configuration, the sysrq interface is blocked by the unprivileged container policy before the kata VM boundary needs to act. Defense in depth: OS-level restriction plus VM-level isolation.

Check for the KVM hypervisor module from inside the sandbox:
```
oc exec -n agent-sandbox $SANDBOX_NAME -- \
  sh -c 'grep "^kvm " /proc/modules || echo "kvm: NOT VISIBLE — host kernel is isolated"'
```
NOT VISIBLE. The sandbox cannot enumerate or access the host kernel module space. A rootkit loader has no path to the hypervisor.
Attempt to access the host filesystem:
```
oc exec -n agent-sandbox $SANDBOX_NAME -- \
  sh -c 'ls /host 2>/dev/null || echo "host filesystem: NOT ACCESSIBLE"'
```
NOT ACCESSIBLE. The sandbox sees only the guest VM filesystem. Host credentials, tokens, and secrets are unreachable.

Comparison: What Happens Without kata

Attack pattern Agent Sandbox (runc) Agent Sandbox + OSC (kata)

Attack pattern	Agent Sandbox (runc)	Agent Sandbox + OSC (kata)
sysrq host reboot	Host node reboots, all pods evicted	Write blocked at OS level (unprivileged); host node `Ready`
KVM module enumeration	Host module namespace exposed	`NOT VISIBLE` — guest kernel only
Host filesystem access	Host paths accessible via `/proc/1/root`	Filesystem is guest VM root only
Adjacent tenant process scan	Tenant B’s PIDs visible in `/proc`	Separate guest VM PID namespace

sysrq host reboot

Host node reboots, all pods evicted

Write blocked at OS level (unprivileged); host node Ready

KVM module enumeration

Host module namespace exposed

NOT VISIBLE — guest kernel only

Host filesystem access

Host paths accessible via /proc/1/root

Filesystem is guest VM root only

Adjacent tenant process scan

Tenant B’s PIDs visible in /proc

Separate guest VM PID namespace

Section 7 — Verify Node Health and Clean Up

Confirm the kata node is healthy after all tool call simulations:
```
oc get nodes -l node-role.kubernetes.io/kata=
```
Both kata nodes show Ready. No host-level security event was triggered.

Confirm all warm pool sandboxes are still ready:

oc get sandboxwarmpool agent-pool -n agent-sandbox

Delete the sandbox claim (TTL would auto-expire it, but clean up manually here):
```
oc delete sandboxclaim agent-session-01 -n agent-sandbox
```

Delete the warm pool and namespace:

oc delete sandboxwarmpool agent-pool -n agent-sandbox
oc delete namespace agent-sandbox

Summary

What You Learned

Agent Sandbox decouples sandbox policy from developer workflow. Platform admins set runtimeClassName: kata inside podTemplate.spec of the SandboxTemplate once. Every SandboxClaim from that template automatically gets VM-level isolation — transparently.
Warm pools eliminate kata cold-start latency. Sandboxes are pre-provisioned VMs. A SandboxClaim acquires one in milliseconds. The pool replenishes immediately.
Defense in depth contains the agent threat model. In the default unprivileged SandboxTemplate, sysrq writes are blocked at the OS level (Read-only file system) before the kata VM boundary even acts. Kernel module enumeration, host filesystem access, and adjacent tenant process scans are contained by the guest VM. The host and other tenants are unreachable.
The security posture is additive. Agent Sandbox without kata gives lifecycle management. Agent Sandbox with kata gives lifecycle management plus hardware-enforced isolation. The two are composed by a single field in the SandboxTemplate.

Decision Tree: When to Recommend Agent Sandbox + kata

Does the platform execute AI agent tool calls, code interpreter requests, or LLM-generated shell commands?: Yes → Recommend Agent Sandbox with runtimeClassName: kata in the SandboxTemplate. The warm pool handles provisioning; the kata VM handles isolation.
Are multiple tenants (customers, teams, or users) sharing the same OpenShift cluster for AI workloads?: Yes → Mandate kata in the SandboxTemplate. Cross-tenant kernel namespace isolation (runc) can be bypassed by a kernel vulnerability. The kata VM boundary cannot.
Is sandbox provisioning latency a concern (interactive notebooks, real-time code execution)?: Yes → SandboxWarmPool is the answer. Pre-warmed kata VMs are ready in milliseconds. Cold-start kata latency is eliminated entirely.
Is this an internal-only, single-tenant, trusted-code workload?: Agent Sandbox without kata may be sufficient. You still gain lifecycle management, TTL, and stable identity — without the overhead of VM-per-sandbox.

Three Discovery Questions for a Customer Meeting

"When a developer or AI agent requests a code execution environment today, what is the isolation boundary — and who controls what runtime it uses?"

Agent Sandbox separates those concerns: the developer gets a SandboxClaim API, the platform admin controls the SandboxTemplate and the runtime class. Kata isolation is enforced centrally, not per-workload.

"How do you handle cold-start latency for isolated workloads like notebooks or code interpreters today?"

Warm pools are the differentiator. Pre-provisioned kata VMs ready in milliseconds is a significant operational improvement over spinning up a new VM per request.

"Have your security or compliance teams expressed concern about AI agents executing code in containers that share the host kernel?"

This is the emerging conversation in regulated industries. Agent Sandbox + OpenShift Sandboxed Containers gives platform teams a single API surface with hardware-enforced isolation — and this module provides empirical evidence of what that means at the kernel level.