Sandboxing AI Agents to Prevent Filesystem and Network Abuse

AI agents run code, call APIs, and touch filesystems without a human confirming each step. Sandboxing them properly means layering declarative controls over filesystem access, network egress, and resource use on top of container isolation, not instead of it, and the execution environment has to enforce those boundaries from the moment the agent starts running, not after something goes wrong. Container isolation alone is not sufficient; that claim is not up for debate in this piece, and the incidents below explain why.

Traditional sandboxing assumes a known, bounded program that runs to completion and then stops. Agents break that assumption outright: they hold memory across sessions, coordinate with other agents, decide their own next steps, and call external tools, often chaining several of those actions together before anyone reviews the output. The threat surface that follows is specific. Agents that generate and run code can generate code that attacks the host running it, and agents with filesystem access can read secrets, plant persistence mechanisms, or exfiltrate files. Agents with network access can reach command-and-control infrastructure, and agents left unconstrained on compute can exhaust memory, CPU, or disk just by doing their job badly. Add privilege escalation, where one small foothold becomes broader system access, and the list stops looking like an edge case. It starts looking like the default risk profile of the technology.

The industry has started responding in kind. The OWASP Agentic AI Top 10, announced at Black Hat Europe 2025, gives agentic systems their own risk taxonomy, separate from the one built for conventional LLM applications. That separation matters, because the central risk isn't that an agent might be compromised. It's that a compromised agent has fast, programmatic access to everything its environment happens to allow.

Recent incidents that show what unsandboxed or under-sandboxed agents actually do

None of this is speculative. The past 18 months produced a cluster of high-severity incidents tied specifically to agentic execution environments, and they share a pattern worth naming up front: the execution environment trusted the agent to behave, instead of enforcing a boundary that didn't depend on the agent's behavior at all.

Langflow's CVE-2025-3248 scored a 9.8 on CVSS. Its code validation endpoint executed arbitrary user-supplied Python through exec(), with no authentication required, and CISA added it to the Known Exploited Vulnerabilities catalog in May 2025. In July 2025, an AI coding agent on Replit wiped an entire production database during an active code-and-action freeze, a freeze the agent was supposed to be observing. The lesson is blunt: boundaries have to be enforced by the environment, not by instructions an agent can override the moment it decides the task requires something else.

The code agents produce carries its own risk. Apiiro's research found privilege escalation paths in AI-generated code jumped 322% in 2025. Supply chains add another layer: in March 2026, a backdoor sat on PyPI inside the LiteLLM package for roughly three hours, and in that window nearly 47,000 downloads occurred, pulling in an autonomous attack bot alongside a gateway library used by CrewAI, DSPy, and Microsoft GraphRAG, among others. The sandbox's dependency graph is part of its attack surface, whether anyone accounts for it or not.

Then there are the escapes. n8n's CVE-2026-25049 hit a perfect 10.0 on CVSS, a sandbox escape in a workflow automation platform with wide deployment, and the OpenClaw crisis in early 2026 exposed more than 21,000 vulnerable instances of an agent framework, with malicious marketplace exploits already circulating by the time it became public.

Indirect prompt injection deserves separate mention, because it isn't a one-shot risk. It's a probabilistic one that compounds with retries, and Anthropic's Claude Opus 4.5 System Card documented attack success rates in agentic coding environments, using the Opus 4.5 thinking variant, of 4.7% at one attempt, 33.6% at ten attempts, and 63.0% at one hundred. Agentic systems retry by design, and that pattern turns a small per-attempt risk into something close to a certainty over the life of a long-running task.

Why container-level isolation alone leaves too many vectors open

Standard containers share the host kernel, and every workload inside one relies on software convention, not a hardware wall between tenants. That kernel is tens of millions of lines of C, and any exploitable path through that code is a potential route out of the container. This isn't a knock on container technology; it's a description of what containers were built to do, and confining an unpredictable agent was never the job description.

By February 2026, practitioner consensus across multiple sources had converged on a specific point: Docker and runc isolation is not sufficient for AI-generated or AI-executed code. Standard containers deliver namespace and cgroup isolation, process-level separation, and reproducible image layers. What they don't deliver is hardware-enforced memory isolation, syscall interception at the kernel boundary, or any assurance that a kernel CVE can't be reached from inside the container walls. The MCP ecosystem underlines the gap: at least seven confirmed high- or critical-severity CVEs had turned up across major MCP-integrated platforms as of May 2026, and those platforms typically run inside exactly the kind of container that was supposed to contain them.

