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 01Ad-hoc
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 environment"No isolation" describes the default state at L1: the AI agent runs directly in the developer's working environment with no boundary between the agent's execution context and the dguide→
- Agent access is coarse-grained (all or none)At the L1 maturity level, organizations face a binary permission model for AI agents: either the agent has full access to the developer's environment (everything), or access is soguide→
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 02Guided
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, cc-mini, bubblewrap wrappers)Basic Docker sandboxing wraps the agent's execution environment in a container that is isolated from the host system.guide→
- Agent credentials scoped per project; per-session spend capsProject-scoped agent credentials means that each project has its own dedicated set of credentials that agents use when working on that project, rather than agents inheriting the deguide→
Criteria - what to measure
- 01Dedicated development environments exist for agent execution (separate from developer's primary workspace)
- 02Basic sandboxing via Docker or equivalent containers is implemented
- 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
L3 · Stage 03Systematic
Practices - what it looks like3 guides
- Isolated agent environments (devbox model)The 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: agent can't see production; granular permission layers; harden agent config (~/.claude/settings.json is now a persistence target - Mini Shai-Hulud)Network isolation for agents means that the agent's execution environment has a constrained network configuration: it can reach the systems it needs for development work (GitHub, pguide→
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
L4 · Stage 04OptimizedMost teams aim here
Practices - what it looks like3 guides
- Ephemeral devboxes: 10s spin-up (Stripe benchmark)The 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 toolsA pre-loaded devbox is one where everything the agent needs to do its work is already running and available when the task starts - not just the codebase, but the dependent servicesguide→
- MicroVM, hardware-isolated execution as default (AWS Lambda MicroVMs / Firecracker; self-hosted E2B-Daytona in your VPC for data residency); classifier-gated sandboxing (Cursor 3.6 Run Mode); cryptographic run provenance (Dapr 1.18 Verifiable Execution)Kernel-level policy enforcement means using Linux security mechanisms - seccomp (secure computing mode), AppArmor, and eBPF (extended Berkeley Packet Filter) - to enforce what an aguide→
Criteria - what to measure
- 01Ephemeral devboxes spin up in under 10 seconds (Stripe benchmark)
- 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 05Autonomous
Practices - what it looks like3 guides
- Agent fleet on dedicated computeAn agent fleet on dedicated compute is the infrastructure pattern where AI agent workloads run on a distinct, purpose-built compute layer that is separate from developer laptops, Cguide→
- Auto-scaling: agents scale with loadAuto-scaling for agent fleets means that the compute infrastructure automatically adds or removes capacity in response to agent task load, without manual intervention.guide→
- Each agent = isolated machine (Cursor approach) or shared with smart resource management; full sovereign runtime as a real option (open-weight GLM-5.2 / Kimi K2.7-Code / DeepSeek V4 on-device via llama.cpp/vLLM - same capability, no vendor lock-in)At L5, organizations running agent fleets at scale face a fundamental architectural choice: does each agent get its own isolated machine (strong isolation, higher cost), or do multguide→
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 (Cursor approach: one machine per agent, or smart resource management)
- 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
python/sandbox/v0.1.8
discovered
release
@e2b/python-sdk@2.27.1
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.
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
release
sandbox-v0.1.1
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 →