READMEs are untrusted code. readme2demo executes them, so isolation is a core design concern, not an afterthought.
The agent and verify stages run inside hardened Docker containers (Sandbox.start()):
--cap-drop ALL and --security-opt no-new-privilegesUSER demo in the base image)The verify stage then replays the distilled commands.sh in a separate,
fresh container with no model credentials and no state carried over from the
agent’s run.
For a claims-vs-roadmap table (enforced today vs planned v0.8 vs known
limitations, each with code pointers), see the root
SECURITY.md. That table is the source of truth; this page
is the short summary.
Render container is not fully hardened like agent/verify. render.py runs
its own docker run with memory/CPU/network limits only (no cap-drop /
no-new-privileges / pids-limit). See the root SECURITY.md table.
docker run argv). Use a dedicated, low-limit key. A
host-side, key-injecting egress proxy is planned so the credential never
crosses the boundary (#64;
argv exposure tracked in
#51).--allow-docker-socket is off by default. Enabling it mounts the host
Docker socket into the sandbox so demos that manage containers work — but the
socket pierces isolation. Only enable it for repositories you trust.--network bridge so package installs and git
clones work. Domain allowlisting is planned for v0.8 (#64). Until then,
treat outbound network from a compromised agent as possible.Please report vulnerabilities privately, not in public issues. See
SECURITY.md
in the repository for the full threat model and the private reporting channel
(GitHub Security Advisories).