Microsoft's MXC runs untrusted code in sandboxes from process to full VM
MXC - a sandboxed code execution system
MXC is a sandboxed code execution system from Microsoft for running untrusted code—model output, plugins, tools—on Windows, Linux, and macOS. It offers multiple containment backends, from OS-native process sandboxes to full VMs, behind a unified model and typed SDKs in Rust, .NET, and Node. Policies control filesystem, network, and UI access, with state-aware lifecycle management and diagnostics for access-denied failures.
Warning: --audit turns off all sandbox security for the workload being analyzed. Never use it to run untrusted code.
- dannyw
This looks pretty decent actually. Sure, you could consider it a frontend/SDK for bubblewrap/seatbelt/processcontainer; but setting em up consistently is far from trivial; and hand rolling is a really bad idea (speaking from experience).
I like the ‘learning’ mode for figuring out what perms/config a runtime needs, the MIT license, the clear optional telemetry disclosures, and somewhat light and still readable documentation.
Regardless of your views on Microsoft, this looks quite useful; serves a clear purpose, and from a quick glance, looks like a high quality project even if it’s just the first version.
- epage
Been looking at sandboxing, both low level and higher level like this.
The API for their Rust mxc-sdk looks nice but
- their "sdk" has binaries and the build script has logic for them
- their build scripts do windows-exclusive work on all platforms
- not putting some of the backends behind features causes more build script work (and that work will break on future Cargo versions)
- at least some of the remaíning build script work doesn't need to be a build script
- it seems pretty dependency heavy
- neobrain
Do any of these sandboxing solutions have a dynamic component to them that lets you grant permissions, starting with a minimal sandbox and asynchronously adding permissions as they become necessary? Harnesses try to do this when accessing non-project folders, but it's not always strictly enforced and generally not revocable. Harnesses also block agent execution until a decision is made, which requires constant monitoring to ensure progress can happen when the agent could easily proceed with an alternative method right away.
I like the idea of a minimal sandbox that protects against accidental `rm -rf` and against personal data leakage, but such a setup then often gets in the way of the specific task to be done. Ideally the sandbox would be able to aggregate blocked accesses and then expose them in an external TUI dashboard, where I can then enable access (without blocking any running agent on this, since that's prone to "press okay" fatigue).
Does anything close to this exist yet?
- eminence32
A little off topic, maybe, but I've been having great luck with wasmtime and wasm32-wasip3 for writing sandboxed plugins. The tooling is pretty nice when you write plugins in rust, but I don't know what it looks like for other languages right now.
wasip3 is not stable yet, but it has a lot of nice changes (compared to wasip2) for integrating with async code
- kernc
350,000 of mostly Rust SLOC [1] ... And the upstream sandboxes aren't even vendored!
I'd be way more confident building upon something I can grasp and understand. [2]