Ephemeral Sandbox Architecture for AI Coding Agent Workloads

AI coding agents no longer just finish a line or suggest a function. Teams now hand them whole tasks: fix this issue, migrate this database, refactor this module, review this pull request, triage this incident. That shift, from completion to delegation, is why sandbox architecture matters now in a way it didn't two years ago, because an agent that can act on its own needs somewhere safe to act.

McKinsey's State of AI report puts the number at 62% of organizations at least experimenting with AI agents. Gartner projects that 90% of enterprise software engineers will use AI code assistants by 2028, up from under 14% in early 2024. Read those two numbers together, and the story is not "agents are coming," it's that the gap between "an engineer tries this on a laptop" and "this runs against production" has nearly closed." It's that the gap between "an engineer tries this on a laptop" and "this runs against production" has nearly closed. Agents now review pull requests, triage bugs pulled straight from customer tickets, kick off deployments, and in a growing number of shops, merge code without a human reading it first. Infrastructure has to catch up to that reality, and the piece of infrastructure doing the catching up is the sandbox.

What goes wrong when an agent runs without isolation

An agent given a shell and no boundary around it produces failure modes that aren't hypothetical. A hallucinated command deletes a directory it had no business touching. A poorly checked SQL statement drops a table because nothing stopped it from running against the real database. A billing limit gets torched overnight because a task looped on an API call nobody scoped down. None of this requires malice. It just requires an agent with real permissions and no fence around it.

Veracode's 2025 benchmark, which ran over 100 LLMs across 80 coding tasks, found that 45% of generated code samples, nearly half, failed security tests tied to the OWASP Top 10. That's not a rounding error, that's nearly half. Separate from the benchmark, there are documented cases of agents wiping local user files and, in at least one case, a production database.

Then there's the exposure that has nothing to do with the model's own reasoning: prompt injection. A browsing agent hits a webpage that contains hidden instructions buried in the page content, reads them as if they were legitimate input from its user, and acts on them. Security researcher Johann Rehberger demonstrated exactly this against Claude Computer Use running directly on a host machine: the agent downloaded and ran a binary, then connected out to an attacker's command-and-control server. No exploit of the model was needed, just a page it was told to read. And this isn't a lab curiosity. Prompt injection showed up in 73% of production AI deployments studied in 2025, according to published research from that year. That's the baseline threat environment agents operate in today, not an edge case worth a footnote.

What makes a sandbox ephemeral and why that property matters

An ephemeral code execution environment is a short-lived, isolated compute unit, spun up on demand to run untrusted or LLM-generated code, then torn down once the task finishes. The word "ephemeral" isn't marketing polish here, it's the actual security mechanism. Every session starts from a known-clean state. Nothing carries over from the last run, and nothing is left behind for an attacker to find and use to move sideways into something else.

Three properties do the actual work. Isolation keeps the sandbox's filesystem, network, and process space separate from the host and from every other sandbox running alongside it, so whatever the agent does can't reach production systems or other jobs in flight. A short lifecycle means the environment gets destroyed when the task ends rather than getting parked and reused for the next one, which caps the blast radius of any compromise to however long that one session ran. Per-session scope means every task gets its own sandbox, its own credentials, its own resource limits, with no shared state and no way for one session's access to leak into the next.

Compare that to a long-lived VM or a shared container pool. Those accumulate state over time: leftover files, cached credentials, an attack surface that grows with every session that touches them. Compromise one task on that shared box and every task that runs after it inherits the exposure. Ephemeral design refuses that accumulation by design, not by policy.

Isolation technologies: microVMs, gVisor containers, and shared-kernel container limitations

Not all isolation is equal, and the ranking determines how much damage a compromised agent can do: microVM, then gVisor, then shared-kernel container, then running code in the same process as everything else. That last option isn't a security boundary at all, it's just code running next to other code and hoping for the best. A plain container sits closer to that end of the spectrum than most people realize, because it shares the host kernel.

Firecracker microVMs give each sandbox its own dedicated kernel, filesystem, and network stack, with VM-level isolation but startup times far faster than a traditional full virtual machine. Vercel Sandbox uses this approach.

gVisor takes a different route: it intercepts system calls in a user-space kernel, which gets you strong isolation and fast startup without needing a full guest operating system underneath. Modal Sandboxes run on gVisor.

Shared-kernel containers are fast to spin up and familiar to any team that already runs a container platform in production, but they share the host's kernel directly. A kernel exploit inside the agent's code isn't contained to the agent; it's an exploit of the host. That's a fine tradeoff for trusted, known workloads. It is not a fine tradeoff for running code an LLM generated in response to an untrusted input, which is exactly the situation a coding agent lives in most of the day.

Credential scoping, session lifecycle, and blast radius control

