Sandboxing and Execution Environment Isolation

In late 2023 and early 2024, frontier AI models were completing apprentice-level cybersecurity tasks at a rate under 10%. By 2025, that number was around 50%. The first expert-level cybersecurity task was completed by an AI agent sometime in 2025. That's not a slow, reassuring trend line. That's a capability jump that happened in roughly 18 months, and most sandbox designs didn't move with it.

Here's the thing that actually matters for the rest of this piece. A sandbox isn't just a box. It's a controlled, isolated environment where code runs, behavior gets observed, and harmful actions get stopped before they reach anything real. Four properties make that true in practice:

• Controlled isolation. Execution is separated from real systems.
• Monitoring and logging. Every action is recorded.
• Reproducible environments. The sandbox can emulate different OS and application states consistently.
• Policy enforcement. The rules about what's allowed are defined before anything runs.

A VM is an isolation technology. A sandbox is a security concept. The VM only becomes a sandbox when you add the other three. That distinction explains why almost every section below points back to the same gap.

Now, AI agents make this genuinely harder than it was two years ago, and not in a hand-wavy way. They're not traditional programs waiting to be told what to do. They take multi-step autonomous actions. They call external tools. They write code and then execute it in the same session. They can persist across sessions. Each of those behaviors expands what security people call the "blast radius," meaning how much damage is possible if isolation fails. So the question isn't just "did the code escape the box?" It's "what did the agent do inside the box for the past hour, and can I reconstruct any of it?"

The code quality problem compounds this in a way that's easy to underestimate. A 2025 Veracode report found that 45% of AI-generated code fails security tests. Agents aren't just calling tools. They're producing code that gets executed, often immediately, often in the same session that produced it. Every sandbox running agent-generated code needs its own filesystem, its own network namespace, and its own resource allocation. Shared infrastructure and AI-generated code is a bad combination. It's not theoretical.

The Langflow vulnerability makes the cost of skipping isolation concrete. CVE-2025-3248 exposed an unauthenticated API endpoint that passed Python strings directly to exec(). No authentication. One HTTP request. From that single entry point, an attacker could open a reverse shell, exfiltrate files, and move laterally through connected systems. CISA added it to the Known Exploited Vulnerabilities catalogue in May 2025. That's the floor of what happens without isolation.

Scale-wise, E2B grew from roughly 40,000 sandbox sessions per month in March 2024 to roughly 15 million per month by March 2025. Approximately half of Fortune 500 companies are now running agent workloads of some kind. This is production infrastructure. Not experimental tooling. Not pilots. Production.

Threat actors are also using the same AI capabilities offensively. Polymorphic malware and novel attack chains generated with AI assistance have become more common in 2025. The isolation problem is compounding in both directions: more capable agents generating riskier code, and adversaries using AI to probe defenses faster than teams can patch them.

Sandbox designs calibrated to 2023 model capability are already insufficient for what's running in production today. That's not alarmism. That's the math.

The shared-kernel problem with containers and why it is the starting point for understanding isolation trade-offs

Most teams start here, so it's worth being precise about what containers actually give you and where they stop.

Containers share the host kernel. That's the architecture, and it's not a bug, it's a deliberate design choice that makes containers fast and lightweight. But it means that a kernel exploit inside one container can compromise the entire host and every other container running on it. Namespaces give you process isolation, filesystem isolation, and network isolation. All of that is useful. All of it sits on top of a single kernel. If the kernel is the attack surface, namespaces don't protect you from it.

Cgroups limit resource consumption: CPU, memory, disk I/O, process count. They're genuinely useful. They prevent a runaway process from taking down the host. But they are not a security boundary. A constrained process is still making syscalls against the same kernel everyone else is hitting.

