Sandboxed Code Execution: How to Run Untrusted Code Safely

You built an AI agent that writes and runs its own code. Congratulations, you also built a way for arbitrary, untrusted code to touch your servers. That is the exact problem that sandboxed code execution cloud platforms solve: they give untrusted code a locked room to run in, where it can do its job without reaching your host, your data, or your other customers.

If you are a developer, DevOps engineer, or a CTO shipping agentic features, this matters more every month. AI-generated code, user-submitted scripts, and third-party plugins all share one trait. You cannot fully trust any of them. A proper isolated execution environment lets you say yes to all three anyway.

What is sandboxed code execution in the cloud?

The concept of sandboxed code execution cloud infrastructure is the practice of running code inside a restricted environment where its actions are tightly limited and its blast radius is contained. The code can compute, print, call approved APIs, and return results. What it cannot do is escape into the surrounding system, read files it has no business reading, or quietly open network connections you never approved.

Think of it as an architectural boundary. Access control, confidentiality, and integrity policies get enforced at the edge of the sandbox, not politely requested inside your app. This idea sits at the center of cloud systems, browser engines, plugin frameworks, and language runtimes, and it is now the default pattern for anything that touches AI-generated code.

In the cloud, the sandbox is usually created on demand, does its work, and gets destroyed. Platforms like LikeClaw, for example, spin up an isolated sandbox for each task and tear it down the moment the task finishes. Nothing lingers, so nothing leaks between jobs.

Why running untrusted code safely is harder than it looks

The naive approach is to run code in a container and call it a day. Containers are great for packaging and deployment, but they share the host kernel. A kernel exploit inside a shared container can, in the wrong conditions, reach the host or neighboring workloads—a risk that sandboxed code execution cloud solutions are specifically designed to mitigate. For truly untrusted input, that shared surface is the weak point.

The second trap is cost. AI agents that loop, retry, and spawn sub-agents can rack up compute charges fast. If your sandbox has no session limits and no clean teardown, you inherit both a security risk and an unpredictable bill. That combination is exactly what teams building agent products keep running into.

The third issue is state. Some workloads finish in two seconds. Others, like an agent holding context across a multi-day conversation, need to persist. A sandbox model that assumes everything is short-lived breaks the moment you need durability, so the isolation strategy and the lifecycle strategy have to be designed together.

To run untrusted code safely, you need three things at once: a strong isolation boundary, a predictable lifecycle, and controls on network and resource access. Miss any one and the other two stop mattering.

How microVMs create a truly isolated execution environment

This is where microVMs earn their keep. A microVM gives each workload its own lightweight virtual machine with its own kernel, so a compromise inside the sandbox does not reach the host kernel the way a container breakout might—a critical advantage for sandboxed code execution cloud platforms. You get much of the isolation of a full VM with startup times measured in fractions of a second.

Firecracker, the microVM technology originally built for AWS Lambda and Fargate, is the engine behind many modern sandboxed code execution cloud providers. E2B, an open-source cloud runtime built specifically for AI applications and autonomous agents, runs its sandboxes on Firecracker microVMs. Its Custom Sandboxes feature launched back on November 7, 2023, and the approach has become a standard for safe AI-generated code execution.

The pattern is proven well beyond AI, too. The same style of isolation powers Cloudflare Workers, AWS Lambda, and Vercel's serverless functions. When a platform tells you it runs each task in a fresh microVM and destroys it afterward, that is the sandboxed code execution cloud model doing its job: strong boundaries, fast startup, clean teardown.

Comparing cloud sandbox options in 2026

The market has clear options now, and they trade off along a few axes. Here is how the main players stack up:

• E2B: Open-source, Firecracker-backed, and built for agent workflows with strong SDKs. Sessions cap at around 24 hours, which is plenty for most task-based work.
• Vercel: Serverless-style sandboxing with short session windows, roughly 45 minutes to 5 hours. Great for quick, stateless execution, tighter for long-running agents.
• Google Cloud Run sandboxes: Cloud Run is already sandboxed and isolated, and its sandbox command-line tool lets you execute untrusted code in any language inside an optimized, isolated environment. A solid fit if you already live in GCP.
• Northflank: Combines microVM isolation with full workload orchestration and, notably, bring-your-own-cloud deployment across AWS, GCP, Azure, or bare metal. Its sandboxes persist until you terminate them, with no forced session cap, which suits agents that hold state for days or weeks.

The decision usually comes down to two questions. How long do your sandboxes need to live, and where does the data need to stay? If you're evaluating a sandboxed code execution cloud option and need sensitive data to remain inside your own VPC, a bring-your-own-cloud model matters. If you just need fast, disposable execution for short tasks, a session-capped platform is simpler and often cheaper.

The common mistake is picking on price alone. A slightly cheaper sandbox that caps sessions at 5 hours is not cheap if your product needs 3-day agent state and you end up rebuilding everything.

How to set up your first code sandbox microVM

You do not need to build Firecracker orchestration from scratch. Start with a managed platform and wire it in behind your existing code execution flow. Here is a practical path:

1. Pick a platform based on session length and data residency. Short, stateless tasks in GCP? Cloud Run sandboxes. Agent workflows? E2B. Persistent state or VPC data requirements? A bring-your-own-cloud option like Northflank.
2. Isolate per task. Create a fresh sandbox for each execution and destroy it on completion. This keeps state from bleeding between jobs and caps your cost per run.
3. Lock down network and resource limits. Deny outbound network by default and allow only the endpoints your code actually needs. Set CPU, memory, and timeout ceilings so a runaway loop cannot drain your account.
4. Log everything the sandbox does. Capture inputs, outputs, and resource usage. You will want this the first time an agent behaves in a way you did not expect.
5. Load test before you ship. Confirm the platform handles concurrent sandboxes at the volume you expect, and verify teardown actually reclaims resources.

Start with a single tool, run 20 or 30 real tasks through it, and check the security boundaries and the bill against your assumptions. If both hold up, you have a foundation you can trust with genuinely untrusted code.

FAQ

What is the difference between a container and a microVM for sandboxing? Containers share the host kernel, which leaves a larger attack surface for untrusted code. A microVM runs its own kernel in a lightweight virtual machine, so a compromise stays contained, while still starting in a fraction of a second.

Can I run AI-generated code safely in the cloud? Yes. That is the main reason the modern sandbox market exists. Platforms like E2B run each AI task in a Firecracker microVM and destroy it afterward, so generated code cannot reach your host or persist between tasks.

How long can a cloud code sandbox run? It depends on the platform. Vercel-style sandboxes run roughly 45 minutes to 5 hours, E2B caps around 24 hours, and Northflank sandboxes persist until you terminate them, which suits long-lived agents.

Do I need to build my own sandbox infrastructure? Usually not. Managed platforms handle the microVM orchestration for you. You focus on wiring the sandbox into your execution flow, setting network and resource limits, and logging what runs.