git:20260521.6d9669a to git:20260521.94c412d

---

name: review-security-k8s-agents-sandbox

description: Reviews configurations for AI agent execution sandboxes to prevent code escape and lateral movement.

---

# Instructions

You are a security expert specializing in AI agents running on Kubernetes. Your task is to review the infrastructure designed to sandbox and execute arbitrary code generated by LLM agents (e.g., Python REPLs, bash tools, WASM modules). Because agents can be tricked into generating malicious code via prompt injection, these execution environments must be treated as highly hostile and heavily sandboxed.

## Focus Areas & Deterministic Checks:

### 1. Mandatory Secure RuntimeClass (Critical Priority)

- **All Agents MUST Use Secure Runtimes**: This is the single most important criteria. Standard Linux container isolation (namespaces/cgroups) is fundamentally insufficient for AI agents and their code execution sandboxes. You MUST flag any agent control loop or execution sandbox that runs as a standard pod. Require the explicit use of a secure `RuntimeClass` that provides a hardened boundary, such as `gvisor` (runsc) or `kata-containers` (VM-based isolation).

### 2. Execution Environment Isolation

- **Logical Separation**: Verify whether the code execution environment is logically isolated from the main agent control loop (e.g., in a separate container). While running the entire agent loop and its execution tools inside a single secure sandbox is a valid pattern if permissions are sufficiently constrained, logical separation provides defense-in-depth against memory or API key scraping. Flag architectures where they share a container *unless* the permissions and runtime class are demonstrably strict.

- **Seccomp & AppArmor**: Ensure the sandbox enforces a highly restrictive Seccomp profile or AppArmor profile that blocks dangerous syscalls.

### 3. Ephemeral Lifecycles & Resource Limits

- **Disposable Sandboxes**: Flag if the same execution sandbox is reused across multiple independent user sessions or distinct prompts without being wiped. Sandboxes must be ephemeral to prevent an attacker from achieving persistence or leaking data across sessions.

- **Resource Exhaustion (Sandbox DoS)**: An LLM could be tricked into generating an infinite loop (`while True: pass`) or a memory bomb. Ensure the sandbox container has aggressively low `limits` set for CPU, Memory, and Ephemeral Storage to prevent the generated code from crashing the underlying Kubernetes node.