Show HN: Fence – Sandbox CLI commands with network/filesystem restrictions

Yes, currently writes are deny-by-default, but reads are allow-by-default.

The challenge is that most programs need read access to system paths (/lib, /usr, /etc, /proc) just to run. A pure "deny all reads" mode would require users to figure out every dependency, which might be painful.

That said, a middle-ground would be reasonable, perhaps something like "defaultDenyRead: true" that blocks home/cwd/etc but still allows essential system paths, then lets you opt-in with "allowRead".

Curious what is your use case that makes deny-by-default reads more helpful? Either way, will file this as an issue.

That's acknowledged in the readme though I don't know if there is a comparison

https://github.com/Use-Tusk/fence?tab=readme-ov-file#attribu...

Yes, Fence is designed for exactly this, the built-in `code` template already allowlists npm and PyPI registries:

``` fence -t code pip install requests fence -t code npm install express ```

This restricts writes to workspace + cache dirs, blocks reading credentials, limits network to allowlisted domains, and blocks dangerous commands (`rm -rf`, `npm publish`, etc).

Thanks! And yeah, these are complementary layers. Fence is at the OS/network boundary, while API-level policies (endpoints, parameters, token budgets) need something that actually understands the protocols.

I think Fence should stay a thin wrapper around OS primitives (sandbox-exec, bubblewrap, Landlock), so not much beyond what it does today. The one extension that probably makes sense is basic resource limits (CPU, memory, fork bombs, etc). But API semantics and MCP tool restrictions belong in a different layer.

Unfortunately nested bubblewrap sandboxes don't work.

When you run `fence flatpak run <app>`, Fence creates a bwrap sandbox with its own user namespace, Flatpak then tries to create another user namespace inside, so you'd get something like `bwrap: setting up uid map: Permission denied`.

The outer sandbox doesn't grant the capability for nested namespace creation (otherwise it would defeat much of the security), so Fence can't wrap Flatpak (or similar namespace-based sandbox tools) in a useful way. Ideally you'd need something at the network level outside any sandbox.

That said, open to suggestions if anyone knows of a feasible solution.

Fair point, it does raise the bar! The distinction I'm drawing is between "semi-trusted" and "actively malicious".

Fence handles well supply-chain scripts that phone home, tools that write broadly across your filesystem, accidental secret leakage, the "opportunistic" stuff that makes up most real-world supply chain incidents.

I hedge on malware because: (1) Domain filtering relies on programs respecting HTTP_PROXY, and malware could ignore it (though direct connections are blocked at the OS level, so they'd fail rather than succeed), (2) OS sandboxes (sandbox-exec, bubblewrap) aren't VM-level isolation and I believe determined attackers could exploit kernel bugs, (3) there are no resource limits or content inspection.

The threat model is really "reduce blast radius from code you're running anyway". For a stronger containment boundary you'd want a proper VM.

More thoughts in the security model doc (https://github.com/Use-Tusk/fence/blob/main/docs/security-mo...) if you're curious!

- https://github.com/webcoyote/sandvault: sandboxes AI agents in a MacOS limited user account, and also uses sandbox-exec to limit access, though fence has more strict limitations

- https://github.com/webcoyote/clodpod: sandboxes AI agents in a MacOS virtual machine

Note: I’m the author of both of these Apache open-source projects

Fence works on macOS and Linux (the install script works for both platforms). I'll make that clearer in the README.