An agent running on a shared, persistent VM holds whatever credentials it was given for the entire life of that VM. Compromise the machine, and the attacker doesn't get one task's worth of access, they get every credential that agent ever touched, going back as far as the VM has been alive. That's the quiet danger of persistent compute: the credential surface only grows.

A properly built ephemeral system does something structurally different. Credentials get minted fresh for each session, scoped tightly to what that session needs and nothing more, then revoked the moment the session ends. There's no long-lived secret sitting around waiting to be stolen, because nothing lives long enough to be worth stealing.

This is the principle of least privilege, applied to agents instead of humans. A code review agent has no business holding deployment permissions. A security scanner has no reason to carry write access. Per-session scoping enforces that boundary at the infrastructure layer, where it can't be skipped, forgotten, or overridden by a rushed engineer under deadline pressure, unlike a policy written in a wiki that depends on someone reading it.

The gap between what teams believe they've locked down and what's actually enforced is where incidents come from. Survey data puts the share of executives who report having complete visibility into agent permissions, tool usage, and data access patterns at only 21%. That means for roughly four out of five organizations, somebody in leadership can't fully account for what their agents are allowed to touch. Per-session credential minting doesn't just narrow that gap, it makes the question easier to answer in the first place, because the answer changes with every session instead of drifting further from reality over months.

Observability and audit trails as first-class requirements, not afterthoughts

Ephemeral sandboxes solve blast radius by disappearing. That's also what makes them dangerous to operate blind: if nobody designed for observability up front, the audit trail vanishes at the same moment the sandbox does. When a security team is asked what happened during an incident, the honest answer becomes "the evidence doesn't exist anymore," which is not an answer anyone wants to give a regulator.

What has to survive past the session's death is specific: every tool call the agent made, every diff it produced, every outbound network request, every credential it drew on, and a record of who or what triggered the session. Those are the facts a security review or an audit will ask for, and if the sandbox architecture didn't capture them while the session was alive, there's no retrieving them after.

Only about a fifth of executives say they have full visibility into what their agents are doing with the permissions and access they've been given, the same 21% figure cited earlier. That's a design failure, baked in from the moment the sandbox architecture was chosen, and no amount of after-the-fact log aggregation repairs a system that never captured the right events to begin with, not a monitoring gap that better dashboards fix after the fact. It's a design failure, baked in from the moment the sandbox architecture was chosen, and no amount of after-the-fact log aggregation repairs a system that never captured the right events to begin with.

One concrete pattern that works: run an outbound HTTP proxy inside the sandbox itself, so governance lives at the network layer instead of trusting the agent to police its own behavior. Data-loss-prevention filters catch a leaking secret before it leaves the box. Domain allowlists limit where the agent can even try to send a request. A kill switch cuts traffic instantly if something looks wrong. And every request that passes through gets logged in a trail that outlives the sandbox that made it, which is the entire point.

The 2026 platform landscape: nine environments

Picking a sandbox platform starts with a fairly clean split. Sandbox-as-a-service APIs suit agents that just need a filesystem, a runtime, and internet access to do their job. Deployment platforms suit agents that need VPC access, live databases, secrets management, and role-based access control. Most agents that start as an experiment end up living there by month two, once the task list grows past toy examples. Matching the platform tier to the actual workload determines operational cost and risk exposure, because an over-provisioned platform for a simple task just adds operational weight, and an under-provisioned one for a production workload leaves gaps exactly where the earlier sections describe them.

Before comparing any other feature, screen platforms on isolation strength first: microVM, then gVisor, then shared-kernel container, in that order of preference. Everything else, pricing, SDK ergonomics, integration surface, is secondary to whether the isolation model actually holds up against untrusted code.

Modal is the clearest example of the gVisor-based approach on the deployment-platform end of the spectrum. It runs a serverless, scale-to-zero model built specifically to absorb bursty, unpredictable agent workloads without a team paying for idle capacity between runs. Modal reports scaling to more than 50,000 concurrent sandboxes without needing to pre-provision that capacity ahead of time, and production users including Lovable and Quora run millions of untrusted code snippets through it daily. It carries SOC 2 Type II compliance, with HIPAA-compatible workloads available through a BAA on Enterprise plans. The SDK is code-first, with support for Python, Go, and JavaScript/TypeScript, and it skips YAML configuration. For state management across sessions, it offers memory snapshotting (currently in Alpha), along with filesystem snapshots and directory snapshots, both in Beta.

The broader 2026 landscape includes other environments built around the same underlying tradeoffs, sandbox-as-a-service simplicity against deployment-platform depth, microVM isolation against gVisor's user-space kernel approach, each suited to a different point on the delegation curve teams are climbing. The pattern holds regardless of which platform a team lands on: isolation strength first, credential scope second, and an audit trail that survives the sandbox's own destruction. Skipping any one of those three means the "ephemeral" in ephemeral sandbox architecture stops doing the job it's there to do.