Stupid question: what exactly is different about any of these tools than spinning a docker container programmatically and running the AI generated code inside it? What exactly are these tools solving that docker isnt?
Sandbox: Run untrusted AI code safely, fast
21–30 of 32 posts
Re: Sandbox: Run untrusted AI code safely, fast
#22Stupid question: what exactly is different about any of these tools than spinning a docker container programmatically and running the AI generated code inside it? What exactly are these tools solving that docker isnt?
A virtual machine is a much better security boundry than a container. Will that often matter… maybe not. I’m sure other tools wrap docker.
Re: Sandbox: Run untrusted AI code safely, fast
#23hello everyone, author here.
although this is self-hostable on gcp, they can get quite expensive due to the machines used. cheapest vm with nested virtualisation on gcp costs about $60/mo. on aws, you'd have to go with bare metal, which can cost you a lot more.
i think the next best thing for sandboxes is, "vm as a library", atleast for personal/small scale workloads.
Re: Sandbox: Run untrusted AI code safely, fast
#24Earlier quoted context omitted.
In the coderunner read me it talks about reading files without sending them to the cloud. Does that mean there is something agentic going on? That’s more than I expect from something called a sandbox. Also if it is agentic, why is it less cloud based than eg Claude code? Are there LLMs running locally?
Regarding files, they are volume mapped (local sandbox) as with docker. It's not agentic - agents can use it to execute code. Those agents can be powered by any LLM including local.
I’m still not sure why sending files to the cloud is supposed to be a disadvantage of other approaches but not this one. Whether you run your LLM’s commands in this sandbox or not, content is going to the cloud if the LLM is in the cloud, and not going to the cloud if the LLM is local. It looks like the amount of data in the cloud is entirely orthogonal to whether you use coderunner.
Re: Sandbox: Run untrusted AI code safely, fast
#25Stupid question: what exactly is different about any of these tools than spinning a docker container programmatically and running the AI generated code inside it? What exactly are these tools solving that docker isnt?
A virtual machine is a much better security boundry than a container. Will that often matter… maybe not. I’m sure other tools wrap docker.
and this was something everyone was parroting years ago, then we moved forward with docker saying it is capable of isolating deps without the overhead of a VM so why are we moving backwards now?
Re: Sandbox: Run untrusted AI code safely, fast
#26I really wish ollama had virtual sandbox where AI could run code.
Re: Sandbox: Run untrusted AI code safely, fast
#27Earlier quoted context omitted.
Out of curiosity, what would be an ideal UX for you? I'm working on a Rust library for this exact problem (CLI and language bindings should be easy to add). It uses KVM directly on Linux and Virtualization.framework on macOS, with a builder API for VM configuration. For AI sandboxing specifically, it has a higher-level "sandbox" mode with a guest agent for structured command execution and file I/O over vsock. You get…
I'm after this too. I want to have a "container" (used in the conceptual sense here - I'm aware of the differences between container and other solutions) that I can let an AI agent run commands in but is safely sandboxed from the rest of my computer. For me this is primarily file access. I don't want it inadvertently deleting the wrong things or reading my SSH keys. But the way the agent uses it is important too. The…
If you provide your own functions/tools to the AI agent, wouldn't that let you do exactly that?
ie "Here AI, call this function -> local_exec(commmand_name, {param1, param2, [etc]})" to execute functions.
And you'd wire up your local_exec() function to run the command in the container however you choose. (chroot, namespace, ssh to something remote, etc)
Re: Sandbox: Run untrusted AI code safely, fast
#28Earlier quoted context omitted.
Regarding files, they are volume mapped (local sandbox) as with docker. It's not agentic - agents can use it to execute code. Those agents can be powered by any LLM including local.
I’m still not sure why sending files to the cloud is supposed to be a disadvantage of other approaches but not this one. Whether you run your LLM’s commands in this sandbox or not, content is going to the cloud if the LLM is in the cloud, and not going to the cloud if the LLM is local. It looks like the amount of data in the cloud is entirely orthogonal to whether you use coderunner.
If you run your LLMs locally then nothing goes to the cloud. If you use cloud offerings then of course nothing is going to help you.
Re: Sandbox: Run untrusted AI code safely, fast
#29Earlier quoted context omitted.
I’m still not sure why sending files to the cloud is supposed to be a disadvantage of other approaches but not this one. Whether you run your LLM’s commands in this sandbox or not, content is going to the cloud if the LLM is in the cloud, and not going to the cloud if the LLM is local. It looks like the amount of data in the cloud is entirely orthogonal to whether you use coderunner.
If you run your LLMs locally then nothing goes to the cloud. If you use cloud offerings then of course nothing is going to help you.
I think their point is more that that architecture of this CodeRunner program isn't very clear.
It's unclear if it is a container manager, or comes with a LLM Agent built in. These are two separate concerns and the README makes it very unclear how to use one without the other.
Re: Sandbox: Run untrusted AI code safely, fast
#30Earlier quoted context omitted.
I'm after this too. I want to have a "container" (used in the conceptual sense here - I'm aware of the differences between container and other solutions) that I can let an AI agent run commands in but is safely sandboxed from the rest of my computer. For me this is primarily file access. I don't want it inadvertently deleting the wrong things or reading my SSH keys. But the way the agent uses it is important too. The…
If you provide your own functions/tools to the AI agent, wouldn't that let you do exactly that? ie "Here AI, call this function -> local_exec(commmand_name, {param1, param2, [etc]})" to execute functions. And you'd wire up your local_exec() function to run the command in the container however you choose. (chroot, namespace, ssh to something remote, etc)
This will work fine for bash commands, but most Agent implementations also have read/write file functions that are implemented using local file operations.