Execution substrate vs sandbox: key differences explained

Your coding agent executes generated code inside a microVM, and the isolation holds. Then a user comes back later and the agent has lost the repository it cloned. A second agent needs the first agent's build artifacts and has no path to them. Your compliance lead asks for a static outbound IP. Every sandbox is leaving from a different one.

In each case the sandbox did its one job and contained untrusted code. The failure sits in the layer around it. That layer places the sandbox on hardware, suspends it when idle, stores its state, and routes its traffic. This surrounding layer is the execution substrate.

The term is still settling. The Cloud Native Computing Foundation (CNCF) calls its agent-substrate work a "standalone project." It sits outside any Kubernetes SIG. The definitions here come from production systems rather than a ratified standard.

TLDR

• Sandbox: One isolation boundary around one workload. It contains untrusted code and nothing else.
• Execution substrate: The platform layer that places, suspends, resumes, stores state for, and networks many sandboxes together.
• Placement and scheduling: The substrate's control plane decides where each sandbox runs and whether it schedules individual requests or full agent sessions.
• State persistence: Sandboxes lose local state on deletion. A substrate adds snapshot lifecycles, block volumes, and shared filesystems that outlive any single sandbox.
• Networking: Egress IPs, domain allowlists, and TLS-terminated preview URLs all belong to the substrate, not the sandbox.
• Isolation selection: The substrate chooses and operates the isolation backend. For AI-generated code, microVM isolation reduces the host attack surface.
• Billing model: A substrate separates compute charges from state-retention costs. Standby sandboxes can carry storage charges without paying for idle CPU.

Sandbox vs execution substrate at a glance

The table below maps each responsibility to the layer that owns it. Use it to spot which gaps a bare sandbox leaves open in your current stack.

What is an execution substrate?

An execution substrate is the platform layer that operates many sandboxes at once. It decides placement, suspension, state, and traffic. The word predates agents. Hindman et al. described a "low-level substrate" in 2009. It "provides isolation and efficient resource sharing across frameworks running on the same cluster." The agent-era version adds lifecycle. In that model, agents execute in secure worker pods for short bursts. They suspend when idle and resume later on any available worker.

AWS Lambda is a production example. Each function runs inside one Firecracker microVM, and that microVM is the sandbox. Around it, Lambda operates a fleet of bare-metal workers. Lambda's placement service assigns a slot and "typically takes less than 20ms." That keeps scheduling overhead small enough for agents that make frequent, short tool calls. A MicroManager on every worker "keeps a small pool of pre-booted MicroVMs."

SnapStart adds a snapshot layer that caches microVM memory and disk state across three cache tiers. Only the Firecracker process is the sandbox. The fleet, the placement service, the pre-boot pool, and the snapshot cache are substrate.

What is a sandbox?

A sandbox is one isolation boundary around one untrusted workload. Sandboxing isolates program execution in a restricted environment to reduce the risk of compromise. The boundary can be a hardware virtual machine, a user-space kernel, a shared-kernel container, or a WebAssembly module. That choice decides how much of the host an escape can reach.

Firecracker shows how narrow a sandbox's job is. Each microVM holds a single sandbox for a single customer function. It also contains a minimized Linux kernel and userland and a shim control process. One Firecracker process runs one and only one microVM, per its design document. One process, one boundary, one workload, and a device model of six emulated devices. The small device model reduces the attack surface exposed to untrusted workloads.

A sandbox executes what it's handed. It has no knowledge of where it runs or which IP its traffic leaves from.

Who decides where the workload runs?

The control plane places each sandbox. A sandbox is placed, and it never places itself or its neighbors. The control plane owns lifecycle and placement of agents onto execution workers.

Lambda splits this across two services. Lambda routes those requests through a stateful router called the Worker Manager. This keeps routing latency out of the user-visible path. A separate Placement service optimizes slot placement for a single function across the worker fleet. That matters for agents making dozens of tool calls per session.

The scheduling unit is changing too. In agent runtimes, the scheduled unit has moved from the individual request to the agent session. Session-level placement decides where a PR review agent lands. One worker already holds the repository state. Another pulls it cold.

Ask whether a platform schedules requests or sessions. Also ask whether a suspended session can resume on any worker. A platform that pins sessions to one host can't drain or scale that host.

What happens when the agent goes idle?

A sandbox has one lifecycle, from create to run to delete. A substrate runs a state machine, moving from active to standby and back. Archived and deleted are terminal states. Snapshotting drives these state transitions.

A Firecracker snapshot consists of a guest memory file and a microVM state file. The operator also manages any disk files. A Lambda snapshot captures the memory state of running processes, disk state, network connections, and file descriptors.

Not everything survives restore. Firecracker documents that network and vsock packet loss is expected across a resume.

