It would be insane to run a full fledged Agent from your own accounts, with the same access as yourself. At the same time running it fully scoped inside a container/VM seemed a little bit too heavy handed to me and the Agent-as-user seems like a better fit for me right now. (I did run my coding agents inside a microVM for a while but ran into a few too many annoyances)

Claude’s auto mode classifier is probably the best ‘firewall’ out there right now, but it’s a non deterministic layer with a failure rate of 17%.

Why is "Allow Once" completely red, "Always allow" is black and "Deny" is muted red? Isn't the order of safety (descending) "Deny", "Allow Once" and "Always Allow"?

In any case, a proxy makes sense, just not for the reasons they give.

To be 100% clear, namespaces are not a security feature in themselves, but can be used to run processes with reduced privileges and improved isolation, but not for untrusted code.

A few reasons.

1) Kernel features explicitly need to support namespaces, and only the portions that support namespaces have increased isolation, any syscall, socket family, etc… can provide an attack vector for the global kernel.

2) The methods to further constrain processes like LSMs, SecComp, eBPF system calling typically are not implemented by common container images and are difficult for users to develop and deploy.

3) User namespaces have actually increased exposure to user data, if protecting the system itself because of the proliferation of capabilities(7)[0]. Capabilities were designed as a vertical slice of superior(root) user functionality, and the contract is much different than people expect[1][2] We will have to see where things go, but as far as untrusted code, no containers/namespaces/etc… are not sufficient at all. There are just too many holes in the shared kernel and several socket() based backends that are used through netlink etc… Here you can see just how insane the number of default capabilities are granted to every user right now.

     $ grep ^CapBnd /proc/$$/status
     CapBnd: 000001ffffffffff
     $ capsh --decode=000001ffffffffff
     0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore