Serverless Functions as On-Demand Code Sandboxes

Serverless functions became the automatic answer to "how do I run this code on demand" because the economics fit an entire class of problem almost perfectly. The pitch is simple: provision nothing ahead of time, pay only for the compute actually consumed, and let the platform absorb traffic spikes without anyone pre-warming a fleet of servers. For workloads that arrive in bursts and disappear just as fast, that model removes a category of operational work that used to eat entire engineering teams.

The original use cases bear this out, and they are worth taking seriously on their own terms rather than treating them as a stepping stone to something more interesting. Webhook handlers, API glue code, event-driven pipelines, short-lived data transforms: these all share a shape. Each one is stateless. Each one behaves as a request comes in, something happens, a response goes out, and nothing needs to be remembered afterward. Function-as-a-service platforms were built around that shape, and for years that was close to the entire universe of "run this code when something happens."

What changed is the kind of code people need to run on demand. The Mastra roundup identifies this growth as the primary force behind the sandboxed-execution category expanding as fast as it has.

Faced with that shift, the engineer's instinct runs in a predictable direction: reach for Lambda or Cloudflare Workers, since they already handle scaling and billing, wrap the code call inside a function, and ship it. This piece examines what happens to the code that did not come from a trusted developer but from a model generating it on the fly. That is where the architecture underneath serverless functions starts to matter more than the economics on top of it.

What FaaS platforms were designed for, and the architectural assumptions baked into them

To understand why this becomes a problem, consider what a standard FaaS platform is actually built to do. It runs a stateless, shared-kernel execution model, tuned for workloads that are short-lived and shaped like a single request followed by a single response, and nothing about that is an accident. Every piece of the design, from billing granularity to how long a function is allowed to run, follows from that premise.

The shared-kernel part deserves a plain explanation, because it is the architectural fact the rest of this piece keeps returning to. Containers running on the same physical host share the underlying operating system kernel. That arrangement is efficient, and for trusted, short-lived functions it works fine, but it introduces a specific category of risk the moment the code running inside that container cannot be trusted. Blaxel's sandbox guide describes a container escape as an exploit that crosses the boundary from a workload into the host kernel itself, and that crossing is the central risk of running untrusted, AI-generated code on infrastructure built around a shared kernel. PandaStack's 2026 roundup lays out the isolation ladder: shared-kernel container at the bottom, user-space kernel such as gVisor in the middle, hardware-virtualized microVM at the top, with the shared-kernel container flagged as the weakest boundary available against code nobody vetted.

Statelessness is the second load-bearing assumption, and it is a deliberate design choice rather than a limitation anyone forgot to fix. For anything that needs to accumulate context across multiple steps, the same property turns into a wall.

Then there are the runtime ceilings. AWS Lambda imposes a 15-minute runtime ceiling for standard synchronous invocations, with asynchronous/ESM invocations on Lambda Managed Instances allowed up to 90 minutes as of September 2026. None of this makes Lambda poorly built. It makes Lambda built for a specific job, and that job does not resemble a multi-step agent task.

Cloudflare Workers take a different approach. That is a genuinely different isolation strategy from container-based FaaS, but it is scoped to a single language runtime and was never designed for arbitrary operating-system-level code execution. It solves a narrower problem than the one agent workloads present.

None of these constraints are flaws in isolation. They are the direct, sensible consequences of designing for stateless, short-lived, trusted request/response code. The shift happens when the workload stops looking like that, and the next section walks through it.

Where the FaaS Model Breaks

AI agent workloads do not strain one assumption behind FaaS. They break three of them at the same time: the code an agent runs is untrusted by definition, it needs state to carry across invocations, and it often runs long enough to hit platform ceilings that were never meant to be tested this way.

Start with trust, because an agent running code it generated itself is the most structural of the three. An agent, by its nature, runs code or commands that it generated itself. A shared-kernel boundary, the one described in the previous section as efficient but thin, is not the right container for code with that provenance. Code generation exploits occur when the agent produces code that contains vulnerabilities or outright malicious logic, and the mitigation for both requires sandboxed execution in an environment with no network access and minimal system privileges.