Snapshot restores must preserve uniqueness. Use "a strong mechanism" to "guarantee that unique things stay unique across snapshot restores." Otherwise, "resuming execution from the same state more than once" is considered insecure. AWS Lambda SnapStart documents the same hazard and recommends post-restore handling of cryptographic state.

Handling both hazards falls outside the microVM. It belongs to the system that decides when to snapshot and stores the memory file. That system also fixes the clock on resume.

Restore speed also depends on the substrate. In FaaSnap's measurements, page-fault handling on a baseline Firecracker restore totals 120ms against 12ms for a warm VM. The measured resume cost comes from page faults. Blaxel puts that whole loop in the substrate. Sandboxes return to standby after 15 seconds of network inactivity. T

hey resume in under 25ms with filesystem, memory, and running processes intact, per Blaxel's standby behavior docs. For a coding agent, the developer returns from lunch to the working tree and memory, with the running dev server still in place. There is no need to wait for a rebuild.

Where does agent state live between sessions?

Whatever the agent wrote to local disk is gone when the microVM is deleted. Standby snapshots preserve state only while the sandbox itself exists. A substrate adds storage that outlives any single sandbox, in two shapes with opposite strengths. Block storage gives low latency on an individual workload. Filesystem storage handles "sharing data with multiple workloads simultaneously."

The hyperscaler primitives follow the same split. Amazon Elastic Block Store (EBS) attaches a volume to one instance by default. Multi-Attach raises that ceiling to 16 Nitro instances for io1 and io2 volumes in one Availability Zone.

Amazon Elastic File System (EFS), by contrast, mounts concurrently on thousands of instances. The gap between 16 instances and thousands means multi-agent systems need both volumes and a filesystem layer. AWS Bedrock AgentCore follows the pattern. Multiple agents collaborate through a shared session directory instead of API handoffs.

Blaxel keeps the two shapes separate as well. Volumes use "block storage and can only be accessed by attaching them to a running sandbox." A coding agent's working tree belongs on a Volume when it must outlast the sandbox. Agent Drive, currently in private preview, is a distributed filesystem. It provides "concurrent read-write access (RWX) from multiple sandboxes simultaneously." Use it for passing artifacts and context between agents. Decide by asking whether more than one sandbox reads the data at the same time.

Who controls the network edge?

A sandbox exposes a port. How traffic reaches it, and what identity it leaves under, belongs to the layer above. By default, Google Cloud Run uses an IP address pool whose addresses can change. A static outbound IP requires routing egress through Cloud network address translation (NAT). On AWS, a NAT gateway takes an Elastic IP at creation. Elastic IPs are stable identifiers for cloud-based resources. They help when configuring "external services, such as DNS records or firewall rules."

A data analysis agent querying a customer's database needs an allowlist entry at the NAT layer, never at the sandbox. Domain filtering lives at the same level. AWS Network Firewall applies domain-name allow and deny lists. It inspects the HTTP host header and the Transport Layer Security (TLS) Server Name Indication (SNI) field. Deny all non-approved outbound destinations by default, per OWASP outbound allowlists guidance. Allowlist only what the agent needs. Neither the allowlist nor the inspection can run inside the sandbox it constrains.

The substrate also controls inbound traffic. Cloud Run generates deterministic HTTPS URLs and terminates TLS before traffic reaches the service. A coding agent that renders a live preview depends on a URL and certificate the substrate issues. Before choosing a platform, list what your agents must reach outbound. Then list who must reach them inbound. Each item on that list is either a substrate feature or a workaround you'll build.

Who chooses the isolation technology?

The substrate picks the isolation backend and operates the host side of it. For trusted first-party code, shared-kernel containers remain the standard and the right call. For code a large language model (LLM) wrote a second ago, the calculus changes. A shared kernel produces a larger inter-object attack surface than hypervisors do. Assume agent-written workloads are malicious and sandbox them, per Kubernetes multi-tenancy guidance.

Host syscall counts quantify the attack surface. Host syscall exposure varies by isolation layer. Standard Linux containers allow roughly 306, gVisor without host networking 53, and Firecracker 36. Filtering a kernel interface and replacing it are different jobs. The comparison shows the gap between them.

Veracode's 2025 report found that 45% of AI code generation tasks introduced a known security flaw. Nearly half is a rate you plan around, so treat agent output as untrusted by default.

Because it intercepts syscalls in user space, gVisor narrows the surface without a hardware boundary. A microVM moves the boundary into the hypervisor. WebAssembly relies on software fault isolation and capability-based WASI.

It runs client-side in a browser sandbox rather than cloud infrastructure. This makes it a moderate fit for untrusted code. A hardware boundary moves the security-critical interface off the operating system boundary. It moves that interface onto hardware plus comparatively simpler software.

