Really nice approach using macOS native sandboxing! The deny-by-default with targeted allows for project folders is the right model.
To answer your question about network sandboxing: yes, it's arguably the more critical half. Filesystem damage is recoverable (backups, git), but credential exfiltration is not. The "lethal trifecta" for agent security is untrusted input + tool access + external connectivity. Your tool addresses #2 beautifully; network controls would complete the picture.
A few thoughts from building similar protections:
1. Network egress by hostname is more useful than blanket deny. Agents legitimately need to hit LLM APIs, but a compromised agent shouldn't be able to POST to arbitrary endpoints. Little Snitch integration could work here, or a simple proxy allowlist.
2. Credential injection timing matters. The Deno Sandbox approach (secrets as placeholders until request time, only injected for approved hosts) is clever for preventing exfiltration even if the agent is compromised.
3. The sandbox-exec deny log UI is gold. Making blocked actions visible is what lets users actually adopt restrictive policies instead of disabling them when something breaks.
One edge case to consider: agents spawning subprocesses (npm install, pip, brew) that need different rules than the parent. Per-command policy inheritance gets tricky.
Would love to see this pattern on Linux too - Landlock + seccomp could achieve similar results.
I understand this macOS based. Do you think it can be ported to Linux (my intuition tells me this very macOS-specific, but maybe I am missing something)?
The same concept is possible on Linux, but I don't think anyone has created a nice UI for it yet. There was a post yesterday about doing it on the command line in linux:
https://news.ycombinator.com/item?id=46874139
One of the nice things in Multitui is that it monitors what is blocked and gives you a way to add a read/write rule from the UI.
Really nice approach using macOS native sandboxing! The deny-by-default with targeted allows for project folders is the right model.
To answer your question about network sandboxing: yes, it's arguably the more critical half. Filesystem damage is recoverable (backups, git), but credential exfiltration is not. The "lethal trifecta" for agent security is untrusted input + tool access + external connectivity. Your tool addresses #2 beautifully; network controls would complete the picture.
A few thoughts from building similar protections:
1. Network egress by hostname is more useful than blanket deny. Agents legitimately need to hit LLM APIs, but a compromised agent shouldn't be able to POST to arbitrary endpoints. Little Snitch integration could work here, or a simple proxy allowlist.
2. Credential injection timing matters. The Deno Sandbox approach (secrets as placeholders until request time, only injected for approved hosts) is clever for preventing exfiltration even if the agent is compromised.
3. The sandbox-exec deny log UI is gold. Making blocked actions visible is what lets users actually adopt restrictive policies instead of disabling them when something breaks.
One edge case to consider: agents spawning subprocesses (npm install, pip, brew) that need different rules than the parent. Per-command policy inheritance gets tricky.
Would love to see this pattern on Linux too - Landlock + seccomp could achieve similar results.
I understand this macOS based. Do you think it can be ported to Linux (my intuition tells me this very macOS-specific, but maybe I am missing something)?
The same concept is possible on Linux, but I don't think anyone has created a nice UI for it yet. There was a post yesterday about doing it on the command line in linux: https://news.ycombinator.com/item?id=46874139
One of the nice things in Multitui is that it monitors what is blocked and gives you a way to add a read/write rule from the UI.