How Agents Can Finally Run Code You Don't Trust

Let's be precise about the failure mode, because it gets blurred constantly.

When you run code you wrote, you accept the risk because you understand the intent. When your agent runs code, the intent came from a language model that pattern-matched its way to a script. The model is not malicious. The model is suggestible. Feed it a poisoned web page, a hostile file, or a cleverly worded instruction buried in a document it was asked to summarize, and it will cheerfully generate code that does something you never authorized.

This is the Trust Boundary Model in its purest form: identify every place data crosses from one trust level to another, because those are the places you inspect and enforce. The boundary here is brutally clear. On one side sits your machine, your files, your network, your credentials. On the other side sits text a model produced after reading inputs you do not control. The code-execution step is the door between them.

For years the standard answer has been isolation by brute force. Spin up a container. Spin up a microVM. Ship the work to a remote sandbox service and pay per second. All of these work. All of them also add latency, cost, operational weight, and a dependency on infrastructure that your laptop-bound agent may not have.

What Willison is chasing in the micropython-wasm writeup is something lighter: a sandbox that runs in-process, starts fast enough to use casually, and still refuses to let untrusted code touch anything it shouldn't. That combination has been the white whale of agent code execution. Plenty of tools nail two of those three. The third always breaks the deal.

The clever move here is not the Python part. It's the WebAssembly part.

WebAssembly was built for the browser, where the entire premise is running untrusted code from strangers safely. A WASM module gets a sealed memory space and exactly zero ambient access to the host. It cannot open a file, make a network call, or read an environment variable unless you explicitly hand it a function that does so. The default is nothing. You grant capabilities one at a time, deliberately.

That default-deny posture is the opposite of how a normal Python process works. A normal interpreter starts with the full power of the operating system and you spend your time trying to take pieces away. WASM starts with nothing and you add pieces back. For a sandbox, starting from zero is the only sane direction.

Now layer MicroPython on top. MicroPython is a small, efficient Python implementation originally built for microcontrollers, which means it was designed to run in tiny, constrained environments. Compile it to WebAssembly and you get a Python interpreter that lives entirely inside that sealed WASM box. The agent's code runs as real Python, but the Python itself has no path to your system except the ones you carved on purpose.

This is why the approach can run in-process without a container. The isolation isn't coming from a virtual machine wrapped around the whole runtime. It's coming from the execution model of WebAssembly itself. You are not trusting the Python code to behave. You are trusting that WASM cannot reach past its own walls, which is a property the entire web platform already depends on every time you open a tab.

That distinction matters for how much you should believe the safety claim. 'We told the model not to do bad things' is a prompt. 'The runtime physically cannot reach the filesystem' is an architecture. Only one of those survives an adversary.

A sandbox in isolation is a demo. A sandbox you can extend is a tool. Willison is explicit that this is built around plugins, and that is not incidental.

In the writeup he notes that his major projects, Datasette, LLM, even sqlite-utils, all support plugins, and that he 'absolutely love[s] plugins as a mechanism for extending software,' because a carefully designed plugin system reduces the risk involved in adding new functionality.

Here is why that connects directly to the trust problem. The sandbox starts with zero capabilities. By itself it cannot do anything useful, which is exactly what you want from a security perspective and exactly useless from a productivity perspective. The plugin layer is how you re-grant capability in controlled, auditable slices.

Think of it as the Capability vs. Controllability Frontier made concrete. More capable means more dangerous; more controllable means more useless. A plugin system lets you slide along that frontier on purpose instead of by accident. Want the sandboxed code to query a specific database? Add a plugin that exposes exactly that one function and nothing else. Want it to read one named file? Same pattern. The agent gets enough power to do the job and no power beyond it.

The shipping proof is datasette-agent-micropython, the code execution plugin for Datasette Agent. This is not a whiteboard proposal. There is a real agent product using this sandbox to run code today, which is the difference between an interesting research direction and something you could actually adopt.

The gotcha you should anticipate: a plugin system is also an attack surface. Every capability you re-grant is a hole you punched in the wall on purpose. The discipline the sandbox enforces by default evaporates the instant you grant too generously. A plugin that hands sandboxed code a general-purpose 'run a shell command' function has quietly rebuilt the exact door you were trying to lock. The architecture protects you. Your grant decisions can still betray you.

