Live data from Hacker News

Monty: A minimal, secure Python interpreter written in Rust for use by AI

github.com

41–50 of 179 posts

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#41

It is absurd for any user to use a half baked Python interpreter, also one that will always majorly lag behind CPython in its support. I advise sandboxing CPython instead using OS features.

How do I sandbox CPython using OS features?

(Genuine question, I've been trying to find reliable, well documented, robust patterns for doing this for years! I need it across macOS and Linux and ideally Windows too. Preferably without having to run anything as root.)

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#43

Is ai running regular python really a problem? I see that in principle there is an issue. But in practice I don't know anyone who's had security issues from this. Have you?

No one is going to let an LLM get prompted by end users to write python code I just run on my server, there's no real debate on that.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#44
post #37

Earlier quoted context omitted.

A big benefit of letting agents run code is they can process data without bloating their context. LLMs are really good at writing python for data processing. I would suspect its due to Python having a really good ecosystem around this niche And the type safety/security issues can hopefully be mitigated by ty and pyodide (already used by cf’s python workers) https://pyodide.org/en/stable/ https://github.com/astral-sh/…

(Pydantic AI lead here) That’s exactly what we built this for: we’re implementing Code Mode in https://github.com/pydantic/pydantic-ai/pull/4153 which will use Monty by default, with abstractions to use other runtimes / sandboxes. Monty’s overhead is so low that, assuming we get the security / capabilities tradeoff right (Samuel can comment on this more), you could always have it enabled on your agents with basically…

lol "agents are better at writing code that calls MCP, then using mcp itself"

In hindsight, it's pretty funny and obvious

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#45
post #40
post #35

Earlier quoted context omitted.

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

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.

we’re not disagreeing here - i meant for general use-case VMs are better, for some application-specific calls Monty this might suffice.

although you’d still need another boundary to run your app in to prevent breaking out to other tenants.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#47
post #43

Is ai running regular python really a problem? I see that in principle there is an issue. But in practice I don't know anyone who's had security issues from this. Have you?

No one is going to let an LLM get prompted by end users to write python code I just run on my server, there's no real debate on that.

i think there’s a confusion around what use-case Monty is solving (i was confused as well). this seems to isolate in a scope of execution like function calls, not entire Python applications

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#48
post #37

Earlier quoted context omitted.

A big benefit of letting agents run code is they can process data without bloating their context. LLMs are really good at writing python for data processing. I would suspect its due to Python having a really good ecosystem around this niche And the type safety/security issues can hopefully be mitigated by ty and pyodide (already used by cf’s python workers) https://pyodide.org/en/stable/ https://github.com/astral-sh/…

(Pydantic AI lead here) That’s exactly what we built this for: we’re implementing Code Mode in https://github.com/pydantic/pydantic-ai/pull/4153 which will use Monty by default, with abstractions to use other runtimes / sandboxes. Monty’s overhead is so low that, assuming we get the security / capabilities tradeoff right (Samuel can comment on this more), you could always have it enabled on your agents with basically…

"But MCP is still useful, because it is uniform"

Yes, I was also thinking.. y MCP den

But even my simple class project reveals this. You actually do want a simple tool wrapper layer (abstraction) over every API. It doesn't even need to be an API. It can be a calculator that doesn't reach out anywhere.

as the article puts it: "MCP makes tools uniform"

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#49

Monty is the missing link that's made me ship my rust-based RLM implementation - and I'm certain it'll come in handy in plenty of other contexts. Just beware of panics!

rlm-rs: https://crates.io/crates/rlm-rs src: https://github.com/synth-laboratories/Horizons

Please report any panics, we'll fix them!

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#50
post #5

I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…

[flagged]
Post reply on HN