The Pulse
Plimsoll Reports Four Isolation Tiers for Agent-Written Code
Plimsoll reports an isolation tier for each run and lets callers set a minimum that a provider must meet before code is dispatched. Its v0.21.0 release focuses on request-bound responses, clearer pre-dispatch refusals and closing unclaimed
AI.info Team · Written with AI ·
Plimsoll describes four isolation tiers for the boundary around agent-written code: process, container, kernel and virtual machine. The open-source sandbox service reports the tier for each run, and callers can set a minimum; if a provider cannot meet it, Plimsoll refuses the job before dispatching code. Its latest listed release, v0.21.0, was published on October 9.
Four tiers, with a caller-set floor
The tiers distinguish materially different protections. Plimsoll classifies its in-process WebAssembly provider as process-level: it offers no operating-system boundary and the project warns against using it for hostile code. A Docker container using the default runc runtime shares the host kernel; using gVisor raises the reported tier to kernel. The project also supports virtual-machine providers, including E2B’s Firecracker-based service and Docker Cloud Sandboxes.
A request can specify its minimum acceptable tier. If the active provider falls short, Plimsoll returns an insufficient-isolation error and says no code ran. The official Go client checks the reported tier again when the result arrives, so an application can reject a run that does not meet its configured floor.
Release v0.21.0 tightens run accounting
The October 9 release focuses on binding responses to the requests they answer and making refusals clearer. Each official Go, Python and TypeScript client sends a request ID; the daemon returns that ID with its answer, and clients reject a response with a missing or mismatched ID. The release notes say the change addresses a failure mode in which a proxy could replay one request’s refusal for another request and make a call appear not to have run.
The release also marks certain failures that happen before the request reaches Plimsoll’s handler as “not dispatched.” That distinction matters when code may have external effects: Plimsoll warns that an error without the mark may have occurred after execution began and is not safe to retry automatically. Version 0.21.0 also closes a session that no request has claimed after its first idle timeout, rather than leaving it open for its full lifetime.
Credentials stay outside the sandbox
For approved API access, Plimsoll uses a broker outside the sandbox. A grant limits a run to specified routes on one API; the broker checks the caller and route, then attaches a per-run credential. Agent-authored code does not receive that credential, the API address or general network access, and a run without a grant has no network access.
The repository describes these controls as safeguards built into its daemon and clients. They do not amount to hardware attestation: the project says each reported tier rests on daemon configuration, provider-reported information and startup checks, not cryptographic proof of the runtime software. That limits what the tier can establish about the machine beneath a run.
The design turns isolation from a general claim into a value an application can inspect and constrain on each request. But the protection depends on the provider, its configuration and how the application handles refusals and uncertain failures. The repository’s own warning is concrete: the process-tier example has no operating-system wall, while callers seeking stronger separation must configure a provider that supplies it.