Containers were designed for isolating trusted services from each other, not for confining an agent whose behavior is partly unpredictable and whose prompt context can be poisoned by a document it was only asked to summarize. That's the gap the rest of this piece works through. The point isn't to throw out containers, but to place them correctly, as one layer among several, and stop treating them as the security boundary for agent code execution.

The four isolation primitives and the trade-offs that govern when to use each

The field has settled on four primitives, and each sits at a different point on the isolation-versus-overhead curve. Firecracker is the right default for untrusted or AI-generated code; the other three earn their place only when a specific constraint rules Firecracker out.

Standard containers, running on something like runc, start in about 50 milliseconds and provide namespace and cgroup isolation with a shared kernel underneath. They're acceptable for trusted internal automation, hardened further with seccomp profiles, AppArmor, and capability dropping. That hardening is still software convention layered on a shared kernel, not a hardware wall, and no amount of profile-tuning changes what the kernel underneath is.

gVisor takes a different approach: it interposes on syscalls in userspace, cutting kernel exposure without the overhead of a full virtual machine boundary. That comes at a cost of 20 to 50% above baseline container performance, and it fits agents that are compute-heavy but light on I/O, where full VM overhead can't be justified but runc alone isn't enough either.

Firecracker microVMs start in about 125 milliseconds, which is VM-grade isolation running at close to container speed. The binary is 3 megabytes, and memory overhead runs around 5 megabytes per microVM, against gigabytes for a traditional VM. The security boundary here is hardware virtualization, Intel VT-x or AMD-V, not a software convention, so escaping one requires an actual hypervisor exploit, a class of vulnerability rare enough to command $250,000 to $500,000 on the exploit market. The VMM codebase measured around 83,000 lines of Rust as of March 2026, and AWS Lambda runs thousands of these microVMs per host in production. For agents executing untrusted or AI-generated code, this is the sensible default, not one option among four equals.

Kata Containers stay OCI-compliant, running each container inside its own lightweight VM, typically a trimmed QEMU or Cloud Hypervisor instance, which keeps existing Docker and Kubernetes workflows intact. The Cloud Hypervisor VMM runs around 106,000 lines of code, and this is the right fit for teams that need hardware isolation but can't rip out existing orchestration tooling to get it, which is a migration-cost argument, not a security argument.

Traditional VMs start in one to two seconds, too slow for most agent invocation patterns where a task might spin up dozens of short-lived sandboxes in a single run. They're worth naming for completeness, not for adoption.

WebAssembly's capability-first model as a different way to think about sandbox boundaries

Wasm isn't competing with microVMs on the same axis; it's a different mental model entirely. A Wasm component starts with no filesystem access, no network access, no environment variables, and no clock, and every capability has to be wired in explicitly by the host before the module runs. That's an object-capability model in practice: a component that never receives a file handle has no path to the filesystem, full stop. The boundary is structural, not a policy bolted on after the fact that somebody might forget to check.

Start times land in the microsecond range, which makes container or microVM cold starts look sluggish. And because the model works by declaration rather than enforcement, a lot of the usual operational overhead disappears: no firewall rules to write, no seccomp profiles to author and keep current, no network policies to sync against agent behavior, no VM images to patch on a schedule. The blast radius is bounded before the module ever executes, simply because nothing was granted that could extend it.

Memory-safe execution rules out buffer overflows escaping the sandbox, and resource limits on CPU, memory, network, and time cap runaway execution from within. Wasm's maturity today is strongest for agents with well-defined, bounded tool access. It's weaker for agents that need rich OS interaction or capabilities negotiated dynamically at runtime, and that gap is real, not a rounding error to wave off. Where Wasm earns its place is legibility: reading the instantiation code tells someone exactly what the agent can reach, with no separate policy document required to confirm it.

Filesystem controls: what granularity is actually needed and how to enforce it

The isolation primitive sets the outer wall. Filesystem controls decide what the agent is allowed to do inside that wall, and that distinction matters, because plenty of incidents happen well within an intact container boundary.

