Sandbox Untrusted Code Execution

The route

4 steps to Done

1. 01

   Choose the isolation and define the policy

   Decide what the boundary must hold before building it.

   Preview prompt + verify gate ▾ Hide ▴

   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.

   • ✓ Technology fits the environment and stakes
   • ✓ All four policy areas specified with numbers
   • ✓ Allowlist entries individually justified
2. 02

   Build the sandboxed executor

   Same tool interface, contained blast radius.

   Preview prompt + verify gate ▾ Hide ▴

   Implement execution inside the sandbox. Build the execution image: base OS plus the project's toolchain (pin versions). Reimplement run_command to execute inside the sandbox: workspace mounted per policy, limits applied (cpus, memory, pids-limit, read-only rootfs where workable, no-new-privileges, non-root user), timeout enforced, stdout/stderr captured and returned with exit codes exactly as before. Session-scoped sandbox reuse for speed (create at session start, execute via exec, destroy at end) with a fresh-sandbox option for suspicious operations. The agent-facing tool interface stays identical - the containment is transparent. Verify normal development commands (install, test, build) work inside.

   • ✓ Limits and non-root enforced on the container
   • ✓ Interface unchanged for the agent
   • ✓ Session reuse keeps latency acceptable
3. 03

   Enforce and verify the network policy

   Default-deny, with every exception named.

   Preview prompt + verify gate ▾ Hide ▴

   Implement network policy. Default: no egress (network none, or an internal network with no route out). Where the workflow needs egress (package installs), route through the allowlist mechanism available: a filtering proxy the sandbox must use, or network rules permitting only named destinations. Failures at the boundary must produce a distinguishable error the agent can read ('network blocked by policy: destination X not allowlisted') so the model reports it rather than flailing. Log every blocked attempt as a security event with destination and context. Test: package install from an allowlisted registry succeeds; a curl to an arbitrary host fails with the policy error; the blocked attempt appears in the security log.

   • ✓ Non-allowlisted egress fails distinguishably
   • ✓ Allowlisted flows work
   • ✓ Blocked attempts logged as security events
4. 04

   Attack it, then tune the ergonomics

   Trust the boundary only after it has survived you.

   Preview prompt + verify gate ▾ Hide ▴

   Verify with attacks, then smooth the workflow. ATTACKS (run each inside the sandbox and verify containment plus logging): rm -rf / (host untouched), read attempts on host paths (/etc/passwd outside the mount - invisible), a fork bomb (pids limit kills it), a memory hog (cgroup kills it), a wall-clock runner (timeout fires), and egress to a random host (blocked). After each, verify the agent received a comprehensible error and the security log recorded the event. ERGONOMICS: measure the overhead (execution latency vs host baseline) and fix the frictions that tempt people to disable sandboxing - warm session sandboxes, cached package layers in the image, fast file sync. Document the final guarantees and the residual risks (kernel exploits, allowlisted-destination abuse) honestly.

   • ✓ Six attacks contained with evidence
   • ✓ Agent errors comprehensible for each
   • ✓ Overhead measured and reduced where hostile to adoption

Research-backed

Sources behind this flow