Trust & security

Nothing runs until the sixth stage

An uploaded bundle is a stranger's code. The first five stages read it, measure it and refuse it without executing any of it — and that is a property with a test behind it rather than a promise in a document.

The six intake stages

Stage 6 is the first that executes an uploaded byte. The five before it do not.

01 · Receive: Oversized bundles, and git URLs pointing at private or metadata addresses.
02 · Unpack: Path traversal, symlink escape, setuid entries, zip bombs, duplicate members.
03 · Structure: A bundle missing instruction.md, task.toml, tests/test.sh or a Dockerfile.
04 · Normalise: A verifier the agent could reach, and resources above the tier.
05 · Scan: Docker sockets, credential reads, remote code loads, tests leaked into the agent image.
06 · Build — first execution: Anything that will not build rootless, behind an allowlist, pinned by digest.

The claim has a test, not a paragraph

`intake-no-exec.test.ts` walks the import graph of stages 1 to 5 and fails if anything reachable from them can reach child_process, vm, eval or a dynamic import. A property asserted by a test is one that cannot quietly stop being true.

Why it is a graph walk: Reading the five stages by eye proves nothing about the twentieth module they import. The test follows every edge, so a dependency added later is caught by the test rather than by an incident.
What that buys a lab: A bundle that is refused was never executed. The cheapest place to learn a task is unusable is before anything has run, and that is where most refusals happen.

Where it runs once it does run

Stage 6 and every trial after it.

Rootless builds: Images are built without a privileged daemon, on an isolated pool, from a context that is the task's own directory and not the repository root.
Egress denied by default: A trial reaches nothing it was not granted. The build is the one stage allowed network access by design, and it is restricted to a registry allowlist.
Pinned by digest: Every image a trial uses is addressed by sha256, so what ran is identifiable after the fact rather than inferred from a tag.
The verifier is separate: The container that writes the reward is not the container the agent worked in, so an agent cannot rewrite the thing that scores it.