Plimsoll: self-hosted sandbox stamps every AI agent code run with its isolation tier

A sandbox that states its own strength

Plimsoll, a self-hosted sandbox for executing untrusted code written by AI agents, was announced on Hacker News on October 12, with the project published on GitHub. Its distinguishing idea is that every execution result carries a machine-readable value describing the isolation boundary the run actually used, and a caller can demand a minimum strength before a single instruction executes.

The name is borrowed from the Plimsoll line, a load-limit marking on ship hulls that lets any observer see at a glance whether a vessel is overloaded. The project applies the same principle to isolation: strength is a first-class, per-run property rather than a claim buried in a datasheet.

Four tiers with a caller-set floor

According to the project's GitHub page, isolation strength is expressed as one of four tiers, weakest first: process, container, kernel and vm. A request may specify the weakest tier it will accept; if the sandbox cannot meet that floor, the run is rejected up front with an error (ErrInsufficientIsolation) and no code executes. The official Go client re-verifies the reported tier when the result returns, so the guarantee is checked on both sides of the call.

The project is candid about the limits of this evidence: the tier reflects the daemon's configuration and its own startup checks, not cryptographic attestation from hardware about what software is running, and no bundled provider offers that.

Refusals you can safely retry

Telling "nothing ran" apart from "it ran and then failed" matters for automation, and Plimsoll marks every refusal that ran nothing with a reason, such as request, permission, protocol, isolation, environment or capacity. A helper function reads the mark whether the backend runs in-process or behind the daemon. Errors without the mark may have occurred after the code started, so the project warns they are never safe to retry automatically. The mark also only counts on an answer that carries the client's own request ID, which stops a proxy from relabelling a call that did execute as one that never dispatched.

Runs additionally return SHA-256 hashes of the request as sent and the result as returned, which the official clients recompute. A separate program outside the daemon, plimsoll-attest, signs the checked results, rejects a chain of calls that is missing one, and can replay a run.

Credentials that never enter the sandbox

Plimsoll also tackles the problem of agent-written code calling external APIs. A grant gives one run permission to reach listed routes of a single API. Sandboxed code invokes a small client placed inside the sandbox, while a broker running outside it validates the caller and the exact route, then attaches a fresh, short-lived, per-run credential itself. Because the broker rather than the in-sandbox client enforces the rules, code that bypasses the client and calls out by hand gets no further, and the credential never crosses the boundary.

An exam, not just a container

The same machinery can evaluate agent code rather than merely contain it. A trial runner built into the simulation image executes an agent's program against scenarios that program cannot read, each delivered in a file deleted before the run starts. In the published demo, an AI agent wrote a controller for a simulated cart-pole, with the simulator compiled to WebAssembly inside the sandbox image, and Plimsoll hashed each run's full trajectory into a SHA-256 fingerprint. The agent's first draft, containing two control gains with the wrong sign, dropped the pole at 5.96 seconds and produced a fingerprint that differed from the accepted controller's.

Integration and a one-minute start

Client packages exist for Vercel AI SDK, Google ADK, Agno, CrewAI, Trigger.dev and Mastra, each handing a model's code to Plimsoll through a tool or code executor. A minimal example needs no daemon, Docker or credentials: it uses a wasm provider running JavaScript on QuickJS inside the caller's own process. That path reports the process tier, which the project warns has no operating-system wall at all and should not be used for hostile code; installing gVisor, a layer that intercepts a container's kernel requests, lifts the same snippet to the kernel tier.

Why it matters

Agents that write and immediately execute code are now routine, and the security question is usually "was it sandboxed?" rather than "how strongly, provably, this time?". By turning isolation strength into a per-run, checkable value with enforced floors, honest refusal semantics and hashed receipts, Plimsoll makes sandboxing an explicit contract that an agent pipeline can depend on. It is not hardware attestation, and the project says so plainly, but as a composable primitive for orchestrating model-generated code it fills a gap most agent stacks currently paper over with assumptions.