A walkthrough · @ruvector/rvforge
A sandbox limits what a running process can touch. It does not govern the whole agent — who made it, what model it carries, what it remembers, what it is allowed to do, or what it has already done. This page explains the difference in plain language, then walks eight commands that put a boundary around all of it.
Start here
Imagine hiring a contractor and locking every room in your house except the kitchen. That is a sandbox: it constrains where they can go while they are working.
It does not tell you who they are, whether their tools were swapped out on the way over, what they wrote down about your house, who else gave them instructions, or what they did on their last three visits.
An agent is not just a running process. It is a bundle: code, a model, memory, tools, a policy about what it may do, and a history. A sandbox covers exactly one piece of that bundle — the part executing right now.
This barely mattered when agents were throwaway chat sessions. It matters a great deal once an agent is downloaded from somewhere, keeps state, and runs for days.
The useful question is not “what may this command touch?” It is: may this exact agent, carrying this exact state and history, do this exact thing — and can we prove afterwards what happened?
The shape of the answer
Rather than one large security feature, the work splits into three jobs happening at three different times: packaging the agent, governing it before it runs, and governing it while it runs.
The thread running through all three is a single number — the SHA-256 digest of the packaged bytes. It is recomputed at every checkpoint, and it either matches or it does not.
The package
A signed container. Code, model, memory, tools, policies, checkpoints and history travel together under one cryptographic identity, instead of as loose files that drift apart.
Before it runs
Authors and validates the container without executing it, checks signatures, applies default-deny capability policy, builds signed installers, records provenance, and chains a receipt across every step.
While it runs
Verifies the artifact, creates an isolated partition, grants only explicit revocable capabilities, and makes every privileged action pass a capability, policy, proof and quota check.
The walkthrough
Follow the panel on the left. It fills in as the artifact acquires its identity, tracks that identity through packaging and execution, and turns red in the final step when we destroy it deliberately.
STEP 01 — IDENTITY
Every release must be attributable to someone. This generates an Ed25519 signing key and a capability policy that is default-deny — nothing is permitted until you write it down explicitly.
STEP 02 — AUTHORING
This is the step that turns a directory into an agent. Each piece becomes a segment with its own hash; the segment table becomes a root manifest; the manifest is signed with the key from step 01. From here on, the artifact has an identity that travels with it.
STEP 03 — INSPECTION
This walks the container's segment table and recomputes digests, and at no point runs anything inside it. That property is what makes pointing this at a hostile artifact safe by construction rather than safe by luck.
STEP 04 — EVIDENCE
The second five are where behaviour becomes observable: install it cleanly, run the same input twice and compare, watch what it dials, starve it of resources, and confirm the receipts it emits match what it actually did.
STEP 05 — PACKAGING
Embedded mode stages the same RVF bytes into every target and re-hashes each copy; if any diverged, the build fails rather than shipping. Thin mode ships a small signed pointer bound to the same canonical identity, so the download is small but the artifact is unchanged.
STEP 06 — CUSTODY
Each authoring, build, verification and publication appends a receipt containing the hash of the one before it. Removing or editing any link breaks every link after it, so the chain either reconstructs cleanly or it visibly does not.
STEP 07 — EXECUTION
Every privileged action passes four checks in order: is the capability held, does policy allow it here, does the proof verify, is it within quota. A refusal is not a silent no-op — it is recorded, so a compromised agent's attempts are visible afterwards rather than inferred.
STEP 08 — THE POINT
This is the whole idea compressed into one command. Identity is not a label attached to a file — it is a value recomputed from the bytes every single time. There is no check to bypass and no policy to argue with; the number simply no longer matches what was signed.
Reference
Each one appends to the same witness chain, so the sequence itself is reconstructable from the artifact afterwards.
| Command | What it does | Executes the agent? |
|---|---|---|
init --keygen | Publisher identity and a default-deny policy | no |
create | Seals code, model and policy into one signed artifact | no |
validate --deep | Structure, segment hashes, signature | no |
test | Five checks by inspection, five in a disposable partition | in quarantine only |
build | Signed installer per platform, inventory, provenance | no |
verify | Re-checks a build and its receipt chain from the outside | no |
submit | Publishes to the registry and the transparency log | no |
rvm run | Verifies, partitions, grants, gates and witnesses | yes — gated |
The model can remain probabilistic.
The authority boundary cannot.