Show HN: Fence – Sandbox CLI commands with network/filesystem restrictions(github.com)
github.com
Show HN: Fence – Sandbox CLI commands with network/filesystem restrictions
https://github.com/Use-Tusk/fence
23 comments
I like it. Is it also possible to block all filesystem access and only allow certain directories / files?
Currently it seems to allow read access by default and only allows to block some paths with with "denyRead"
Currently it seems to allow read access by default and only allows to block some paths with with "denyRead"
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.
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.
pretty close to anthropic’s version, yes? or am I mistaken
https://github.com/anthropic-experimental/sandbox-runtime
https://github.com/anthropic-experimental/sandbox-runtime
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...
https://github.com/Use-Tusk/fence?tab=readme-ov-file#attribu...
Hey! Yes, Fence was inspired by sandbox-runtime. Both use the same underlying OS primitives (sandbox-exec on macOS, bubblewrap on Linux) and proxy-based network filtering.
Fence adds additional controls on top of what is available on sandbox-runtime:
- Command deny rules
- SSH command filtering
- Port exposure for inbound connections (useful for running dev servers inside the sandbox). This is a key reason why I decided to create Fence - because https://github.com/Use-Tusk/tusk-drift-cli spins up users’ services locally for trace replays and Fence helps to block unintended localhost outbound connections.
- Built-in templates for common developer workflows
- Better ergonomics for violation monitoring (`fence -m` gives you real-time violation logging on both macOS and Linux via eBPF, vs sandbox-runtime where Linux requires manual strace)
In summary, Fence layers extra permission-management features for wrapping popular CLI agents. If you just need filesystem + network isolation and you're in the Node ecosystem, sandbox-runtime is great. If you want command blocking, SSH filtering, inbound port exposure, or a standalone Go binary, Fence adds that.
Fence adds additional controls on top of what is available on sandbox-runtime:
- Command deny rules
- SSH command filtering
- Port exposure for inbound connections (useful for running dev servers inside the sandbox). This is a key reason why I decided to create Fence - because https://github.com/Use-Tusk/tusk-drift-cli spins up users’ services locally for trace replays and Fence helps to block unintended localhost outbound connections.
- Built-in templates for common developer workflows
- Better ergonomics for violation monitoring (`fence -m` gives you real-time violation logging on both macOS and Linux via eBPF, vs sandbox-runtime where Linux requires manual strace)
In summary, Fence layers extra permission-management features for wrapping popular CLI agents. If you just need filesystem + network isolation and you're in the Node ecosystem, sandbox-runtime is great. If you want command blocking, SSH filtering, inbound port exposure, or a standalone Go binary, Fence adds that.
Can fence wrap applications that do their namespace-based sandboxing?
This could allow finer control than the application's own sandbox offers. For example, Flatpak apps run in bubblewrap containers with all-or-nothing network permissions. Being able to restrict access by domain name would be useful.
This could allow finer control than the application's own sandbox offers. For example, Flatpak apps run in bubblewrap containers with all-or-nothing network permissions. Being able to restrict access by domain name would be useful.
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.
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.
Steam creates its pressure-vessel containers using namespaces, and there is a Steam flatpak, which I think was made possible by some work a few years ago specifically for the purpose of nesting. I don't know if that work applied to flatpak, bubblewrap, or both. It might be worth investigating.
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/t...
https://github.com/flathub/com.valvesoftware.Steam
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/t...
https://github.com/flathub/com.valvesoftware.Steam
Thanks. I was sure someone was going to make this sooner rather than later and this one seems relatively easy to configure.
I got tired of setting individual allow lists for each CLI, hopefully now I can run them all in Yolo mode while fence does the centralized sandboxing.
I got tired of setting individual allow lists for each CLI, hopefully now I can run them all in Yolo mode while fence does the centralized sandboxing.
Awesome, give it a spin and let me know if you have any feedback!
Thank you for sharing. Why do you say that it’s not strong protection against malware? Seems like it might be pretty handy there, at least with respect to untrusted code.
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!
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!
Nice, this was helpful for us internally. Good call on allowing importing of existing .claude/settings.json, makes my life easier on personal projects.
- can i run user submitted untrusted code in this? and can it do a pip install if user wants or an npm install?
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).
``` 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).
thank you for the response,
- how would you go about deploying this on an aws ecosystem? ec2 server? lambda? fargate?
- basically i want to run untrusted user code for many programming languages inside a sandbox and i am looking for solutions to do so
- need to be able to install libraries from pip, npm, cargo , just about any programming language's package manager
- how would you go about deploying this on an aws ecosystem? ec2 server? lambda? fargate?
- basically i want to run untrusted user code for many programming languages inside a sandbox and i am looking for solutions to do so
- need to be able to install libraries from pip, npm, cargo , just about any programming language's package manager
You can just install Fence in your deployed service (see the installation instructions in the README), then wrap the user command/script with `fence -t code <command>`. It will probably work fine in an EC2 instance but I'm not very sure about Fargate/ECS/Lambda.
The `code` template already allowlists npm, PyPI, crates.io, and Go modules, easy to extend for others by adding to allowedDomains in your config.
The `code` template already allowlists npm, PyPI, crates.io, and Go modules, easy to extend for others by adding to allowedDomains in your config.
Is there anything like this for macOS?
- 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
- 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.
Wow this is really cool
Nice work on Fence! The network/filesystem restriction approach is exactly what's needed for running untrusted commands safely.
We're working on similar containment problems but at the API/MCP layer at keypost.ai - enforcing what outbound calls an agent can make rather than what local filesystem/network it can access. The two layers complement each other well.
The "restrictions as code" pattern is powerful. Are you thinking about extending to other resource types (API calls, token budgets, etc.)?
We're working on similar containment problems but at the API/MCP layer at keypost.ai - enforcing what outbound calls an agent can make rather than what local filesystem/network it can access. The two layers complement each other well.
The "restrictions as code" pattern is powerful. Are you thinking about extending to other resource types (API calls, token budgets, 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.
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.
Fence wraps any command in a sandbox that blocks network by default and restricts filesystem writes. Useful for running semi-trusted code (package installs, build scripts, unfamiliar repos) with controlled side effects, or even just blocking tools that phone home.
> fence curl https://example.com # -> blocked
> fence -t code -- npm install # -> template with registries allowed
> fence -m -- npm install # -> monitor mode: see what gets blocked
One use-case is to use it with AI coding agents to reduce the risk of running agents with fewer interactive permission prompts:
> fence -t code -- claude --dangerously-skip-permissions
You can import existing Claude Code permissions with `fence import --claude`.
Fence uses OS-native sandboxing (macOS sandbox-exec, Linux bubblewrap) + local HTTP/SOCKS proxies for domain filtering.
Why I built this: I work on Tusk Drift, a system to record and replay real traffic as API tests (https://github.com/Use-Tusk/tusk-drift-cli). I needed a way to sandbox the service under test during replays to block localhost outbound connections (Postgres, Redis) and force the app to use mocks instead of real services. I quickly realized that this could be a general purpose tool that would also be useful as a permission manager across CLI agents.
Limitations: Not strong containment against malware. Proxy-based filtering requires programs to respect `HTTP_PROXY`.
Curious if others have run into similar needs, and happy to answer any questions!