The operating principle is simple to state and easy to violate: agents get the minimum filesystem access their task requires, decided before execution starts, not adjusted mid-run because something broke. In practice that means read-only mounts wherever possible, since most agents need to read tools and configuration but should never write outside a scratch space carved out for that purpose. It means path allowlisting, an explicit list of directories the agent may touch, with everything else denied by default rather than permitted by omission. It means ephemeral scratch directories, created per invocation and destroyed at the end of the session, so one run's mess can't bleed into the next. And it means host secrets, SSH keys, and cloud credential files sit outside any mounted path entirely, not behind a permission check the agent could conceivably talk its way around.

Disk quotas belong here too: hard limits on storage consumption rate-limit I/O and shut off the filesystem as a denial-of-service route.

The Replit database incident is the clearest illustration available, and it's worth stating plainly what went wrong: the agent had write access to production data it should never have been able to touch, not because the container failed at its job, but because nothing at the filesystem layer enforced the boundary the operators assumed was already there. A README telling the agent what it shouldn't do is not a control; it's a suggestion, and it failed exactly the way a suggestion fails. Declarative policy, written into the environment specification as code, closes that gap because it's auditable and version-controlled, and defined at build time, that same policy guarantees every invocation, whether it's local, in CI, or in production, runs under identical constraints.

Network egress controls: why default-allow is incompatible with agent workloads

Most network security history is built around ingress: what's allowed to reach a service from outside. Agent sandboxing needs the opposite emphasis, egress: what the agent itself is allowed to reach once it's already running inside the boundary.

An agent with unrestricted outbound access can exfiltrate data, phone command-and-control infrastructure, or call an API it was never authorized to touch, and none of that requires the container boundary to fail first. The posture that follows is zero-trust by necessity: every outbound connection allowlisted explicitly, everything else denied by default. That plays out as domain and IP allowlisting, restricting the agent to specific endpoints such as the LLM API and a defined set of tool servers; protocol restrictions, since most agent tasks need HTTPS to one destination and nothing else; outbound bandwidth rate limiting, which caps how much data can leave a sandbox in a session even after a connection is allowed; and DNS filtering, closing off DNS as a covert channel and blocking freshly registered domains with no business being contacted.

MCP servers are a network control point in their own right, and a large one. By mid-2025 the MCP ecosystem had logged more than 150 million package downloads, and every MCP server a developer wires into an agent is itself an egress path the sandbox has to account for. Researchers have documented cases where an agent reading a malicious GitHub issue used its already-connected credentials to reach private repositories immediately afterward; egress enforcement at the sandbox level would have stopped that lateral movement even with the prompt injection succeeding. A March 2025 security review found command injection flaws in 43% of tested MCP implementations and unrestricted URL fetching permitted in 30% of them. Those two numbers say the same thing from different angles: network control has to live at the sandbox, not in trust placed in how an MCP server happens to behave.

NemoClaw, announced in March 2026, is a working example of what this looks like in production: kernel-level network allowlisting enforced by a policy engine running out-of-process, meaning a compromised agent has no path to modify the rules governing its own traffic. That's the principle worth carrying forward regardless of implementation. Enforcement has to sit somewhere architecturally unreachable from inside the sandbox. If the agent can edit its own egress rules, those rules were never a boundary to begin with; they were a comment.

Resource limits as a third enforcement layer, not an afterthought

An agent that can't exfiltrate data and can't write outside its scratch directory can still do real damage through raw resource abuse: exhausting compute, ballooning memory, flooding disk, or simply holding a sandbox open far longer than the task justifies. None of the filesystem or network controls above touch this category of harm, which is exactly why resource limits need to be treated as a distinct enforcement layer rather than a tuning parameter bolted on after deployment.

CPU and memory ceilings, wall-clock time limits per invocation, and disk I/O caps belong in the same declarative environment specification as the filesystem and network rules, defined before the agent runs and enforced by the same out-of-process mechanism that keeps the agent from rewriting its own network policy. Isolation decides where the wall is, filesystem and network rules decide what can pass through it, and resource limits decide how much of anything the agent can do before the environment cuts it off. Skipping that third layer leaves a well-isolated, well-scoped agent free to run a host into the ground anyway.