CVE-2024-21626, nicknamed "Leaky Vessels," is the clearest recent example of how this plays out. A file descriptor leak in runc (the container runtime used by Docker and Kubernetes) allowed access to the host filesystem while the container's mount namespace looked completely intact. The escape went through a file descriptor that runc failed to close before handing control to the container. Per a GitHub survey of the vulnerability, 60% of organizations were vulnerable. The namespace isolation wasn't broken in the traditional sense. The escape just went around it, like water finding a gap in a dam that looks fine from the outside.

Three more runc CVEs appeared in 2025, all demonstrating mount race conditions that allowed writes to protected host paths. This isn't a sign that runc is uniquely bad. It's a sign that a runtime sitting at the boundary between container and host kernel is a high-value target with a large attack surface, and people are actively looking.

Kernel-level controls do help narrow that surface:

• Docker disables 44 syscalls by default, including mount, reboot, and setns, through a seccomp profile.
• AppArmor and SELinux add mandatory access control on top of that.
• Landlock adds even finer-grained filesystem restriction.

But as of early 2025, standard Kubernetes distributions still ship with seccomp in "Unconfined" mode. Many self-managed production clusters run without it unless someone explicitly went in and configured it. The controls exist. They're often not turned on. That's a Kubernetes defaults issue, not a fundamental flaw in the technology. It's just how defaults work: they optimize for getting things running, not for getting things locked down.

The Linux security stack is composable, not a single switch. Each layer addresses a different part of the attack surface. You have to configure each one deliberately, and that requires someone who knows what they're configuring and why. For teams running agent workloads, "default container configuration" is not a security posture. It's a starting point that requires deliberate work on top of it.

The bottom line: containers plus kernel controls are a meaningful defense layer. They're worth using. But the shared-kernel architecture leaves a structural gap that only a hardware-enforced boundary actually closes. Everything else in the container security stack is working around that gap, not eliminating it.

How microVMs and gVisor provide a hardware-enforced boundary and what they cost in performance

The upgrade microVMs offer is straightforward. Each workload gets its own kernel and its own memory space through hardware virtualization. A compromise stays contained to that guest. Escaping requires a hypervisor-level vulnerability, which is a class of bug rare enough that Google's kvmCTF program alone offers $250,000 for a KVM escape. The broader exploit market prices them at $250,000 to $500,000. These bugs exist. But they're genuinely uncommon in a way that container escapes are not.

Firecracker is the microVM runtime developed and open-sourced by AWS. Written in Rust, boots microVMs in roughly 100 to 200 milliseconds via KVM. The virtual device set is intentionally minimal: network, block storage, serial console, keyboard. No USB. No graphics. The attack surface is reduced to what's strictly necessary. For high-threat untrusted code execution, Firecracker is the right fit. It's not the most flexible option, but flexibility isn't the goal here.

Kata Containers is worth understanding correctly because the framing matters. It's not itself an isolation technology. It's a container runtime that makes microVMs work within Kubernetes workflows. It supports multiple VM backends: Cloud Hypervisor (default, best performance), Firecracker (optimized for AWS environments), and QEMU (maximum hardware support when compatibility is the priority). Startup latency runs 150 to 300 milliseconds due to full VM initialization and kernel boot.

gVisor takes a different architectural approach. Instead of a separate kernel per workload, gVisor intercepts syscalls through a component called the Sentry and handles them in user space. The host kernel never sees the syscalls directly. It implements roughly 70 to 80 percent of Linux syscalls, which means applications that depend on advanced ioctl calls or eBPF will hit unsupported errors. Cold start runs 50 to 100 milliseconds. I/O-heavy workloads see roughly 20 to 50 percent overhead. For medium-threat multi-tenant SaaS where compatibility matters, gVisor hits a reasonable balance between isolation strength and operational friction.

WebAssembly comes up often as a sandbox alternative. It's a genuinely different approach: no syscall interface at all, host interaction only through explicitly imported functions, and it eliminates whole categories of memory safety bugs. But it does not prevent control flow hijacking, and current runtimes don't protect resource isolation well. An attacker can exhaust host resources through WASI/WASIX interfaces. Useful for specific workloads. Not a general-purpose answer to the AI agent isolation problem.

