Getting started

Playground guide

Understand the interactive examples, compile a policy locally and interpret every result.

Before a sandbox can enforce anything, somebody must answer three practical questions:

Which files may the program read?
Which files may it change?
May it communicate outside the sandbox or create child processes?

The JSON manifest is that answer. It does not contain executable code and it does not launch anything. It is a strict, reviewable description of the boundary Warden must later enforce.

Start from a task, not from syntax

The workshop provides four starting points:

Use case	Boundary demonstrated
Build a project	read the source, write only build output, no network
Audit source code	read the project, hide sensitive metadata, change nothing
Install dependencies	write selected directories and reach only approved registries
Run a generator	protect source files while allowing one generated output tree

Choose the task closest to yours, then read the manifest as a sentence: deny everything by default, open only these paths, choose this network posture, keep the process tree confined.

The four parts of a manifest

CODE

formatVersion   selects the strict source language
filesystem      says what may be read, written or explicitly hidden
network         disables access, mediates named destinations, or allows direct access
process         states whether children must remain confined

Paths normally use symbolic roots such as workspace and temp. Warden binds those names to real directories only when it prepares an execution. This is why one compiled decision can be used across different machines and sandbox backends.

Try the complete pipeline

POLICY WORKSHOPDescribe the boundary before the program starts

Loading runtime

Choose a familiar task, inspect the permissions it needs, then compile a policy you can enforce.

Build limits

document=1 MiB
filesystem rules=4096
path bytes=4096
network destinations=1024
hostname bytes=253
json depth=32

Use case

Read the project and write only to a prepared build directory, without network access.

Policy sourceJSON

{
  "formatVersion": 2,
  "filesystem": {
    "default": "deny",
    "rules": [
      {
        "access": "read",
        "path": { "special": "minimal-runtime" }
      },
      {
        "access": "write",
        "path": { "root": "workspace", "relative": "build" },
        "missing": "error"
      },
      {
        "access": "deny",
        "path": { "root": "workspace", "relative": ".env" },
        "missing": "skip"
      }
    ]
  },
  "network": { "mode": "none" },
  "process": { "treeConfinement": "required" }
}

Compiled decisionreadable / binary

Your boundary is ready to reviewCompile it to see the normalized decision and download the portable policy file.

Understand the result

After compilation, the right-hand panel exposes three views of one decision:

Result	What it tells you
Readable decision	the normalized permissions that survived validation
Binary policy	the exact portable bytes handed to Warden
Decision fingerprint	the SHA-256 identity of those exact bytes

The readable view may reorder entries, lowercase hostnames and remove duplicates. That is expected: many equivalent JSON spellings become one decision.

The downloaded policy.mir is the normative artifact. The readable JSON is an inspection view and never becomes a second policy identity.

What happens inside the browser

The same C11 compiler used by the native CLI is compiled to WebAssembly. It validates the manifest and produces MIR. A small dependency-free TypeScript implementation independently parses those bytes, checks canonical ordering and recomputes their digest.

Nothing is uploaded and no policy service is contacted.

Continue learning

Quickstart compiles and enforces a first policy locally.
Concepts explains the complete source-to-enforcement pipeline.
JSON manifest reference documents every field.
MIR binary format specifies the downloaded file byte for byte.