01
why a shared kernel is the whole problem
a container is a process with restrictions. it still calls into the same host kernel as everything else on the machine. one kernel bug that the guest can reach, and the restrictions are the only thing between hostile code and your host.
microsandbox does not share the kernel. every sandbox boots its own guest kernel inside a hardware-isolated microvm. code that breaks its kernel is still inside a virtual machine, held by the cpu's virtualization boundary, not by a syscall filter you hope is complete.
02
a real machine, not a stricter process
each sandbox gets its own kernel, process tree, memory, and filesystem, booted from the oci image you chose. it looks like a small computer because it is one.
there is no shared daemon running as root to compromise. the runtime starts the microvm as a child process and tears it down with the job.
microsandbox runs untrusted code in hardware-isolated microVMs with their own kernel. It is open source under Apache 2.0.
03
control what survives
stopping a local sandbox preserves its configuration and filesystem for the next start. removing it deletes sandbox-owned state. use snapshots when you want a reusable copy.
least privilege still matters. mounts, network policy, credentials, limits, and lifecycle settings decide what the guest can reach.
