Serverless Functions as On-Demand Code Sandboxes

Serverless functions were built to answer one question: can you run code without babysitting a server? For years the answer was an uncomplicated yes. Then agents changed the assignment. They write, execute, and revise their own code across steps that run for minutes or hours, a shape of work nobody had in mind when the timeout logic got written. This piece walks through what happens when a compute model built for short, stateless requests must hold an agent's memory, tools, and context for as long as the task takes, and where the cracks show first.

What serverless functions actually provide when used as a sandbox

The headline feature is isolation by invocation. Every time a function runs, it gets a fresh execution context, so a bad script from one run doesn't bleed into the next. Once the function returns, the platform tears the whole thing down, and there's no leftover state sitting around waiting to be poked at. Memory and CPU are capped per function, which keeps a runaway loop from eating the whole host, and network egress can be locked down through the cloud provider's VPC and IAM rules. Scale-to-zero billing rounds out the picture: idle costs nothing, and the platform meters every invocation on its own.

That's a genuinely solid fit for one kind of job: a single script written by a model that runs, produces an answer, and exits. A lot of early AI tooling looks exactly like that. Trigger the function, feed it the model's output, run it, hand back the result, discard the environment. For narrow, short-lived work this holds up fine, and you get real separation from the host system without much setup on your end.

But the moment a task needs to remember something from three steps back, or a tool needs to load once and get reused across a chain, things come apart at the seams. Serverless assumes each invocation is a clean, closed loop. Agent work is rarely that clean, and pretending otherwise is how teams end up debugging state loss at 2am instead of designing around it.

The three structural constraints that surface when serverless runs agent code

Start with the timeout. Serverless platforms enforce a hard execution limit on purpose; that reclamation is what makes scale-to-zero economics work at all. Agent tasks don't respect that clock. Browsing a page, writing and running a snippet, waiting on a slow API, chaining several tool calls together: any single one of these can burn minutes, and stacked together they run for hours. When the timeout hits mid-task, the agent doesn't just pause. It loses whatever state it was holding, and the work either restarts cold or has to reconstruct itself from whatever got persisted along the way, assuming anything was. AWS addressed this head-on at re:Invent 2025 with Lambda Durable Functions, removing the timeout constraint for long-running and human-in-the-loop workflows. Worth sitting with for a second: the largest serverless provider in the market built a feature whose entire job is admitting the original timeout model doesn't hold up once agents show up.

Cold starts are the second problem, and they're sneakier. Before a function runs a single line of code, the platform has to spin up a fresh environment, load the runtime, initialize whatever dependencies the function needs. For a web API that delay is a rounding error, a few hundred milliseconds nobody notices. For an agent mid-task, waiting on a tool call whose next step depends on a response that isn't there yet, the same delay can break the interaction outright. Provisioned concurrency, pre-warming, snapshot restore all exist to soften this, and all three cost money or operational overhead; most of them mean you've already stepped outside the pure serverless model just to patch around its own default behavior. MicroVM snapshot-restore, the approach behind Firecracker, resumes a full environment in a fraction of the time a cold boot takes, attacking the same problem from a different angle entirely.

The third constraint is structural rather than a matter of degree. Statelessness itself is the design. Serverless functions are built so nothing carries over between invocations, and anything that needs to persist gets pushed out to a database or object store. Agents accumulate exactly the kind of state this model resists: results from earlier tool calls, partial outputs, environment variables, loaded libraries, files changed mid-run. Push all of that to external storage and you've added latency, added serialization work, and added new places for the process to fail quietly, often without a useful error message telling you why. A config flag won't patch this one. It reflects two different philosophies about what a unit of compute is even for: one handles discrete, disposable requests, the other runs a process that thinks in steps and remembers what it did three steps back.

How the isolation model inside a serverless function compares to what AI-generated code actually requires

Most standard serverless containers share the host machine's kernel. The isolation you get is a software convention: the runtime enforces boundaries in cooperation with the OS rather than providing a hardware wall between tenants. That distinction starts to matter once you think hard about what's actually running inside the box. Code an agent writes is untrusted by definition, and no human read it before it executed. That puts it in a different risk category than code a developer commits after review, and, frankly, the execution environment needs to treat it that way even when it's inconvenient to do so.

This isn't hypothetical. A 2026 vulnerability in a widely used AI platform's command-line tool showed how AI-generated instructions could escape sandbox mode, reach cached credentials, and trigger arbitrary code execution on the host machine. That's the exact failure mode weak isolation makes possible, spelled out in production rather than in a whitepaper.

The hierarchy runs roughly like this. Hardened containers are fine for code you already trust, but they fall short against adversarial or AI-generated input; the boundary is soft. gVisor, a user-space kernel, intercepts system calls before they ever reach the host kernel, cutting the attack surface considerably, though it gives up GPU passthrough to do it. MicroVMs, the model behind Firecracker and Kata Containers, push the boundary down to hardware virtualization. Escaping one means finding a hypervisor bug, a category of vulnerability that's rarer and far more expensive to discover than a container escape.

The gap has real teeth. A container escape on a shared serverless host can hand an attacker root on infrastructure other tenants are using. A microVM escape means breaking the hypervisor itself, a fundamentally harder problem to pull off. For any team running code it didn't write (LLM output, agent-generated scripts, snippets a user submitted), the isolation tier stops being a nice-to-have and turns into the actual security requirement, full stop.

