Step 1 of 4
Choose the isolation and define the policy
Decide what the boundary must hold before building it.
Design the sandbox. Choose the isolation technology available in my environment (containers via Docker/Podman are the default; microVMs or gVisor where stakes are higher; a restricted-user + namespace approach where containers are unavailable) and justify briefly. Write the policy document: FILESYSTEM - workspace mounted read-write at a fixed path, nothing else from the host; a scratch tmp; image-provided tooling read-only. RESOURCES - CPU cores, memory cap, pids limit, disk quota, wall-clock timeout per execution. NETWORK - default deny; allowlist (package registries, required APIs) with rationale per entry. LIFECYCLE - fresh or session-scoped sandbox, teardown rules. This document is the spec the next steps implement and the tests verify.
Expected after this step
An isolation choice plus a concrete policy spec.
Should not happen
- ✕Running as root with the host filesystem mounted - a sandbox in name only
- ✕No resource limits, so the host dies from a while-true the model wrote
- ✕Unrestricted network, letting exfiltration or cryptomining ride along
- ✕Sandbox friction so high that developers quietly disable it
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Running as root with the host filesystem mounted - a sandbox in name only
- !No resource limits, so the host dies from a while-true the model wrote
- !Unrestricted network, letting exfiltration or cryptomining ride along
- !Sandbox friction so high that developers quietly disable it
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The policy says 'reasonable limits'. Replace every adjective with a number (2 CPUs, 2GB, 256 pids, 120s, 1GB disk) - unquantified policy cannot be enforced or tested.