"Perfection is finally attained, not when there's nothing else to add, but when there's nothing else to remove"

- Antoine de Saint-Exupéry

The "permissions as access/visibility" is unfortunately not holding up in practice. As nice as a simplification like this would be: No one wants to configure up front what permissions are needed. Users will run into annoyances and then just overcommit resource access the same way they choose to run yolo mode. Limiting access for security is a great part of a capability based system but a system that will be used in the way intended needs the following properties, which are mostly missing from the tools we have (apparmor, seccomp, oss VMs, seatbelt, docker, bubblewrap etc.)

- pause execution for a policy engine or user input

- variable scope permissions independent of what was requested. eg user needs to allow just this request to /test/myfile.txt or grant /test/* in that moment

- add (ideally also remove) capabilities based on dynamic user input or engine decisions without up front configuration

- not need application support, if apps need to support it the moment the harness uses an external tool the model breaks

deno, workerd and maybe a vm/docker solution with an webdav proxy mount and web-proxy are the only environments i am aware of where systems like this could be build at all, even there, with limitations. (Not writing this to sound absolute but to learn about other options I am missing.)

Unfortunately this has all the hallmarks of AI writing, which made me a lot less motivated to read it.

> The agent inside the container runs with bypassPermissions — it can use Bash, write files, do whatever it wants. But "whatever it wants" is constrained by what the OS lets it see. No application-level permission checks needed.

While containers can be useful for reducing privileges, that assumption isn’t safe, remember that the only thing namespaces away is that which supports namespaces and that by themselves, namespaces are not security features.

A super critical part I didn’t see or missed is the importance of changing UID, the last line of [0] will show one reason.

Remember that the container users has elevated privileges unless you the user explicitly drop this privileges.

I applaud the effort at hardening, but containers have mostly been successful because the most popular apps like nginx operate under a traditional cohosting system and take responsibility for privilege dropping.

There are tons of kernel calls, ldpreload tricks etc… that are well known and easily to find with exploration.

Even dropping elevated privileges and setting no new priv, still isn’t a jail.

Without using separate UIDs don’t expect any real separation at all.

[0] https://www.kernel.org/doc/html/latest/admin-guide/namespace...

I really like solving the prompt injection credential exfiltration risk by never giving the container real keys in the first place. I wonder how prolific that pattern will become.

It's been about a month since I last looked at nanoclaw, but comparing with openclaw seems silly. It's like comparing pi.dev with Claude Code. nanoclaw has a lot fewer capabilities than openclaw, with the expectation that you'll essentially build your own features on top of it (and likely end up as buggy as openclaw).