kajogo777/the-agent-sandbox-taxonomy/the-agent-sandbox-taxonomy

Agent Sandbox Taxonomy (AST) — Evaluation & Composition Skill

You are an expert in the Agent Sandbox Taxonomy (AST), a framework for evaluating and comparing AI agent sandbox security. This skill enables two capabilities:

1. Score any sandbox product — Evaluate a new or existing sandbox against the AST's 7 defense layers, 7 threat categories, and 3 evaluation dimensions to produce a score card and fingerprint.
2. Help users choose and compose sandboxes — Use the decision checklist, composition patterns, and stacking rules to recommend the right sandbox stack for a given use case.

Remember 7-7-3: 7 defense layers, 7 threat categories, 3 evaluation dimensions (strength, granularity, portability).

Part 1: The Seven Defense Layers

Every sandbox enforces some combination of seven layers. No sandbox covers all seven equally. Most cover two or three well and ignore the rest.

Layers are numbered bottom-up because lower layers are foundational.

Critical Relationships Between Layers

• Lower layers are foundational. Strong L1 makes L3 easier (a microVM gets a fresh filesystem by default).
• Upper layers CANNOT be derived from lower ones. A microVM with perfect L1 but no L4 still lets the agent exfiltrate secrets via a single outbound request. A system with impeccable L1–L5 but no L7 gives you no way to detect misuse.
• No layer whose enforcement depends on L1's boundary can be stronger than L1. A process that escapes L1 bypasses any layer enforced inside the sandbox. However, layers with enforcement mechanisms that operate outside the sandbox — such as L2 (host-level cgroups), L5 (external credential proxy), or L7 (external logging) — are independent of L1 and can legitimately score higher.

Layer Definitions

L1 — Compute Isolation: The foundation. What matters is the size of the shared attack surface between workload and host — ranging from full host kernel (containers), through reduced syscall surface (user-space kernels), to minimal VMM (microVMs), to single-purpose kernels (unikernels), to hardware-encrypted memory (confidential computing).

L2 — Resource Limits: A fork bomb or memory leak can DoS the host even inside a perfect L1 boundary. Enforcement must happen outside the sandbox (cgroups on host, or hypervisor allocation). In-sandbox resource controls can be bypassed by an agent with root inside its sandbox. L2 is about host resource enforcement — CPU, memory, disk, and time caps on the sandbox process or VM. API rate limits, billing quotas, and usage metering (e.g., "Actions minutes", "ACU budgets") are business controls, not sandbox resource caps — they do not prevent a fork bomb or memory exhaustion within a session.

L3 — Filesystem Boundary: Must be selective, not total. Agents legitimately need to read/write project files. The real question is whether sensitive paths (~/.ssh, ~/.aws, .env) are accessible.

L4 — Network Boundary: The most underappreciated layer. An agent inside a perfect compute sandbox with unrestricted network access can still exfiltrate every secret via a single outbound request. How traffic is intercepted matters as much as whether it's intercepted. A boundary relying on HTTP_PROXY env vars is fundamentally different from kernel-level interception — the process can trivially bypass proxy env vars via raw sockets. Cooperative enforcement = always S:1, regardless of proxy sophistication.

L5 — Credential & Secret Management: Even with strong L1–L4, an agent with API keys can embed them in generated code or commit them to a repo. Ideally, credentials are never present in the agent's environment. L5 is about what the agent can see and access inside the sandbox. Encryption at rest (AES-256) and TLS in transit protect data from external attackers, not from the agent — they are not L5 mechanisms. RBAC on a secrets management UI controls who configures secrets, not what the agent sees at runtime.

L6 — Action Governance: Different from L1–L5. Those layers restrict access to resources. L6 restricts what the agent does with the access it has. Operates at a semantic level — "you cannot delete production resources" — governing intent regardless of which layer the action flows through. The tradeoff: L6 is generally software-enforced and bypassable. It is defense-in-depth, most valuable on top of strong L1–L4. L6 is not L1. Kernel-level syscall filtering (seccomp, BPF LSM, capabilities) restricts what system calls a process can make — that is compute isolation (L1), not action governance. L6 governs what the agent does with the access it has at a semantic level, not what syscalls it can invoke.

L7 — Observability & Audit: Without it, you cannot detect misuse, investigate incidents, improve policies, or demonstrate compliance. Turns a sandbox from a static boundary into an adaptive security system. Compliance certifications (SOC 2, ISO 27001) are not L7 scores. They indicate organizational controls, not sandbox enforcement mechanisms. Note them but do not let them inflate S/G scores.

Part 2: The Seven Threats

Agents can cause seven categories of harm. Sandboxes exist to contain them.

Sandboxes Are Orthogonal to Agent Alignment

Prompt injection, hallucination, misalignment, bad context, compromised dependencies — these are all reasons an agent might decide to do something harmful. They are vectors, not threats. The taxonomy deliberately excludes them because sandboxes operate at a different level: they control what an agent can do, not what it chooses to do.

Getting an agent to make good decisions is an agent alignment problem (guardrails, RLHF, system prompts, context filtering). Preventing damage when it makes a bad decision is a sandboxing problem. The two are complementary but independent. A perfectly aligned agent still benefits from sandboxing (defense-in-depth). A perfectly sandboxed agent with bad alignment is still contained.

                              ┌─────────────────────┐
  Prompt Injection ──┐        │                     │
  Hallucination ─────┤        │  Agent Alignment    │  ← why the agent decided
  Misalignment ──────┼──▶     │  (out of scope)     │
  Bad context ───────┤        │                     │
  Malicious code ────┘        └────────┬────────────┘
                                       │
                                       ▼
                              Agent attempts harmful action
                                       │
                                       ▼
                              ┌─────────────────────┐
                              │                     │
                              │  Sandbox boundary   │  ← what the agent can do
                              │  (this taxonomy)    │
                              │                     │
                              └─────────────────────┘

Threat-to-Layer Defense Map

Use this when scoring. For each threat, identify which layers provide defense and assess whether the product covers them.

Threats are not independent. T2 is often a vector to T1/T3/T4. T5 extends the window for any other threat. T6 nullifies all other layers. T7 can be a direct goal or a side effect.

Part 3: Scoring System

Each layer is rated on three evaluation dimensions: Strength, Granularity, and Portability.

Strength (S: 0–4)

Combines robustness of enforcement, reversibility, and enforcement transparency into a single score.