For newcomers · 1 of 2

What a sandbox is

Someone hands you a program and says "run this for me". You did not write it, and you are not going to read all of it. It is probably fine. Most code is. This page is about the rest, and about how plimsoll tells you which precautions a given run actually got.

Running code you did not write

A program you run acts as you. It can read the files you can read, send what you can send over the network, and use as much memory and time as the machine will give it. That is the deal with every program on your computer, and it works because you chose those programs.

More and more code comes from nobody you chose. An AI agent, a program that uses a language model to decide what to do next, writes a few lines to answer a question and wants them run. The model may simply be wrong. It may have read a web page with instructions planted in it, a trick called prompt injection: instructions hidden in data a model reads, written so that the model follows them. Either way, the code that arrives is a stranger's code, and you are about to let it act as you.

A sandbox is a place where code runs with something stopping it from reaching the rest of the machine. Think of a room in your house set aside for a visitor: you let the stranger in, but only into that room, and the door locks from the outside. plimsoll's documentation even calls the stranger's code the guest: the code running inside a sandbox, seen from the machine that runs it.

Rooms differ in their locks, and that is the whole subject of this page. plimsoll calls the strength of the lock the isolation tier: how strong the wall around a run is, one of four levels, weakest first: process, container, kernel, vm. plimsoll does not build the rooms itself. It is the doorman in front of them: it checks each request, sends it to the one kind of room it was set up with, and writes on every answer which kind of room that was.

Five strangers in the cheapest room

On 2026-11-05 a plimsoll server, plimsolld, was started on a laptop with the setting SANDBOX_PROVIDER=wasm. The provider is the backend that actually runs the code, and each server uses exactly one. wasm is the cheapest room plimsoll has: JavaScript runs on QuickJS, a small JavaScript engine, compiled to WebAssembly, a portable bytecode format that runs inside a host program, which decides everything the code can reach. Here the host program is plimsolld itself.

Five short JavaScript programs were sent to it, four of them behaving the way a badly behaved stranger might, and a sixth from a careful caller. What each card shows came back from the server unedited; it is read from the signed recording published beside the next page (INTERNAL · plimsoll site →), which also shows how to check it.

{
  "protocol": 5,
  "minimumIsolation": "kernel",
  "javascript": {
    "code": "console.log(\"hello\");\n"
  }
}

plimsoll-attest: refused before dispatch (reason isolation), so nothing ran; the bundle is unchanged: sandbox isolation requirement not met
failed_precondition: sandbox isolation requirement not met: provider isolation process is below requested minimum kernel

Four rooms, four locks

Each provider restricts memory, run time, files and network access. For providers whose walls depend on the host or a remote service, a startup test checks the promised restrictions; the in-process wasm provider relies on the project's own tests. (A run can be given one narrow exception, a grant: permission, attached to one run, for its code to call listed routes of one HTTP API through plimsoll, which adds the credential itself, so the code never sees it.) Where rooms differ is what happens when the lock itself has a bug. The picture puts each room where its escape would land.

There is a fifth setting, and it is the default: no room at all. With SANDBOX_PROVIDER unset, plimsoll runs nothing and says so. The front door stays bricked up until somebody chooses a room on purpose.

The other rooms are not drawn from imagination. On 2026-09-28 the same program, one that balances a simulated pole on a cart, was sent to five rooms with nothing changed but the provider setting, and each answer stated its room. One of them was a sandbox from OpenShell, NVIDIA OpenShell, an agent sandbox runtime whose gateway server creates and deletes sandboxes on request (same run, different sandboxes (INTERNAL · plimsoll site →)):

All five produced the same result, byte for byte. The process room was not in that recording: it runs single snippets, and that program is a project with several files.

The sign on the door

Every answer above says process. Where does that word come from? Not from an inspector. It is plimsoll's statement, assembled from what it can check, and it is worth knowing exactly what goes into it.

Think of a hotel. The hotel set the room up, checked at opening time that the deadbolt turns and the window does not open, and prints "deadbolt" on your bill. That is worth a good deal more than a brochure. It is still the hotel's word: nobody from outside inspected the lock this morning, and nothing on the bill would change if someone swapped the lock after opening time.

The exact term for the inspector's certificate is attestation: cryptographic proof, usually rooted in the hardware, of exactly what software a machine is running. plimsoll does not have it, and says so wherever it reports a tier. Concretely:

• kernel on docker rests on docker's own registration of the runsc runtime, checked by the preflight (the configuration check a provider runs at startup and on each readiness poll), plus the smoke test. The code says in so many words that this is not proof that the wall actually running is gVisor (sandbox/docker_preflight.go (EXTERNAL · source repo ↗)).
• vm on E2B and Docker Cloud Sandboxes follows from which service it is. Their smoke tests prove the microVM behaves as promised, network blocked included; they do not prove a hypervisor is there.
• process, the runs on this page, has no smoke test at all, because its walls are library code built into plimsolld and the same on every machine. The project's own tests prove the memory cap and the missing network functions, and at startup the wasm provider only reads its settings.
• If the machine is changed after startup, or plimsolld itself is taken over, the sign can be wrong. A compromised server can state anything.

The full account, provider by provider, is docs/isolation-tiers.md (EXTERNAL · official docs ↗). If the attacks you must hold out against need attestation, no room here supplies it.

What this page does not show

• The other rooms, tonight. Only the process room ran for this page. The other rooms' tiers come from the 2026-09-28 recording linked above.
• That the code's answer is right. A sandbox limits what wrong code can damage. It does nothing to make a wrong answer right.
• An attack on the engine. The strangers tried the doors, not the hinges.
• Proof of the room. Every tier here is plimsoll's statement from its settings and its checks, never attestation.

Next: the receipt

Every answer above came with a run record (INTERNAL · glossary →), plimsoll's written statement of what was sent, what came back and which room ran it, and the five were signed into one file as they came back. The next page shows what is on a run record, why the client checks it, who signs it and what it cannot prove, and lets you check these five in your browser.

• Proof of what ran (INTERNAL · plimsoll site →): the signed records of the five runs on this page.
• Plain English (INTERNAL · trainer site →): the same walls as an interactive cross-section, and the words decoded.
• Concepts: read the mark, not the name (INTERNAL · trainer site →): each tier with its real checks.
• What plimsoll does not do (EXTERNAL · official docs ↗): the limits, stated plainly.