The uncomfortable part is that "easy to turn on" and "enough for the threat" get sold as the same thing.

Self-sandbox APIs like this are real progress for trusted apps. You declare the paths and ports you need, call enable, and the process sheds everything else. For a static file server that is a clean win, even when the container is already locked down. Defense in depth should be cheap.

It is a different story for agent runtimes. An agent that can write code, install packages, and talk to the network is closer to "untrusted code with a goal" than "my service with a bug." Landlock and Seatbelt reduce filesystem blast radius. They do not give you a separate kernel, a clean network policy, or a place to kill the session when it starts escalating around a deny.

What I want from a sandbox API next is not more sugar on unveil. It is an honest matrix: which threats this layer stops, which ones it only slows, and which ones still need a microVM or a disposable host. Ease of use matters. So does not letting people confuse a good default with a security boundary.