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.