Who pays for idle time?

With a bare sandbox, billing is binary: it exists and costs money, or deletion loses everything. A substrate can separate compute charges from state retention. Lambda shows both the promise and the limits. On-demand Lambda charges nothing between invocations. Keeping a function warm through Provisioned Concurrency bills continuously while idle. Billing is rounded to the nearest five minutes.

For intermittent agent workloads, short bursts can therefore incur more billed warm time than they use. SnapStart bills separately for snapshot cache storage per GB-second and for each GB restored. It also deletes snapshots after 14 days without an invocation, per Lambda pricing.

A low-traffic agent session pays for cache storage and then loses the state anyway. Blaxel bills standby as snapshot storage rather than as compute. Suspended time doesn't count toward active CPU, so a standby sandbox carries no compute charge. For data that must be re-attachable to a different sandbox, use Volumes.

Keep-warm strategies waste memory across a fleet. In an Azure Functions trace, 82% of functions were invoked less than once per minute. Keeping those apps warm would consume 40% of service memory. With Firecracker and Knative autoscaling, committed memory averaged 16 times more than active requests used. If your review agents fire only a few times an hour, keep-warm bills for mostly unused hardware.

Pull your invocation histogram before choosing a model. If most sessions idle for hours between bursts, standby economics dominate.

Decision matrix: sandbox-only or full substrate?

Build a substrate capability yourself only when you can't buy it. This is CNCF's own capabilities test for platform teams. Each additional level of platform maturity brings greater requirements for funding and people's time.

How to use the matrix

Read down the left column and count how many rows describe your workload. The isolation and networking rows are disqualifying on their own. A bare sandbox can provide workload isolation, but a substrate is required to select, place, and operate that isolation consistently across a multi-tenant fleet. Network-edge controls are substrate capabilities. The rest are additive.

If your workload matches only the first row, a bare sandbox is enough for now. If several rows apply, you are choosing between buying a substrate and staffing one.

Where Blaxel fits: the execution substrate for autonomous agents

Blaxel is a perpetual sandbox platform and the infrastructure foundation for autonomous agents. It is organized around the substrate pattern above. The sandbox unit is a microVM with full access to its file system and processes. Its logs are also fully accessible. Compute includes Sandboxes and Batch Jobs.

Volumes and Agent Drive make up the storage layer. For networking, the platform provides custom domains for preview URLs, plus domain filtering and proxy-based secrets injection (both public preview). Dedicated egress gateways are in private preview.

Coding agents fit the pattern most directly. The sandbox holds the cloned repository and drops to standby when the developer stops typing. It resumes with the working tree and running processes in place. PR review agents and data analysis agents use the same standby-and-resume lifecycle.

Sandbox creation from a template takes roughly 200–600ms. An agent that needs a fresh environment mid-task gets one inside a single tool call. Start free and run your first sandbox.

Frequently asked questions

What is an execution substrate in AI agent infrastructure?

An execution substrate is the platform layer that operates many sandboxes at once. It handles placement, suspension, state persistence, storage, and networking across a fleet of workers. The term originates from distributed systems research in 2009 and now applies to agent runtimes where workloads suspend when idle and resume on any available worker. AWS Lambda is a production example: the Firecracker microVM is the sandbox, and the fleet, placement service, snapshot cache, and pre-boot pool are the substrate.

Can I use a sandbox without a full execution substrate?

Yes. If your agent runs trusted first-party code, executes statelessly, and needs no session persistence or static egress IPs, a single sandbox or managed function is enough. The decision changes when sessions must resume after hours of idle time, multiple agents share artifacts, or AI-generated code runs for multiple tenants. In those cases, you need substrate capabilities for snapshot lifecycles, shared filesystems, and network-edge controls that a bare sandbox cannot provide on its own.

Why does agent-generated code need microVM isolation instead of containers?

Standard Linux containers expose roughly 306 host syscalls. Each exposed syscall is a potential attack vector for untrusted code. MicroVM isolation reduces that surface to around 36 syscalls by moving the security boundary into the hypervisor. Veracode's 2025 report found that 45% of AI code generation tasks introduced a known security flaw. At that rate, treating agent output as untrusted is a baseline requirement, and microVM isolation provides the narrowest host interface available in production today.

How does standby billing differ from keep-warm billing?

Keep-warm strategies reserve compute capacity continuously. In measured traces, 82% of serverless functions were invoked less than once per minute, yet keeping them warm consumed 40% of fleet memory. Standby billing separates state-retention costs from compute charges. A suspended sandbox stores its memory and filesystem snapshot without paying for active CPU time. When the agent resumes, compute charges restart. This model fits intermittent agent workloads where sessions idle for hours between short bursts of activity.