Our interpretation: a firm that lets an AI agent write and run code has to answer a plain question before go-live. The code might parse intake forms, reshape a document export or call a CRM API. How strong is the wall around it, and who checked? This article compares how three public projects document their isolation boundaries, then lays out an acceptance test a practitioner can run. It is an architecture piece. It does not rank products, and nothing here is an independent audit or benchmark.
Our interpretation: A note on evidence. Everything attributed below to Plimsoll, gVisor and Firecracker comes from short excerpts of each project's own documentation, retrieved for this review. Those are the projects' declared claims. The excerpts carried no publication dates, and I have not tested any of the three. The acceptance test and the tier-mapping reasoning are my own recommendations and hypotheses, labeled as such.
Why "it runs in a sandbox" is not an answer
Our interpretation: Code written by an AI agent is untrusted code by construction. Nobody on the team has read it line by line, and it may be regenerated tomorrow with different behavior. "It runs in a sandbox" hides a wide range of designs. A restricted process, a container, a user-space kernel and a hardware-virtualized VM are different boundaries with different failure modes. The governance question is which boundary applies, where it is declared and how it is verified.
Our interpretation: Our earlier post on agents that probably run with root permissions covered the privilege side of this problem. Isolation is the layer below it. Even with sensible permissions, you still decide what happens when the code misbehaves.
Three documented boundaries
gVisor: an application kernel in user space
According to the gVisor documentation, the project provides an isolation layer between running applications and the host operating system. It does this with an application kernel that implements a Linux-like interface, is written in Go (a memory-safe language) and runs in userspace. The documentation says the system interfaces normally implemented by the host kernel move into a distinct, per-sandbox application kernel, to minimize the risk of a container escape exploit. It also describes an OCI runtime, runsc, that integrates with Docker and Kubernetes. The project positions itself as a third approach: many of the security benefits of VMs, with a lower resource footprint and fast startup.
Our interpretation: These are design statements. The excerpt does not quantify overhead or escape resistance, so neither should a policy document.
Firecracker: microVMs on KVM
The Firecracker project page describes open source virtualization purpose-built for secure, multi-tenant container and function-based services. Workloads run in lightweight virtual machines called microVMs. These combine the isolation properties of hardware virtualization with the speed and flexibility of containers. The main component is a virtual machine monitor that uses the Linux Kernel Virtual Machine (KVM). The project describes a minimalist design that leaves out unnecessary devices and guest-facing functionality, to reduce memory footprint and attack surface. It states that Firecracker was developed at Amazon Web Services for services such as AWS Lambda and AWS Fargate, and that it has been integrated into container runtimes including Kata Containers and Flintlock.
Our interpretation: Origin at a large cloud provider is context, not proof. The page does not say how any specific deployment of it would hold up against your workload.
Plimsoll: the tier as a value on every result
The Plimsoll project describes a sandbox service. Per its own description, it runs untrusted code, such as code an AI agent wrote, inside a sandbox, and every result states how strong that sandbox was. The strength is expressed as one of four tiers, weakest first: process, container, kernel and vm. A request can set a floor, the weakest tier it will accept. If the sandbox is weaker, nothing runs. The project says its official Go client checks the tier again when the result comes back. It also describes machinery that can run an exam on agent-written code. The project describes the reported tier as configuration and startup-check evidence, not hardware attestation. This article does not cover all of its documented mechanisms.
The name borrows from the load line painted on a ship's hull, where anyone can check it. For governance, that is the useful idea: the isolation claim travels with the result as data, not as a sentence in a datasheet.
How the three relate
Our interpretation: gVisor and Firecracker describe mechanisms. Plimsoll describes a contract about reporting and enforcing mechanism strength. They answer different questions, so they are not direct competitors in this comparison.
Hypothesis, not a documented mapping: a user-space application kernel like gVisor's might sit near Plimsoll's kernel tier, and a Firecracker microVM near its vm tier. None of the three excerpts says Plimsoll makes that mapping. Confirm it in the project's own documentation before writing it into a policy.
Declared boundary versus verified boundary
Our interpretation: Three things can differ in any deployment:
- Our interpretation: The policy floor: the minimum tier your firm decided a workload needs.
- Our interpretation: The declared tier: what the runtime or service reports about itself.
- Our interpretation: The enforced tier: what the environment actually does when code tries to cross the line.
Our interpretation: Plimsoll's design narrows the gap between the first two. It makes the floor machine-readable, refuses to run when the floor is not met, and re-checks the tier on return. It cannot by itself prove the third. A label is only as good as the deployment behind it.
Our interpretation: Here is a hypothetical failure, not an observed incident. A cluster upgrade drops the stronger runtime from one node pool, and workloads quietly land on the default runtime. If nothing compares the declared tier against observed behavior, the paperwork still says the strong boundary is in place. This is why the check has to be an executable test and not a line in an architecture diagram.
A practical sandbox acceptance test
What follows is an illustrative operational example. It is my recommendation, not a procedure from any of the three projects. Run it before agent-written code touches client data, and again after any change to the runtime, node image or orchestration configuration. Use canaries (planted dummy files, dummy secrets, dummy services), never real client data.
- Recommended check: Set the floor in writing. For each workload class, name the minimum isolation tier. Code that transforms public marketing copy and code that handles matter files need not share a floor. This is a firm decision. None of the sources dictates it.
- Recommended check: Run a refusal test. Request a floor higher than the deployment provides. Expected result: nothing runs, and the refusal is clear and logged. If the code executes anyway, the test fails. This checks the fail-closed behavior Plimsoll describes, or your own equivalent.
- Recommended check: Compare the reported tier to the observed environment. Run a harmless probe inside the sandbox that reports what it can see: kernel version string, mounted filesystems, visible processes and network interfaces. A user-space kernel or a guest VM kernel should present an environment that differs from the host's, as our proposed check, to be confirmed against the actual runtime configuration. Confirm the exact expectation in the runtime's documentation. If the probe sees host details you did not expect, treat the declared tier as suspect.
- Recommended check: Probe the boundaries you care about with canaries. Plant a canary file outside the working directory on the host, a canary value in the host's environment variables, and a canary listener on an internal network address. Run test code that tries to read or reach each one. Pass means every attempt fails and each is logged.
- Recommended check: Bound the resources. In staging, run a small program that tries to exceed its memory, CPU time and wall-clock limits at modest levels. Pass means it is stopped at the limit and the host is unaffected. This is a limit check, not a stress test of shared infrastructure.
- Recommended check: Inspect the result record. Every execution should produce a record containing the tier, the runtime version and the policy floor that applied. Confirm that downstream systems re-check the tier instead of trusting the first hop. Plimsoll's client-side re-check is one example of that pattern.
- Recommended check: Pin the version and re-run on change. Log the runtime version under test. Any upgrade, node-pool change or configuration edit triggers the test again, and the dated output is kept.
Recommended check: Scoring is binary per step. A single failure means that workload class does not get that tier until the cause is fixed and the test passes again.
What to put in front of a managing partner
Recommended check: Three artifacts are enough: the written floor for each workload class, the most recent dated acceptance test output, and the list of people who can change runtime configuration. That is governance a reviewer can inspect, as opposed to governance that depends on trusting a vendor slide.
Recommended check: I am not citing a specific professional-conduct rule here. Confidentiality and supervision duties vary by jurisdiction, and counsel should map them to this evidence. The test above produces the facts that mapping needs.
What this analysis does not establish
- Our interpretation: It does not show that any of the three projects resists a particular attack. The sources are each project's own description, and I did not run benchmarks or audits.
- Our interpretation: It does not recommend one mechanism. The right tier depends on your threat model, your workloads and your operating capacity.
- Our interpretation: It does not say any firm is exposed today. Whether yours is depends on a basic inventory: where AI-written code runs now, under what runtime, and with access to what.
Our interpretation: The takeaway for implementers is that an isolation claim should be a value you can demand, a value you can refuse to run without, and a value you can test. If the sandbox's strength lives only in a sentence in a datasheet, the first time anyone checks it may be after something has gone wrong.