Plimsoll: open-source sandbox that states its isolation tier

Plimsoll is an open-source daemon, written in Go and released under Apache-2.0, that runs untrusted code, such as code an AI agent wrote, inside a sandbox and reports how strong that sandbox was. Its author, posting as cagster, introduced it as a Show HN on 11 October 2026. It had 16 points and three comments at the time of writing. Everything below is the author's description in the GitHub README and the thread, not an independent test.

What it does

The name comes from the load line painted on a ship's hull. Plimsoll applies the idea to isolation: every result states one of four tiers, weakest first, as a value on the result. The README defines them as process, container, kernel and vm.

• Process: JavaScript on QuickJS compiled to WebAssembly, inside the daemon itself. The README says there is no operating-system wall and not to use it for hostile code.
• Container: Docker with the default runc runtime, sharing the host kernel.
• Kernel: Docker under gVisor (runsc), which handles the container's system calls itself.
• VM: a microVM from E2B (running on Firecracker) or from Docker Cloud Sandboxes, both billed per run.

A request can set a floor, the weakest tier it will accept. If the daemon cannot meet it, the request is refused before any code runs and the caller gets an error that means nothing ran. The README says the tier is evidence from the daemon's configuration and startup checks, not hardware attestation.

Credentials the code never sees

The second feature is a broker. A grant lets one run call listed routes of one API. The code calls through a small client inside the sandbox, and the broker, outside it, checks the caller and the exact route and attaches the credential itself. The README says the credential can be minted fresh per run and never enters the sandbox, and that a run with no grant has no network at all.

Spend limits and records

In the Hacker News post the author says each caller can get a daily allowance of microVM seconds, so an agent that loops forever runs out and the next run is refused before it starts. The README adds that every run returns SHA-256 hashes of the request and result, which the official clients recompute, and that a separate tool signs and replays records.

The limits the author states

• Pre-1.0, single author and no external users yet; breaking changes land without a deprecation path.
• No third-party security audit has ever been performed.
• The CI suites for E2B and Docker Cloud Sandboxes are deliberately never run, because they drive live paid services.
• Sessions that keep one sandbox across calls trade a fresh sandbox per call for speed, and a service running many customers' code must keep each customer in their own session.

The pushback

The one question in the thread came from wanderingbit, who asked how it compares with a remote SSH sandbox service such as exe.dev plus a credential-injecting reverse proxy, and said that combination looked sufficient for keeping agents away from personal data. The author replied that Plimsoll is for running code on behalf of agents or MCP servers, not for running the agents, and said they would avoid SSH agent forwarding because anything in the VM could use the laptop's SSH keys while connected. The thread has no independent testing of Plimsoll.

What a team can take from it

Whether or not you use this project, the pattern is checkable: make the isolation level a field on every execution result, let the caller set a minimum, and fail closed. Ask your own code-execution vendor whether it can do the same, and whether the credential is ever inside the sandbox. Treat a pre-1.0, unaudited project as a design to learn from, not a control to rely on.