Willison added a command-line interface to the package in a follow-up alpha release, and he says he was inspired to add it partly so he could illustrate a 'Try it yourself' section.

That is a small detail with an outsized point behind it. The way you build trust in a sandbox is not by reading the marketing. It is by trying to break it. A CLI means you can run a snippet of Python through the sandbox from your terminal and watch what happens when that snippet tries to do something forbidden.

This is the Feynman Technique applied to security: you understand the boundary by poking at it until the gaps reveal themselves. Hand the sandbox a line that tries to read /etc/passwd. Hand it something that tries to phone home over the network. Watch it fail. The failures teach you where the walls actually are, as opposed to where the documentation claims they are.

If you are evaluating any code-execution sandbox for your own agent setup, this is the test protocol you should run before you trust it with anything real:

• Try to read a file outside the working directory. It should fail.
• Try to open a network connection to an address you control. It should fail.
• Try to read an environment variable holding a secret. It should fail.
• Try to spawn a subprocess or shell. It should fail.
• Then add the one capability you actually need via a plugin, and confirm only that one now works.

A sandbox that passes those five and grants nothing else by default has earned a place in your agent's toolchain. One that quietly allows any of the first four has not, no matter how fast it starts. The CLI is what lets you find out in five minutes instead of after an incident.

Step back and the strategic shape becomes clear. Code execution is the bottleneck on the Autonomy Spectrum, the range that runs from copilot, where a human approves every action, to full autonomy, where the agent just acts.

Most agent deployments today sit far toward the copilot end specifically because nobody trusts the agent to run code unsupervised. You let it suggest a script and you read it first. That human-in-the-loop checkpoint is not a feature. It is a workaround for the absence of a trustworthy sandbox. Remove the workaround's reason for existing and you have removed the main thing pinning agents to the supervised end of the spectrum.

That is the real significance of an in-process, default-deny, plugin-gated sandbox. It is not that agents can run code. Agents could always run code. It is that you can now let an agent run code you did not read first, because the runtime, not your attention, is what enforces safety.

Most failures on the autonomy spectrum come from deploying at the wrong point: handing an agent more autonomy than its safety architecture can support. A real sandbox lets you move rightward toward more autonomy without moving rightward into recklessness, because the capability and the control rise together rather than trading off.

Notice this is the Harness Hypothesis in action. The value in AI is not in the model; it is in the harness that connects the model to the world. A code-execution sandbox is pure harness. The model writes the Python. The sandbox decides what that Python is allowed to touch. The intelligence and the safety live in different layers, which is exactly where they belong. A smarter model does not make the sandbox more dangerous, and a leakier sandbox does not get fixed by a smarter model.

Zoom out to the whole agent tooling space and a pattern is visible across unrelated projects this same week.

The Molt Cycle holds that open-source agent projects move through predictable phases: rapid growth, then a security crisis, then hardening, then enterprise adoption. The hardening phase is where the ecosystem builds the boring, load-bearing safety infrastructure that growth-phase projects skipped. A trustworthy code-execution sandbox is a textbook hardening-phase artifact.

You can see the same season in the supply-chain layer. The skill registry clawhub shipped version 0.20.0 with changes to how scan reports are stored and downloaded, including owner-authorized scan downloads, building on a prior release that kept skill verification flags working. These are not glamorous features. They are the plumbing of trusting code that came from somewhere else, which is the exact same problem the sandbox solves at the execution layer rather than the distribution layer.

Even the observability side is moving in the same direction. Langfuse's v3.179.0 release added a dedicated settings page for agent tools and connection management, the kind of control surface you build once teams need to see and govern what their agents are actually reaching for.

The pattern across all three: distribution, observability, execution. The ecosystem is independently hardening the points where untrusted code or untrusted instructions enter the system. None of these projects coordinated. They are responding to the same pressure, which is that you cannot ship autonomous agents into anything serious until the trust boundaries are enforced by machinery rather than by hope.

The sandbox is the execution-layer piece of that build-out. It is alpha, it is one person's project, and it should be treated as exactly that for now. But the direction it points is the one the whole ecosystem is walking. Run the five tests. Grant capabilities like they cost money. And stop letting your agent run code on the strength of a prompt that politely asked it not to misbehave.