WebAssembly is a third option worth a mention, one still finding its footing. It offers instruction-level isolation without needing a full OS boundary, which fits narrow, portable tasks well. It hasn't reached the full range of system calls most AI agents actually need to touch, though, so treat it as promising rather than settled.

Where serverless providers are extending their platforms to reach agent workloads

The major cloud providers have clearly seen this coming, and each is building toward it from inside its existing serverless product rather than starting over. Azure Functions has a Serverless Agents Runtime in public preview, using a markdown-first programming model that treats AI agents as a first-class workload complete with event-driven triggers, scale-to-zero billing, and built-in session history and observability. The platform handles trigger registration, model calls, tool assembly, and state tracking on its own, giving the agent a measure of continuity beyond a typical stateless function.

AWS is moving on two fronts at once. Lambda Durable Functions removes the hard timeout, as mentioned above, and Lambda Tenant Isolation lets a team pass a tenant ID at invocation time so Lambda spins up a fully isolated environment per tenant, with no separate deployed function needed for every customer. And there's Bedrock AgentCore, a managed service for deploying agents built on any framework (LangGraph, CrewAI, custom code) with stateful MCP server support that keeps session context alive across tool calls. AgentCore in particular reads less like an extension of serverless and more like a managed agent runtime that happens to sit next to it. That distinction is worth pausing on.

Cloudflare Workflows and Vercel's Workflow DevKit both hit general availability for durable execution in late 2025. That's a decent signal this has moved past early-adopter territory.

What ties all of this together is direction, not any single feature: durable execution, state that sticks around, environments that outlive a single invocation. Every one of these moves is a step away from what made serverless serverless in the first place, and toward properties a purpose-built agent runtime would have started with on day one. That's less a knock against the providers than a read on where the demand is pulling everyone. Underneath, though, these are additive patches on a stateless foundation, and a team that adopts them inherits the job of assembling durability, isolation, and observability out of parts that weren't originally built to click together.

What purpose-built sandbox runtimes provide that serverless extensions still assemble from parts

The design difference comes down to starting point. Serverless platforms start from stateless request handling and bolt agent capability on afterward. Purpose-built sandbox runtimes start from what an agent actually needs to execute and build outward from there. That ordering decides what you get by default versus what you're stitching together yourself at 11pm before a launch, a distinction that sounds abstract until you've lived it once.

In a runtime built around that starting point, near-instant provisioning is the baseline rather than a stretch goal. Sandboxes built on microVM snapshots restore a full environment in milliseconds, keeping an agent responsive across a chain of tool calls without a cold-start gap breaking the flow. State persists across steps because the architecture assumes it should: filesystem changes, loaded tools, in-progress context stay put between invocations, and nothing has to be serialized out to an external store just to survive to the next step. Execution runs as long as the task actually takes, with no platform clock forcing an artificial stopping point mid-flow. Isolation happens at the hardware level, through microVM boundaries rather than container convention, on the working assumption that AI-generated code is untrusted from the first instruction it runs.

Some purpose-built runtimes embody this philosophy end to end. Sandboxes provision in under 90 milliseconds, stateful from the ground up, able to run for as long as the task needs, isolated at the hardware layer instead of leaning on container norms. The design targets what autonomous systems actually do, drawing on tooling built with agent workloads in mind rather than retrofitted from tools designed for a human developer running the occasional script. Docker-native compatibility means a team can bring images it already has; no rewrite required to go from prototype to production. Support for customer-managed compute, meaning the sandbox runs inside the customer's own cloud, plus compliance certifications like SOC 2, HIPAA, and GDPR, make it workable for organizations where data residency and audit trails aren't optional line items. And because the architecture is open-source, a team can see what the runtime actually does with its code, rather than trusting a sealed box to behave itself.

How to decide which model fits the work at hand

Serverless still earns its place for a specific kind of job: short tasks with a clean, predictable end point, invocations that finish comfortably inside the platform's timeout window, workflows where pushing state to a database doesn't cost latency you can actually feel. Teams already deep in one cloud provider's ecosystem, who'd rather not stand up new infrastructure to run a script, belong here too. There's no shame in that fit; it's still most of what gets built.

The signal points the other way once tasks start bumping against timeout limits, even occasionally, or once an agent needs to carry state across several steps without constantly round-tripping to a database. It points the other way once the code in question is genuinely untrusted, written by a model or submitted by a stranger, and needs a hardware-level isolation boundary rather than a container's good-faith agreement. It points the other way once a workflow needs to pause and pick back up later without losing its place, which calls for snapshot-restore rather than re-invoke-and-hope. And it points the other way once cold starts, multiplied across several agents running at once in production, start adding up to latency that shows up on someone's dashboard, the kind that gets a ticket filed against it.

Hold the workflow up against its real time and state needs. If the serverless timeout feels like an obstacle you're engineering around, rather than a natural stopping point the task was always going to hit anyway, the platform is working against the job, not for it. Teams building agents, or anything that executes code on the fly, ought to treat the execution environment as a real architectural decision made up front rather than a default that happened to be sitting there when the project started. Whatever assumptions get baked into that sandbox end up defining what the agent is actually allowed to do once it's live. By then, changing them costs a good deal more than it would have on day one, which is really the whole point of thinking about it now instead of after the incident report.