Then there is latency, and here the numbers make the case better than any description could. Blaxel's platform analysis, drawing on sandbox performance findings from The New Stack, lays out the arithmetic: five tool calls at 50 milliseconds each finish in 250 milliseconds total, while the same five steps running inside a 1.5-second sandbox take more than seven seconds. That gap does not just annoy a user staring at a loading spinner. Blaxel's analysis describes it as "breaking the agent's reasoning chain," because an agent working through a multi-step plan depends on each step returning fast enough that the next step can build on it coherently. Cold-start delay compounds across an agent's full trajectory rather than costing time once. A startup tax that looked tolerable in a single Lambda invocation becomes a serious liability once it repeats dozens of times inside one task.

State loss is the third break, and it follows directly from the statelessness described in the previous section. FaaS, by design, only knows how to answer "start clean."

Finally, the runtime ceiling. Multi-step agent tasks frequently run for minutes at a stretch, sometimes longer, and Lambda's runtime limit is a boundary the platform was built to enforce, not an oversight that catches these tasks by accident. An agent mid-reasoning does not pause gracefully at a 15-minute mark just because the platform asked it to.

Isolation in Practice: Three Technologies

If shared-kernel containers are the weak link, the next question is what a strong one actually looks like. Meaningful isolation for untrusted, AI-generated code means a hardware-level boundary between the guest workload and the host kernel: a genuinely separate kernel, not a process boundary or a namespace. That distinction is the whole argument in miniature: vendors use the word "isolation" loosely enough that it can mean three very different things.

There are three mainstream isolation models, and PandaStack and Blaxel both describe where they sit on the same security ladder. Shared-kernel containers sit at the bottom. They are efficient and well understood, but a single runtime CVE can compromise the entire host, because the attack surface is the full Linux syscall interface, every system call the kernel exposes, available in principle to anything running inside the container. User-space kernels, gVisor being the common example, sit in the middle of that ladder: stronger than a shared kernel because syscalls get intercepted before they ever reach the host, weaker than full hardware virtualization, and carrying some performance overhead as a result of that interception.

Hardware-virtualized microVMs, Firecracker and Kata being the named examples, are at the top. Each sandbox gets its own kernel and its own guest operating system, so the virtual machine monitor's attack surface is dramatically smaller, and far better audited, than the full Linux syscall interface a shared-kernel container exposes. That claim needs an honest qualifier, and PandaStack supplies one directly: VMMs have had bugs, and KVM has had bugs. Smaller and better-audited does not mean unbreakable, and no serious engineer should treat microVM isolation as a guarantee rather than a substantial reduction in risk.

Isolation at the VM boundary is also not the end of the defensive stack. Privilege-dropping jails, seccomp filters, and per-sandbox egress controls all layer additional restriction on top of the VM itself, narrowing what a compromised guest could do even in the unlikely event it broke out. Prompt injection sits adjacent to this whole discussion rather than inside it: input validation, prompt filtering, and output monitoring all help, but they operate at a different layer than sandbox isolation and do not substitute for it.

Cloudflare Workers' V8 isolate model deserves another mention here, because it is a genuinely distinct approach rather than a weaker version of the same idea. Each isolate gets its own heap and its own global scope, but the model is scoped to a single JavaScript runtime rather than arbitrary operating-system-level execution, which places it outside this ladder entirely rather than at some fixed rung on it.

None of this is settled, static engineering either. The 2026 arXiv paper on DeltaBox (arXiv:2605.22781) addresses scaling stateful AI agents through millisecond-level sandbox checkpoint and rollback, which confirms that checkpoint-based isolation is an active research frontier, not simply a line in a vendor's marketing copy. The practical upshot for anyone evaluating a platform: the isolation model is the first question to settle, because everything else, startup speed, state handling, pricing, sits downstream of that choice.

How the leading sandbox platforms handle isolation, startup, and state

With that framework in hand, the platforms engineers actually evaluate separate out clearly along three axes: isolation model, startup latency, and state persistence, the same three dimensions the prior section identified as the ones that matter for agent workloads.

