> Older alternatives like sandbox-2 exist, but they provide isolation near the OS level, not the language level. At that point we might as well use Docker or VMs.

No,no, Docker is not a sandbox for untrusted code.

The example is:

    @task(name="analyze_data", compute="MEDIUM", ram="512MB", timeout="30s", max_retries=1)
    def analyze_data(dataset: list) -> dict:
        # Your code runs safely in a Wasm sandbox
        return {"processed": len(dataset), "status": "complete"}

Even defining semantics seems awkward, especially if one wants those semantics to simultaneously make sense and have any sort of clear security properties.

edit: a quick look at the source suggests that the output is deserialized JSON regardless of what the type signature says. That’s certainly one solution.

The gist dismisses sandbox-2 as “might as well use Docker or VMs” but IMO that misses what makes it interesting. The PyPy sandbox isn’t just isolation, it’s syscall interception with a controller in the loop.

I’ve been building on that foundation: script runs in sandbox, all commands and file writes get captured, human-in-the-loop reviews the diff before anything executes. It’s not adversarial (block/contain) but collaborative (show intent, ask permission).

Different tradeoff than WASM or containers: lighter than VMs, cross-platform, and the user sees exactly what the agent wants to do before approving.

WIP, currently porting to PyPy 3.8 to unlock MacOS arm64 support: https://github.com/corv89/shannot

> Python doesn't have a built-in way to run untrusted code safely. Multiple attempts have been made, but none really succeeded.

Long, long ago, there was "repy"[1][2]. (This is definitely included in the "none succeeded" bucket, FWIW.)

[1]: https://github.com/SeattleTestbed/repy_v2

[2]: https://dl.acm.org/doi/10.1145/1866307.1866332

I have been thinking about this myself, but am still not convinced about how to run untrusted Python code. I'm not convinced that the right solution is to run the code as WebASM [1].

I have been looking towards some kind of quick-start qemu option as a possibility, but the project will take a while.

[1] https://github.com/mavdol/capsule

As with most Python problems, the solution is to switch to Tcl - https://www.tcl-lang.org/man/tcl9.0/TclCmd/interp.html#M44 :-)

> The thing is, Python dominates AI/ML, especially the AI agents space. We're moving from deterministic systems to probabilistic ones, where executing untrusted code is becoming common.

This is so true

Sharing my friend's startup for sandboxed code execution:

https://judge0.com/

Neither the article nor the README explains how it works.

How does it work? Which WASM euntime does it use? Does it use a Python jnterpreter compiled to WASM?

Edit: never mind, I read it wrong.

---

That is not save at all. You could always hijack builtin functions within untrusted code.

  def untrusted_function():
      original_map = map
  
      def noisy_map(func, *iterables):
          print(f"--- Log: map() called on {func.__name__} ---")
          return original_map(func, *iterables)
  
      globals()['map'] = noisy_map

Seems fine to me. I think you're going to take a huge performance hit by putting CPython into wasm. gVisor is mentioned as having a performance penalty but I'm extremely doubtful of that penalty (which is really on IO, which I expect to not be a huge deal for these workloads) being anywhere near the penalty of wasm.