←back to thread

MCP Run Python

(github.com)
173 points xrd | 1 comments | 15 Apr 25 11:09 UTC | HN request time: 0.267s | source
Show context
behnamoh ◴[17 Apr 25 15:27 UTC] No.43718268[source]▶
So their method of sandboxing Python code is to spin up a JS runtime (deno), run Pyodide on it, and then run the Python code in Pyodide.

Seems a lot of work to me. Is this really the best way to create and run Python sandboxes?

replies(11): >>43718335 #>>43718770 #>>43718841 #>>43719300 #>>43719370 #>>43719672 #>>43719881 #>>43721408 #>>43722369 #>>43723869 #>>43726452 #
redleader55 ◴[17 Apr 25 19:53 UTC] No.43721408[source]▶
The author states:

> The code is executed using Pyodide in Deno and is therefore isolated from the rest of the operating system.

To me personally, the premise is a bit naive - it assumes that deno's WASM VM doesn't have exploits, that pyodide doesn't have bugs, etc. It might as well ask the LLM to produce javascript code and run it under deno and then it would be simpler.

In the end, the problem is one of risk budget. If you're running this in a VM you control and it's only you running your own prompts on it, maybe it's "good enough". If on the other hand, you want to sell this service to others who will attack your infrastructure, then no - it's not even close to be enough.

Your question is a bit vague because it doesn't explain what "best way" means for you. Cheap, secure, implementable by a person over a weekend?

replies(2): >>43721735 #>>43723543 #
1. fragmede ◴[17 Apr 25 20:17 UTC] No.43721735[source]▶
The answer, I think, is to push running the VM back onto the user, and build on top of Fabrice's JS Linux and run the sandbox on the user's machine. That way at the very worst they can escape and steal their own cookies from the browser process the VM is running on/in.