翻訳待ち：A primer and taxonomy for agent sandboxes

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

All posts Sandboxing: One Word, Many Variations — A Primer for the Agent Era SecurityAI AgentsSandboxingSoftware Architecture Luke Hinds Co-founder & CEO·August 25, 2026 Sandboxing is a security technique that runs a workload1 inside a boundary that limits what it can do and what it can access. The workload can be almost anything — a full operating system under a hypervisor or microVM, an application, a browser tab, a process, or even a single function call — and under the term "sandbox" there are many different models for drawing that boundary. The breadth of the term matters, because whenever a new class of workload arrives — most recently, AI agents and the "agent sandbox" — the first instinct is to reach for one point on this spectrum and declare it the answer. Understanding what the different models actually protect is the antidote to that. A spectrum of sandboxes It's worth taking a moment to look at the spectrum of sandboxing techniques that have been developed over the years, and how they relate to each other. The following is a non-exhaustive list of common sandboxing techniques, ordered by mechanism class. The ordering is intentional: it traces an apparent gradient, with isolation strength descending as the granularity of control ascends — and it foreshadows the later point that these techniques can be combined to produce a more robust security posture than any one of them alone. Indeed, two of the most familiar sandboxes of all — the mobile app and the browser tab — turn out to be compositions of the mechanisms on the gradient rather than points on it. The microVM and hypervisor At one end of the spectrum sit hardware-virtualised sandboxes. Hypervisors like KVM or Xen, and microVMs such as Firecracker or Kata Containers, give each workload its own virtual machine with a separate kernel — this is what allows cloud providers to run untrusted code from thousands of customers on the same physical host. Containers, jails, and zones A step down in isolation strength are OS-level sandboxes: containers (namespaces and cgroups on Linux), FreeBSD jails, or Solaris zones, where processes share a kernel but see a restricted view of the filesystem, network, and process tree. Process isolation Narrower still is the sandboxed process: a single running program stripped of privileges by the kernel itself. The primitives here are seccomp-bpf, which lets a Linux process give up all but a handful of syscalls; Landlock, which restricts its view of the filesystem; macOS's Seatbelt; and OpenBSD's pledge and unveil. Because the primitives are fiddly to use directly, tools compose them into something practical — bubblewrap and Firejail wrap desktop applications, and more recently nono wraps AI coding agents, applying kernel-enforced, irreversible restrictions on what the agent process can read, write, and connect to. Notably, the "process" being confined here can be quite a high-level thing — a coding agent invoking a tool — and the granularity can follow suit: nono's broker launches each tool call as its own process under its own policy, with its own filesystem grants, network rules, and credentials, so a tool never inherits the agent's broader access. Process isolation is the lowest-overhead boundary that the kernel will still enforce for you: no VM, no container image, near-zero latency — drawn around exactly one program. In-process: language runtimes, verifiers, and WebAssembly At the fine end of the gradient, the boundary moves inside the process itself. The JVM's old SecurityManager and .NET's Code Access Security attempted in-process sandboxing at the language level, and eBPF programs are sandboxed by a verifier that proves they terminate and stay in bounds before the kernel will run them at all. WebAssembly is the model's modern flagship: a Wasm module gets a linear memory region and can only interact with the outside world through functions the host explicitly imports for it. This makes the sandbox cheap enough to wrap around a single library or function call — which is exactly how projects like RLBox use it, compiling risky C libraries (font parsers, image decoders) to Wasm so a memory-safety bug inside them can't corrupt the surrounding application. Compositions: the mobile app sandbox The best-known sandboxes are not single mechanisms from the gradient above but compositions of several. Mobile platforms are the clearest example. On Android, every app installed from the marketplace runs as its own Linux user with a private data directory, and can only reach the camera, contacts, or location through a permission system mediated by the OS. That per-app UID is only the first layer: SELinux runs in enforcing mode underneath, confining every app and system service to a mandatory-access-control domain the app cannot alter, and seccomp filters trim the syscalls an app process can make — so even a bug that bypasses one layer lands inside another. iOS works similarly with its per-app containers and entitlements. Here the sandbox isn't something the developer opts into — it's a condition of distribution: the app store model only works because users can install software from strangers with some confidence it can't read another app's data. Compositions: the browser Browsers compose across the gradient even more visibly, layering several sandboxes on top of each other. Each tab (or site, under site isolation) runs in a separate low-privilege process that can't touch the filesystem directly, while inside that process JavaScript executes within the confines of the JS engine and the same-origin policy — and risky native libraries can be confined further still behind Wasm/RLBox boundaries. Under the hood, both Chrome and Firefox assemble this from whatever the host OS provides, confining their content processes with Seatbelt on macOS, seccomp-bpf and namespaces on Linux, and restricted tokens on Windows — Firefox's multi-process split (Electrolysis, and later Fission for per-site isolation) mirroring Chromium's architecture. Document readers follow the same compositional pattern on a smaller scale: PDF and Office applications open untrusted files in restricted "protected view" processes. Sandboxing as a service More recently, the sandbox has become a product in its own right. Cloud services such as E2B, Daytona, Modal, and the sandbox offerings from Cloudflare and Vercel expose isolated execution environments through an API: call a function, get a fresh sandbox, run untrusted code in it, tear it down. These services sit at no single point on the gradient — they span it: E2B gives each session its own Firecracker microVM with a dedicated kernel, while Daytona builds on containers sharing a host kernel and optimises for persistent, stateful workspaces. The primary customers are AI systems: these platforms exist largely because agents now generate code that has to run somewhere, and that somewhere cannot be the host. The common contract What unites a Firecracker microVM, an Android app, a browser tab, and a Wasm function is not the mechanism — hardware virtualisation, kernel enforcement, process boundaries, and validated bytecode with runtime bounds enforcement are wildly different techniques — but the contract: code runs with the least privilege it needs, inside a boundary it cannot cross, so that when things go wrong — through malice, a bug, or an entirely well-intentioned mistake — the harm is limited to what the workload was ever allowed to touch. Strength is not the whole story This spectrum invites a misleading reading: that sandboxes can be ranked on a single axis from "weak" (in-process) to "strong" (hardware-virtualised), and that stronger is always better. That framing conflates two independent properties — the strength of the boundary and the granularity of what it protects. A microVM or Xen guest has an extremely strong boundary. The attack surface between guest and host is narrow, escape vulnerabilities are rare and expensive, and cloud providers rightly trust it to separate mutually hostile tenants. But the boundary encloses an entire operating system. Inside that VM, nothing is isolated from anything else: the web server, the TLS private keys, the database credentials, the image-parsing library, and the config files all live in one trust domain. If the image parser is compromised, the strong hypervisor boundary is irrelevant — the attacker is already inside it, standing next to the keys. The VM protects the host from the workload; it does nothing to protect the workload's components and assets from each other. Fine-grained sandboxes invert this trade-off. Wrapping a font parser in a Wasm/RLBox sandbox, splitting a browser into per-site processes, or confining a single process with seccomp and pledge produces boundaries that are weaker in terms of isolating the entire operating system, but far more capable and adaptable — able to carve out zero-trust paths that allow an agent, or any component, to act within a limited level of authority. The renderer that parses hostile input holds no cookies; the parser that decodes hostile fonts can't reach the network; the compromised component gains almost nothing, because almost nothing was reachable from inside its boundary. Judging a sandbox This is why grading sandboxes by isolation strength alone is misguided. The right question is not "how hard is this boundary to escape?" but "what does an attacker get without escaping?" A strong boundary around everything can be worth less than a modest boundary around exactly the right thing. Isolation strength measures the cost of crossing the fence; granularity determines what was left inside it — and a security architecture has to be judged on both. The "agent sandbox" Nowhere is this distinction more current than in the emerging notion of an agent sandbox. As AI agents have started writing and executing code, browsing the web, and operating tools on a user's behalf, a natural consensus has formed: run the agent inside strong isolation, ideally a microVM, so that whatever it does stays contained. The sandbox-as-a-service platforms above are this consensus made concrete. That instinct is sound as far as it goes. An agent executing arbitrary generated code is exactly the kind of untrusted workload hypervisor isolation was built for, and a Firecracker-class boundary is a reasonable floor for it. But it answers only one of the two questions. VM isolation addresses the escape threat — the agent (or code it ran) breaking out to the host. It says nothing about what the agent can do with what is legitimately inside its operating context. An agent is typically handed real assets to be useful: repository contents, API tokens, cloud credentials, a browser session, customer data, an email account. All of that sits inside the boundary with it, in one trust domain — the same shape as the VM whose web server, keys, and parsers all live together. And the characteristic failure mode of an agent is not a hypervisor escape; it is being manipulated, through prompt injection or poisoned tool output, into misusing its legitimate access — reading a secret it didn't need, or exfiltrating data through a perfectly ordinary outbound request. Against that threat, the strength of the VM wall is beside the point: nothing needs to cross it. Seen through the strength-versus-granularity lens, the agent sandbox problem is mostly a granularity problem. What matters is drawing boundaries inside the operating context: scoping credentials to the single task rather than the account, mounting only the files the task needs, restricting egress to an allowlist of destinations, brokering sensitive actions through an interface that can require review, and keeping untrusted content the agent reads separated from the authority it wields. None of this replaces the VM — the VM remains the right outer wall, and dismissing it would be as one-sided as relying on it alone. The point [truncated for AI cost control]