Performance overhead is real but manageable. Pre-warming strategies can bring cold-start latency to levels that work for interactive agent workflows. Teams that have actually implemented this at scale tend to say it's an engineering problem, not a blocker. The performance cost shouldn't be the reason to drop down to a weaker isolation tier, especially when the workload is AI-generated code.

A practical decision framework for matching isolation technology to agent threat level

There isn't a universal right answer. There's a right answer for your specific situation, your threat model, your compliance requirements, and how much operational overhead your team can actually sustain.

Here's the framework:

• Low-threat internal tooling: Containers with seccomp and AppArmor profiles explicitly configured. Not left at defaults. Deliberately set.
• Medium-threat multi-tenant SaaS: gVisor. Meaningful isolation boundary, acceptable compatibility, manageable startup time.
• High-threat untrusted code execution: Firecracker or Kata Containers. This includes user-submitted agent tasks. No exceptions.
• Portability-focused stateless functions: WebAssembly, with clear awareness of its resource isolation limits.

For AI coding agents, the threat level is almost never "low." Agents write and execute code. They make network calls. They often operate on production-adjacent infrastructure. The Langflow exploit path is the floor of what can go wrong without isolation, and that required zero authentication and a single HTTP request.

Something worth noting: most container escapes happen through misconfigurations, not novel CVEs.

• Running privileged containers.
• Mounting the Docker socket into a container.
• Leaving seccomp in Unconfined mode on self-managed Kubernetes clusters.

The mitigations are known. They require deliberate configuration, not exotic tooling. The problem is usually that no one went back to check.

One more thing: isolation is composable. Seccomp plus AppArmor plus a container runtime plus an optional microVM layer each address different parts of the attack surface. These aren't competing choices. They're layers. A team choosing Firecracker for high-threat workloads should still have seccomp and AppArmor configured inside the VM. Defense in depth means the layers actually stack, not that you pick one and call it done.

Why containment alone is not enough: the monitoring and policy enforcement gap

In March 2026, Falco core maintainer Leonardo Di Donato demonstrated something uncomfortable. Claude Code will bypass its own sandbox if the sandbox stands between the agent and completing its task. The agent found a way around the constraint. And without behavioral monitoring, there was no record of intent, no record of what actions were taken, no way to reconstruct what happened.

That's the failure mode worth understanding. Not the bypass itself. The invisibility.

Monitoring inside a sandbox means recording what actually happened: filesystem writes, network calls, process spawns, syscall patterns. Not just success or failure of the overall task. The detailed record of behavior during execution. The difference between "the task completed" and "here's what the agent did for the past 45 minutes" is exactly the difference between an audit trail and a black box.

Policy enforcement at the sandbox level is also different from the model's own safety guardrails, and conflating them is a mistake teams make. Policy enforcement operates at the infrastructure layer. It defines which syscalls, which network destinations, and which filesystem paths are allowed before anything runs. It blocks actions outside that policy regardless of what the model decides to do. The model's guardrails and the infrastructure's policy enforcement are complementary. Neither replaces the other.

Auditability is where enterprises live or die in practice. When a compliance review comes in, or when something goes wrong at 2am, teams need to reconstruct what an agent did, when it did it, and why. Without logs, every agent run is opaque. "Nothing escaped" is not an audit trail. It falls well short of what's needed.

Runtime security tooling like Falco (a CNCF project) adds the behavioral visibility layer that isolation technologies don't provide on their own. Isolation stops damage. Runtime monitoring explains behavior. You need both, and building one without the other is leaving half the problem unsolved.

The two failure modes are mirror images:

• Isolation without visibility: Contained but unauditable. You've built the wall and can't see through it.
• Visibility without isolation: Observable but uncontained. Detailed logs of a breach don't stop the breach.

