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.)?
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.
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.
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.
Nice, this was helpful for us internally. Good call on allowing importing of existing .claude/settings.json, makes my life easier on personal projects.
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.)?
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 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"
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.
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!
Nice, this was helpful for us internally. Good call on allowing importing of existing .claude/settings.json, makes my life easier on personal projects.