Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's discuss sandbox isolation

shayon.dev

Post reply on HN
Print view View original

51–60 of 75 posts

Re: Let's discuss sandbox isolation

#51

Post by athrowaway3z »

pash wrote: post #3

OK, let’s survey how everybody is sandboxing their AI coding agents in early 2026. What I’ve seen suggests the most common answers are (a) “containers” and (b) “YOLO!” (maybe adding, “Please play nice, agent.”). One approach that I’m about to try is Sandvault [0] (macOS only), which uses the good old Unix user system together with some added precautions. Basically, give an agent its own unprivileged user account and…

Dedicate user account.

That's not to say I don't use bwrap.

But I use that specifically to run 'user-emulation' stories where an agent starts in their own `~/` environment with my tarball at ~/Downloads/app.tar.gz, and has to find its way through the docs / code / cli's and report on the experience.

Re: Let's discuss sandbox isolation

#52

Post by adamgold7 »

We've been working on exactly this at Islo. Zero-setup microVM sandboxes with isolated networking by default, plus an approval workflow layer so agents can request capabilities and humans approve/deny in real-time.

The credential problem is handled through proxy middleware - agents never see real tokens, requests get routed through policy-checked proxies that inject credentials only for approved operations.

Happy to share more: https://islo.dev

Re: Let's discuss sandbox isolation

#53

Post by pbowyer »

adamgold7 wrote: post #52

We've been working on exactly this at Islo. Zero-setup microVM sandboxes with isolated networking by default, plus an approval workflow layer so agents can request capabilities and humans approve/deny in real-time. The credential problem is handled through proxy middleware - agents never see real tokens, requests get routed through policy-checked proxies that inject credentials only for approved operations. Happy to…

Is there only a cloud-based mode for Islo, or can I run this entirely on my laptop?

Re: Let's discuss sandbox isolation

#54

Post by mentalgear »

diacritical wrote: post #13
grouchypumpkin wrote: post #10

QubesOS was built to give sandboxes kernel isolation via a hypervisor. It’s not surprising that most people don’t know about it, because QubesOS as a daily driver can be painful. But with some improvements, I think it’s the right way to do it.

Just posted about Qubes a minute after you did, but I don't find it painful or even time consuming. Initially there was a learning curve, but even if the security of Qubes became the same as the security of a baremetal OS, I would still use it. When I'm trying to get some software up and running, I've had issues with Debian many times, as well as with Fedora. Rarely with both. With Qubes after a few minutes of trying…

This is great insight - using Qubes as a "Super-OS" over other OSes. How does it fly performance-wise, what HW are you on or recommend ?

Re: Let's discuss sandbox isolation

#55

Post by mentalgear »

diacritical wrote: post #11

Is there anything more secure than Qubes, assuming enough hardware resources? I'm asking about existing solutions, not theoretical ones. Given its track record so far, I'm betting not, but I'd love to be proven wrong. Adding sandboxing within a VM or hardening it should add more security, but overall I think this is the right approach for anyone who can afford a decent computer. The attack surface of Xen, the current…

Took a quick look, and indeed sounds like QubesOS is the ultimate sandbox for developers in the age of LLMs.

Re: Let's discuss sandbox isolation

#56

Post by shayonj »

lox wrote: post #46

It's amazing how many different implementations of sandboxes have popped up in the past few weeks. I'm CTO at Buildkite, have been noodling on one with a view to have an environment that can run CI workloads and Agentic ones https://github.com/buildkite/cleanroom

Heya! nice to see you here. In retrospect it feels like CI companies and environments are very well suited for sandboxes since a lot of the problems overlap around ephemeral workloads, running untrusted code, fast cold starts, multi-tenancy isolation. Also, loved Buildkite at a past job! Looking forward to following cleanroom

Re: Let's discuss sandbox isolation

#57

Post by shayonj »

m132 wrote: post #30