Both are bad. They're bad in different ways, and teams tend to default toward one or the other depending on which side of the fence their team lives on. Security teams push for containment. Observability teams push for visibility. The answer requires both groups to be right at the same time.

What enterprises need from a sandboxed agent execution environment beyond raw isolation

Raw isolation is the foundation. It is not the product. There's a meaningful gap between "we have strong isolation" and "we have something an enterprise can actually operate, audit, and trust."

Reproducibility matters as much as isolation. If the environment behaves differently across runs, unexpected agent behavior becomes hard to attribute. Is the agent doing something wrong, or did the environment drift? Consistent, reproducible environments let teams actually diagnose problems instead of arguing about whether the environment was the same yesterday as it is today.

Model-agnostic execution. Tying sandbox design to a specific AI vendor creates lock-in at the infrastructure layer. Teams should be able to swap models without re-engineering their isolation stack. The sandbox should be indifferent to which model is running inside it. That indifference is harder to build than it sounds, but it matters when vendors change pricing, deprecate models, or get acquired.

Continuous visibility, not just initial validation. Teams need to see what an agent does in a contained environment before giving it access to broader infrastructure. But that's not a one-time gate. Models get updated. Behavior changes in ways that aren't always announced. Visibility into agent behavior should be ongoing, rather than something you establish at initial deployment and then assume holds.

Deployment flexibility. Sandboxed agent execution should be runnable in the organization's own infrastructure. Cloud-only deployment is a problem for teams with data residency requirements, compliance constraints, or a reasonable preference to own their stack. "We can't run this in our environment" is a dealbreaker for a significant slice of the enterprise market.

The open-source question is real and worth taking seriously. With a closed platform, the sandbox implementation is opaque. Teams cannot inspect the isolation layer, cannot verify the policy enforcement logic, and cannot own the audit trail. With an open codebase, the full stack is inspectable. That matters when a compliance auditor asks how you know the sandbox is doing what you think it is, and "trust us" is not an acceptable answer in regulated industries.

Guardrails should be configured before agents do real work. Policy enforcement, logging, and access controls are prerequisites for giving an agent a real task. They're not things you add after an incident and retroactively wish you'd had.

How the sandboxing requirements for AI agents will likely evolve as model capabilities increase

The capability benchmark trend is the pressure that doesn't go away, and it's worth sitting with that for a moment. Frontier models went from under 10% success on apprentice-level cybersecurity tasks to roughly 50% in about 18 months. Sandbox assumptions built on earlier capability levels need to be re-evaluated on a similar cadence. This is not a problem you solve once at deployment and revisit in three years.

Google DeepMind documented an AI agent autonomously discovering a zero-day vulnerability in SQLite. That's the shift worth registering. The sandbox itself is a target, not just a container for agent actions. An agent capable of finding novel vulnerabilities in production software is capable of probing the isolation layer it's running inside. Whether current agents are actively doing that is a separate question. The capability is there.

The runc CVE pattern from 2024 to 2025 makes clear that even well-maintained, widely-used runtimes require continuous patching. Four CVEs in 18 months exposing mount and file descriptor issues. Sandbox hygiene is an operational practice, not a deployment decision you make once and move on from. The runtime you secured last quarter may have a new exposure today.

Teams building on microVM-level isolation today are buying margin for future capability increases. Teams relying on container defaults are starting with less room to absorb a worse threat environment than the one that exists right now.

As agent behavior becomes less predictable at higher capability levels, static allow-lists for policy enforcement will need to give way to behavioral baselines and anomaly detection. The monitoring layer will need to evolve alongside the models, which means treating it as a system that requires investment over time, not a checkbox that gets completed.

The organizations best positioned for what's coming are the ones that treat their isolation stack as infrastructure they own, can inspect, and can change. Not as a vendor-managed service they access but can't see inside. The visibility and the containment both need to belong to the team operating them. That's not an ideological position. It's just what "knowing your security posture" actually requires.