Smolmachines is putting a name and clear pattern to something every AI team needs: running agent actions in an “untrusted sandbox.” Simon Willison’s write‑up is the best fast read on why this matters and how to think about it (source).
What is the “untrusted sandbox” pattern?
Treat any code an LLM writes or any tool it calls as hostile by default. Execute it in a short‑lived, heavily restricted environment with minimal privileges, no implicit network, and strict resource limits. Communicate via well‑defined, auditable message passing—never via shared process state or long‑lived permissions.
- Ephemeral by design: new sandbox per task; destroy on completion or failure.
- Default‑deny networking: off by default; allowlist specific domains/ports if truly needed.
- Filesystem isolation: read‑only base; write only to a scratch dir purged after run.
- Least privilege: drop Linux capabilities; run as non‑root; narrow Syscall surface (e.g., seccomp).
- Hard quotas: CPU, memory, file size, open FDs, and wall‑clock time limits.
- Secret hygiene: no long‑lived creds inside the sandbox; scoped, time‑bound tokens only if required.
- Complete auditing: capture prompts, tool inputs/outputs, stdout/stderr, artifacts, and policy decisions.
Why this matters now
Agents can write code, call tools, and touch data or services you care about. Without isolation, you risk data exfiltration, runaway costs, and supply‑chain compromise. This aligns with emerging guidance like the OWASP Top 10 for LLM Applications, which emphasizes strict isolation and least privilege.
- Reduces blast radius if a prompt goes off the rails or a dependency is malicious.
- Creates clean audit trails for compliance and incident response.
- Enables safe iteration: you can let agents try more without risking core systems.
- Controls spend via time/IO/egress limits.
How to implement it today (quick start)
- Run each agent action in an isolated worker: a container or microVM you can throw away.
- Choose isolation tech fit for risk: rootless containers with seccomp/AppArmor, or stronger sandboxes like gVisor or Firecracker microVMs.
- Default‑deny egress; maintain a tight domain allowlist per tool. Monitor and log DNS + HTTP(S) metadata.
- Mount a read‑only root; give a tmpfs scratch dir; block device mounts and privilege escalation.
- Apply cgroup limits for CPU/mem; cap file sizes and number of files; enforce wall‑clock and idle timeouts.
- Pass inputs via JSON; validate against schemas; sanitize outputs; bound result sizes.
- Keep secrets out: inject only short‑lived, scope‑limited tokens when strictly necessary.
- Record everything: prompts, tool specs, decisions, diffs, and artifacts for replay and forensics.
Design tips for agent tool interfaces
- Small, single‑purpose tools with explicit capability lists (read‑only vs write, network domains, data scopes).
- Deterministic CLIs with JSON in/out; versioned schemas and strong input validation.
- Predictable resource footprints; declare and enforce quotas per tool.
- Human‑in‑the‑loop gates for high‑impact actions (payments, prod writes, external emails).
- Make runs reproducible: pin dependencies; store digests; hash artifacts; sign results.
Takeaway
The untrusted sandbox isn’t optional anymore—it’s the baseline for shipping agents with confidence. Start with default‑deny networking, ephemeral isolation, tight quotas, and auditable tool contracts. You can always relax controls later; it’s far harder to bolt them on after an incident.
Like nuggets like this? Subscribe to our weekly briefing: theainuggets.com/newsletter.
