Every demo of an agent that “runs code” quietly skips the part that actually matters in production: where does that code run, and what can it touch? Simon Willison’s micropython-wasm experiment is worth attention precisely because it refuses to skip that question.

• 🎯 The real threat model isn’t the model writing buggy code — it’s that code executing with full privileges over your files, network, and secrets.
• ⚡ WASM plus MicroPython is a pragmatic pairing: a genuine Python runtime with no host filesystem or network access unless you explicitly hand it in.
• 🔍 The hard constraints are the boring ones — deny file reads, block outbound connections, cap memory and CPU — not the language semantics everyone obsesses over.
• ⚠️ Calling it a “vibe-coded sandbox” is refreshingly honest; an isolation layer you can’t reason about formally is a liability, not a feature.
• 💡 For agentic tool use this is the missing primitive: most frameworks expose a code-execution tool and wave away isolation as someone else’s problem.

This is the gap I keep hitting in production agent work — teams ship a code-exec tool, watch the eval numbers climb, and never write down what the blast radius is when the agent calls it on real data.

The HN discussion keeps circling the same uncomfortable point, and so do I: if your agent can execute arbitrary code, you don’t have a tool-use feature — you have an untrusted-code-execution problem you haven’t named yet. Who’s auditing the sandbox in your stack?