From the README:
> Security model
> The sandbox runs inside WebAssembly with WASI for a minimal syscall interface. WASM provides memory isolation by design—linear memory is bounds-checked, and there's no way to escape to the host address space. The wasmtime runtime we use is built with defense-in-depth and has been formally verified for memory safety.
> On top of WASM isolation, every tool call goes through capability validation: [...]
> The design draws from capability-based security as implemented in systems like seL4—access is explicitly granted, not implicitly available. Agents don't get ambient authority just because they're running in your process.
From "Show HN: NPM install a WASM based Linux VM for your agents" re: https://github.com/deepclause/agentvm .. https://news.ycombinator.com/item?id=46686346 :
>> How to run vscode-container-wasm-gcc-example with c2w, with joelseverin/linux-wasm?
> linux-wasm is apparently faster than c2w.
container2wasm issue #550: https://github.com/container2wasm/container2wasm/issues/550#...
vscode-container-wasm-gcc-example : https://github.com/ktock/vscode-container-wasm-gcc-example
Cloudflare Runners also run WASM; with workerd:
cloudflare/workerd : https://github.com/cloudflare/workerd
...
"Cage" implements ARM64 MTE Memory Tagging Extensions support for WASM with LLVM emscripten iirc:
- "Cage: Hardware-Accelerated Safe WebAssembly" (2024) https://news.ycombinator.com/item?id=46151170 :
> [ llvm-memsafe-wasm , wasmtime-mte , ]