7 Sandbox Escape Vulnerabilities Across 4 Coding Agent Vendors
4 points by afogel
4 points by afogel
I feel very strongly that:
$HOME/Documents/Taxes/. You need to hide anything outside the working directory, and maybe some approved dotfiles.Unfortunately, while Linux supports this kind of sandboxing, actually setting it up requires some knowledge to configure actual, minimal permissions. And of course, a truly malicious and clever agent could find a kernel vulnerability and escape. But that's a more drastic threat model.
So these recommendations are not technically feasible in most environments, especially outside of custom Linux setups.
There's also the constant issue that agents are more useful when they have more rights. if you lock them down to not see the network, files and useful CLIs (with creds!) like the github cli or whatever; then they're kinda useless. So the system is pulling you away from good security practices and as you mentioned, Linux doesn't have easy sandboxing affordance. You can use containers or bubblewrap and socat like srt does but it's clearly not there yet.
Yeah, I use a custom bwrap+pasta wrapper that implements very specific policies. It also supports per-project customization. By default, I allow the agent to access the public internet, since it has no credentials in its sandbox anyway. So it can research or download stuff if it really wants, but it can't access reserved IPs (inside my firewall) or authenticate against anything. Not 100% secure, but a lot of effective security for little effort.
A simpler approach is just to give the agent it's own user account and let the OS treat it like an untrusted undergrad on a shared Unix host, like back in the old days. Or buy the agent a Mac Mini if you can afford it. The point is, security belongs in the environment. Not the harness!
100% agreed, I was hoping for WASM to actually become a capability based runtime for agents but it hasn't raised to the challenge that I know of.
You might be interested in https://github.com/danthegoodman1/tinysandbox, which I saw recently! It's a VFS (replaceable), a bash-like shell written in Rust, some common CLI utilities, a jq clone, and WASM-sandboxed JavaScript interpreter for running JS code in the sandbox. This isn't a solution for a general-purpose coding agent, but it's an interesting building block for agents which need a filesystem and a few throwaway scripts.
My shandbox script sets it up (by default) so $HOME/shandbox appears as $HOME within the sandbox environment, and you only expose what you choose to it. I find this gives something similar to creating a new user account without any file permissions hassle.
Yes, and if you plan to open the codebase outside of the sandbox:
.git/config or a filter driver.Yes. But the first rule of security is "understand your threat model." I am not trying to contain a hostile, Mythos-level model left unattended for hours. If Mythos wanted to, it would supposedly just find a kernel vulnerability and escape the Linux user namespace using some 3-step Rube Goldberg attack using 2 brand new zero days, and a backflip off a trampoline. Mythos should probably only be allowed shell access on a dedicated server in your firewall DMZ.
I am mostly trying to contain Qwen3.6 27B, which could charitably be described as a hard-working, well-intentioned idiot. And it's running in an environment where the damage is limited. So, yes, your points about editors and git are important for people to know before deciding on how to manage risks.
(You also need to keep in mind that most developers are still running npm install or pip install without a sandbox, which is getting less safe by the week. Unfortunately, this one is extremely hard to fix in many environments.)