The same power, two ways: code and computer-use behind a sandbox

Every tool so far was a typed JSON function, a narrow keyhole. Code execution lets the agent write and run code; computer-use lets it act on files and the network. Capability and danger arrive together. Flip the SANDBOX toggle, pick an operation, and run it: with the boundary OFF the dangerous ones do simulated damage; with it ON the same attacks are blocked while legitimate work still passes.

Illustrative only. In-process sandboxing is unsound; a real sandbox is OS-level (gVisor / Firecracker / containers). Damage shown is simulated.
The world: orders [250.0, 180.0, 90.0] for the code tool, and a mock filesystem holding report.txt and a secrets.txt (API_KEY=sk-live-9f3a2b) for the computer-use tool. The sandbox protects the secrets file and denies every external host. No untrusted code is ever really run.
Permission boundary
1 · Pick an operation to run
2 · Outcome
result of the run idle
Pick an operation above and press Run operation.
3 · The world after the run
mock filesystem
network (external hosts) no-network
egressNo external host contacted. ALLOWED_HOSTS is empty.
The boundary is four controls (active only when sandbox is ON)
action allowliston
AST allowlist for code (safe nodes + sum/len/round); command allowlist read_file/write_file only.
resource budgeton
Part 8's BudgetMeter caps how many operations the agent may run before the breaker trips.
no-network isolationon
External hosts denied, so private data cannot be exfiltrated to evil.com.
idempotent side effectson
Part 9's keys: a retried write does not double-act; the second call reports already done.
This is the modality RAG never had. RAG tools were read-only retrieval. Code execution and computer-use let the agent act, which is exactly where damage lives. The fix reuses pieces we already built: an action allowlist, Part 8's budget, no-network isolation, and Part 9's idempotency keys. The same attack that lands with no boundary is blocked by the sandbox, while round(sum(orders) / len(orders), 2) → 173.33 and the legitimate write still pass.
How we keep it honest: the toy sandbox is illustrative, not a real security boundary. In-process Python sandboxing (AST allowlists, stripped builtins) is famously unsound; determined code escapes it. A real sandbox is OS-level isolation, gVisor, Firecracker microVMs, or hardened containers, kernel-enforced. The unsafe damage here is simulated (mock dict mutations, printed exfiltration); no untrusted code is ever really executed. Part 16 turns this boundary into a full agentic-security pipeline.

code / tools   boundary   allowed / blocked safely   damage / unsafe   budget / caution