Northflank positions itself around high concurrency, with support cited for thousands of concurrent sessions and a specific claim of being best suited to AI agent code execution at that scale. Its SOC 2 Type 2 certification covers the platform across both managed cloud deployments and bring-your-own-cloud arrangements, a detail that matters for teams with their own compliance requirements layered on top of whatever the sandbox vendor provides.

Blaxel takes what it calls a perpetual sandbox approach: microVM environments stay in standby indefinitely and resume in under 25 milliseconds with the complete filesystem and memory state restored. Blaxel holds SOC 2 Type II and ISO 27001 certifications, with HIPAA compliance available as a BAA add-on, and it operates as a first-class sandbox provider inside the OpenAI Agents SDK.

PandaStack runs an open-source, Apache-2.0 model in which every sandbox is a Firecracker microVM with its own guest kernel, version 5.10 on Ubuntu 24.04, isolated by KVM and run under a privilege-dropping jailer. That stack can run on a developer's own infrastructure, any Linux box with /dev/kvm available, or on PandaStack's hosted offering, using identical SDK code either way. Boot is snapshot-restore on every create, with a 179ms median and roughly 203ms at the high end, the restore step itself taking around 49ms. PandaStack also supports first-class forking through copy-on-write: same-host forks complete in 400 to 750 milliseconds, cross-host forks in 1.2 to 3.5 seconds, a pattern suited specifically to tree-search style agent work, where a task tries several candidate fixes in parallel branches rather than one linear path.

Northflank's comparison finds that Together Code Sandbox fits agents that return to a workspace expecting memory and disk state preserved through hibernation. Vercel Sandbox provides isolated code execution using Firecracker microVMs, with session limits set by plan tier, and fits most naturally for teams already building on the Vercel platform.

Across this field, a few patterns repeat often enough to count as a trend rather than a coincidence. Several platforms lean on being open-source and transparent as a deliberate contrast to black-box execution services, and compliance, SOC 2, HIPAA, GDPR, appears built into the base offering for some rather than priced as a premium tier.

State Persistence and Snapshot Design

Lost state.

The distinction is mechanical rather than philosophical. Ephemeral sandboxes discard the entire environment the moment a task ends. Stateful sandboxes take a different approach: they may preserve files automatically, support suspending and resuming a session, mount persistent volumes that outlive any single invocation, or let a developer create explicit snapshots to return to later. Mastra's evaluation framework reduces the choice to a single question: should each task begin in a clean environment, or should it continue from work a previous step already did?

That question is not rhetorical. An agent running a one-shot data transform behaves exactly like the webhook handlers FaaS was built for in the first place, and a clean environment every time is not just acceptable, it is correct. Discard its state between calls and every invocation starts by redoing work the previous invocation already finished; this is the same state loss described earlier, now built into the product rather than appearing as an abstract failure mode.

The snapshot and checkpoint mechanics covered earlier stop being theoretical here. PandaStack's snapshot-restore boot path and sub-second forking exist specifically to make "continue from previous work" cheap enough to do constantly rather than sparingly. Blaxel's perpetual sandbox model, resuming in under 25 milliseconds with full filesystem and memory state intact, answers the same question from a different direction: keep the environment alive in standby rather than tearing it down and rebuilding it. The DeltaBox research described earlier, millisecond-level checkpoint and rollback for stateful agents, points at where this capability is headed next: faster, cheaper state transitions that make the distinction between "ephemeral" and "persistent" less of a binary choice and more of a dial an engineer can set per task.

What ties the whole piece together is this: serverless functions got the economic model right from the start, pay for what runs, scale to meet demand, provision nothing ahead of time. What they did not anticipate was a workload shaped like an agent: untrusted by origin, stateful by necessity, and long-running by the nature of the task itself. The platforms built specifically for that shape, whatever their differences in isolation technology or snapshot speed, share one trait that distinguishes them from a Lambda function wrapped around an agent call: they treat state as something to preserve on purpose, not an afterthought left behind when the function returns.