Capability 01 of 04 · Infrastructure
Agent Runtime & Sandboxing
Where and how AI agents execute code - isolation, security, and resource management.
5
maturity levels
15
practices
15
guides
L1 · Stage 01Assisted
Practices - what it looks like3 guides
- Agent in developer's IDEAt the earliest stage of AI-assisted development, the agent lives inside the developer's IDE - literally running as an extension or plugin within VS Code, Cursor, or JetBrains.guide→
- Agent runs in the developer's local environmentThe L1 default: the agent runs straight in the developer's environment, with the same filesystem, environment variables, network and credentials.guide→
- Agent access is coarse-grained (all or none)The L1 permission model, and it has only two settings: the agent can reach everything the developer can, or so little that it cannot do useful work.guide→
Criteria - what to measure
- 01Agents can run in the developer's local environment
- 02Agents have file-system and shell access in their run environment
- 03Developers are aware of the security implications of agents with full local access
- 04Agent access scope (file system, network) is understood even if not restricted
L2 · Stage 02Delegated
Practices - what it looks like3 guides
- Dedicated dev environmentsDedicated dev environments move agent execution off the developer's laptop and into isolated cloud-hosted workspaces.guide→
- Basic sandboxing (Docker, bubblewrap, eBPF directory confinement), and untrusted repositories opened with auto-run hooks disabled - repo-supplied agent, editor and git config (`core.fsmonitor`, GitSpawn) executes on folder open, before any install stepBasic Docker sandboxing wraps the agent's execution environment in a container that is isolated from the host system, and untrusted repositories are opened with auto-run hooks disabled, because repo-supplied agent, editor and git config executes on folder open.guide→
- Agent credentials scoped per project and short-lived, never a personal PAT or a shared long-lived key; spend caps and baseline alerts on every provider account - the first mass agent-run campaign found Claude, Cursor and Gemini tokens on 5,871 machines and burned $600k of credits through one dashboardAgents stop borrowing the developer's personal tokens and get their own short-lived per-project credentials, scoped to the one repository or bucket they need, with a spend cap and a baseline alert on every provider account.guide→
Criteria - what to measure
- 01Dedicated development environments exist for agent execution (separate from developer's primary workspace)
- 02Agents run inside a container, not directly on a developer machine
- 03Agent credentials are scoped per project (not a single org-wide key)
- 04Container images for agent environments are versioned and reproducible
- 05Credential rotation schedule exists for agent-scoped keys
- 06Agents never run on a developer's personal access token or a shared long-lived key
L3 · Stage 03Systematic
Practices - what it looks like3 guides
- Isolated agent environments (devbox model); credentials injected at run time from a vault or broker, never in prompts, files or eval sandboxes - an injected evaluation sandbox handed over production keys for several providersThe devbox model is the architectural pattern where each agent task gets its own isolated environment, created at task start and destroyed at task end.guide→
- Pre-warmed containers with codebasePre-warmed containers are agent environments that have been prepared in advance and are waiting in a ready state before any task is assigned to them.guide→
- Network isolation with egress denied by default and destinations allowlisted; the evaluation and test environment is inside the security boundary, not outside it; audit everything the agent WRITES, because escapes work by planting files that trusted host tools later readEgress is denied by default and destinations are allowlisted, so the agent reaches GitHub, registries and staging but not production - and the evaluation environment sits inside that boundary, not outside it.guide→
Criteria - what to measure
- 01Isolated agent environments (devbox model) prevent agents from accessing other projects
- 02Pre-warmed containers with codebase at HEAD and dependencies installed are available
- 03Network isolation prevents agents from reaching production systems
- 04Container warm pool size matches team's agent usage patterns
- 05Network isolation rules are tested and audited quarterly
- 06Credentials are injected at run time from a vault or broker, never stored in prompts, files or evaluation sandboxes
L4 · Stage 04GovernedMost teams aim here
Practices - what it looks like3 guides
- Ephemeral devboxes spin up fast enough that the agent never waits on the environmentThe 10-second devbox spin-up is the performance target that Stripe's agent infrastructure team set as the benchmark for production-grade agent environments.guide→
- Pre-loaded services, code, MCP toolsThe devbox starts with everything already running: dependent services, MCP servers, observability and test infrastructure, not just the codebase.guide→
- MicroVM, hardware-isolated execution as default (kubernetes-sigs agent-sandbox standard, AWS Lambda MicroVMs, Docker Cloud Sandboxes, Microsoft MXC); assume escape, including over DNS: workload identity per agent (SPIFFE, WIF, Google Agent Identity) with task-scoped tokens that expire in minutes + cryptographic run provenanceseccomp, AppArmor and eBPF decide what an agent process may do at the syscall level, whatever the agent or its container configuration believes.guide→
Criteria - what to measure
- 01Ephemeral devboxes spin up fast enough that an agent does not wait on the environment (single-digit seconds)
- 02Devboxes come pre-loaded with codebase, dependencies, and MCP tools
- 03Kernel-level policy enforcement restricts agent actions (syscall filtering, resource limits)
- 04Devbox spin-up P99 latency is under 30 seconds
- 05Firecracker microVMs or equivalent provide VM-level isolation with container-level startup speed
L5 · Stage 05Self-improving
Practices - what it looks like3 guides
- Agent fleet on dedicated compute, on a harness whose parts are replaceable - model adapter, tool registry, session log and the agent loop itself swappable without a rewriteAgent workloads move off laptops and CI runners onto a compute layer of their own, running a harness whose model adapter, tool registry, session log and agent loop can each be swapped without a rewrite.guide→
- Agent execution environments scale with demand, independently of CI runner capacityThe environments agents actually run in scale up and down with demand on their own signals, independently of CI runner capacity, without manual intervention.guide→
- Each agent = isolated machine or managed-agent-on-your-hardware (Devin Outposts model); sender-constrained tokens (DPoP, mTLS) and every session of one agent revocable in secondsThe fleet architecture choice at scale: one machine per agent for strong isolation, or shared machines with resource management for density and cost.guide→
Criteria - what to measure
- 01Dedicated compute infrastructure exists for agent fleet (not shared with developer workstations or production)
- 02Agent fleet auto-scales with load (agents scale up during business hours, scale down off-hours)
- 03Each agent runs in a fully isolated environment (one machine per agent, or equivalent resource isolation)
- 04Cost per agent-hour is tracked and optimized
- 05Fleet scaling responds to demand within 60 seconds
From the Field
Recent releases, projects and discussions the AI Radar classified into this capability.
release
alibaba/OpenSandbox
discovered
Zawwarsami16/Loki
release
e2b-dev/E2B
discovered
Confine an AI agent (Claude Code, Codex, oh-my-pi, ...) to one directory with a BPF-LSM program, and watch it live over eBPF.
release
trycua/cua
discovered
RL training environments with verifiable rewards for coding agents. Works with TRL, Unsloth, verl, OpenRLHF.
discovered
A general-purpose coding agent that runs inside an NVIDIA OpenShell sandbox, orchestrated by Deep Agents and powered by NVIDIA Nemotron. The agent write
discovered
Sub-millisecond VM sandboxes for AI agents via copy-on-write forking
Which level is your team at in Agent Runtime & Sandboxing?
The criteria above are what we check in a facilitated assessment. Run it yourself to place this capability, see which gates you have passed, and compare it against the other 3 in Infrastructure.
Start the assessment →