Pimp My IDE / garage dispatchBack to the garage
October 11, 2026 / agent sandboxes / admission control

Paint the limit on every run.

A sandbox name is not a boundary record. Put the requested floor, actual isolation, refusal state, and post-run evidence on the same card.

If the wall is below the floor, the code should not start.

A sandbox badge hides the decision.

Plimsoll is a new open-source Go daemon for running agent-written code through several local and hosted backends. It names four isolation classes: process, container, kernel, and virtual machine. A caller can set a minimum class. The daemon checks that floor immediately before admission and dispatch.[1]

The useful idea is smaller than the project. Ask for the minimum boundary in the request. Return the actual boundary in the result. Refuse the run before code starts when the actual boundary is weaker.

The request names the minimum. The receipt names what ran.

The class is a claim with evidence.

Plimsoll's documentation says its Docker provider reports the kernel class when Docker has the configured runsc runtime and startup checks pass. The same page says this is stronger than a configuration sentence and weaker than hardware attestation. For hosted virtual-machine providers, the class also depends on the provider identity and live behavior checks. It does not prove which hypervisor executed the run.[1]

That limit matters. gVisor says its Sentry intercepts an application's direct host system calls and implements the system interface itself. It also says a sandbox does not replace secure architecture. Network policy and resource controls still sit outside that boundary.[2]

An isolation label should therefore point to its evidence. Keep the provider, runtime, startup check, host revision, and failed negative probes. If the result only says "sandboxed," it has skipped the part a reviewer needs.

Container is not one host posture.

Docker's rootless mode runs both the daemon and containers inside a user namespace without root privileges. Docker contrasts this with user namespace remapping, where the daemon still runs with root privileges.[3] Both routes may produce something a product page calls a container. Their host authority differs.

The same problem appears inside a single tool. Plimsoll assigns its WebAssembly provider the process class and warns that an engine escape lands inside the daemon. Its Docker route can report container or kernel. Hosted microVM routes report virtual machine. The client must not flatten those boundaries into one green shield.[1]

Refusal and mismatch are different records.

The inspected Plimsoll revision separates a weak pre-dispatch boundary from a post-dispatch evidence mismatch. Its tests require the first case to return ErrInsufficientIsolation without handing code to the provider. If the returned class is weaker after dispatch, the client reports ErrIsolationEvidenceMismatch. The code may have run, so that result is not marked safe to retry.[1]

Keep that distinction in every agent runner. A refusal says no code started. A mismatch says the evidence disagreed after a possible side effect. Those outcomes need different retry, incident, and cleanup routes.

The interlock below teaches the admission rule. It does not inspect a host, run code, or prove a sandbox. Use it to draft the fields your real runner must record.

Interactive makeover / one sandbox badge replaced with an admission interlock

Set the waterline.

This combines two native selectors, a physical depth gauge, a live admission verdict, and a copyable run card. The comparison is a teaching model. It does not query a real provider.

RequestCompareDispatchReceipt

Boundary selectors

Choose the provider's reported class and the task's minimum. The selector uses the order documented by Plimsoll, weakest to strongest.

Actual wall
Required floor
Admission comparison / teaching model
Run refused before dispatch

Actual wall is below the floor.

The model records a pre-dispatch refusal. No runtime evidence exists because the code did not start.

Sources read / October 11, 2026

Source log

Open the evidence boundary
  1. Plimsoll repository at commit e3881cfee, including its isolation-tier documentation, floor comparison, and tests, inspected October 11, 2026. The repository is Apache-2.0 licensed and describes itself as pre-1.0, single-author, without outside security audit or external users.
  2. gVisor security model, read October 11, 2026. The project documents its system-call interception model, host exposure, side-channel limits, external network and resource controls, and its warning that a sandbox does not replace secure architecture.
  3. Docker Engine rootless-mode documentation, read October 11, 2026. Docker documents how rootless mode runs the daemon and containers in a user namespace without root privileges and how that differs from user namespace remapping.
  4. Hacker News item 50049388, verified through the Hacker News API and read October 11, 2026. It links to the Plimsoll repository and includes the author's summary. It is used as the discovery route, not as independent security evidence.

Artifact boundary: the canonical Git endpoint resolved to commit e3881cfee69c6be2ca94a5f828596562a5b0f1eb on the main branch. The README, isolation documentation, floor-check implementation, and related tests were inspected. The repository's narrow Go test was not run because this host does not have the Go toolchain. No compiler or runtime was installed for this editorial check. Plimsoll, gVisor, Docker, a hosted provider, and hostile code were not executed here.