> The trade-off versus gVisor is that microVMs have higher per-instance overhead but stronger, hardware-enforced isolation. Having worked on kernel and hypervisor code, I really don't see much of a difference in terms of isolation. Could you elaborate on this?

Yeah, it's hard to hit the right balance with nuance around these and you're spot on. What I meant to get at was the specific difference in default modes where gVisor's systrap intercepts syscalls via seccomp traps and handles them entirely in a user-space Go kernel, so there's no hardware isolation boundary in the memory/execution sense. A microVM puts the guest in a VT-x/EPT-isolated address space, which is a qualitative difference in what enforces the boundary (perhaps?)

Whereas yeah, you can run gVisor in KVM mode where it does use hardware virtualization, and at that point the isolation boundary is much closer to a microVM's. I believe the real difference then becomes more about what's on either side of that boundary where gVisor gives you a memory-safe Go kernel making ~70 host syscalls, a microVM gives you a full guest Linux kernel behind a minimal VMM. So at least in my mind it comes down to a bit of around different trust chains, not necessarily one strictly stronger than the other.

Re: Let's discuss sandbox isolation

#58

Post by syrusakbary »

saghm wrote: post #47
syrusakbary wrote: post #6

Earlier quoted context omitted.

I also disagree with that. Wasmer can run now Python server-side without any restrictions (including gevent, SQLAlchemy and native modules!) [1] [2] Also, cool things are coming on the JS land running on Wasmer :) [1] https://wasmer.io/posts/greenlet-support-python-wasm [2] https://wasmer.io/posts/python-on-the-edge-powered-by-webass...

Is the support for Python code provided as a Rust library by any chance, where you could do something like pass in a simple python function, run it in wasmer, and then get back the result? I know a lot of complications would come into play around supporting C-based dependencies and support for the WASM APIs for stuff like I/O, but I recently was looking into this for a use case where the goal is to be able to prevent…

Not right now but we would love to provide it.

We have been super busy lately, but when we have a chance we will work on it!

Re: Let's discuss sandbox isolation

#59

Post by scosman »

beepbooptheory wrote: post #36
scosman wrote: post #20

Earlier quoted context omitted.

Shell over MCP, with multiple options for sandbox. Includes Docker, Podman, Modal, E2B, and WASM: https://github.com/Kiln-AI/Kilntainers Can run anything from a busybox in WASM to a full cloud VM. Agent just sees a shell.

This seems to be billed as a MCP server for making sandbox containers... right? Doesn't this kind of miss the whole point? "Make me a sandbox for yourself! Make sure its really secure!"

The sandboxing options are set when you connect the MCP to the agent, not by the agent passing params about its own sandbox.

There’s a misconception about the right security boundary for agents. The agent code needs secrets (API keys, prompts, code) and the network (docs, other use cases). Wrapping the whole agent in a container puts secrets, network access, and arbitrary agent cli execution into the same host OS.

If you sandbox just the agent’s CLI access, then it’s can’t access its own API keys/code/host-OS/etc.

Re: Let's discuss sandbox isolation

#60

Post by simonw »

saghm wrote: post #45
simonw wrote: post #2

I disagree with this section about WebAssembly: > But the practical limitation is language support. You cannot run arbitrary Python scripts in WASM today without compiling the Python interpreter itself to WASM along with all its C extensions. For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable. There are several versions of the Python interpreter that are compiled to WASM already - Pyodide ha…

Can you clarify what your disagreement is? The statement you're responding to seems to be that you can't necessarily run arbitrary code in arbitrary languages because it's only possible if the runtime is supported, and you're giving examples of two specific languages that had explicit extra work done to support them, which sounds pretty much exactly like what they're stating. From what I can tell, the point they're m…

It used Python as an example of why "For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable." - but Python in WASM works really well, as do other languages where the interpreter can be compiled to WASM.

So while the statement is technically true that you can't run "arbitrary code in arbitrary languages", the practical reality is that for many languages WASM is a great solution despite that.

Post reply on HN