zlacker

[return to "Monty: A minimal, secure Python interpreter written in Rust for use by AI"]
1. imfing+Dv[view] [source] 2026-02-07 01:00:44
>>dmpetr+(OP)
This is a really interesting take on the sandboxing problem. This reminds me of an experiment I worked on a while back (https://github.com/imfing/jsrun), which embedded V8 into Python to allow running JavaScript with tightly controlled access to the host environment. Similar in goal to run untrusted code in Python.

I’m especially curious about where the Pydantic team wants to take Monty. The minimal-interpreter approach feels like a good starting point for AI workloads, but the long tail of Python semantics is brutal. There is a trade-off between keeping the surface area small (for security and predictability) and providing sufficient language capabilities to handle non-trivial snippets that LLMs generate to do complex tasks

◧◩
2. ushako+Cx[view] [source] 2026-02-07 01:19:51
>>imfing+Dv
there’s no way around VMs for secure, untrusted workloads. everything else, like Monty has too many tradeoffs that makes it non-viable for any real workloads

disclaimer: i work at E2B, opinions my own

◧◩◪
3. scolvi+Xy[view] [source] 2026-02-07 01:35:25
>>ushako+Cx
As discussed on twitter, v8 shows that's not true.

But to be clear, we're not even targeting the same "computer use" use case I think e2b, daytona, cloudflare, modal, fly.io, deno, google, aws are going after - we're aiming to support programmatic tool calling with minimal latency and complexity - it's a fundamentally different offering.

Chill, e2b has its use case, at least for now.

[go to top]