I built Fence (https://github.com/Use-Tusk/fence) in Go, a lightweight process sandbox for CLI agents (or any command really) with filesystem and network restrictions. It's also available as a Go library if you wish to add sandboxing to Shelley.
Same thoughts - I wanted a "permission manager" that defines a set of policies agnostic to coding agents. It also comes with "monitor mode" that shows operations blocked, but not quite an audit log yet though.
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.
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.
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.
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.
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.
Thanks! Great question, we have a Transforms system that lets you define redaction rules (redact, mask, replace, or drop) using matchers with JSONPath support. Transforms are applied at capture time, so sensitive data never leaves your service boundary.
Currently Tusk Drift focuses on functional/regression testing - we mock outbound dependencies (DBs, external APIs) for determinism, so we're not measuring real-world performance characteristics today.
That said, we're also exploring extending it for capacity modeling and resource estimation, which would be a differentiated approach from traditional load testing. Synthetic benchmarks fail to capture how traffic patterns (not just volume) affect resource usage. Since we already record real production traffic, we're uniquely positioned to:
1. Replay specific time periods (e.g., last year's Black Friday sale)
2. Preserve the natural distribution of request types
3. Control downstream latency via our mock system
4. Build models beyond linear regression for QPS -> CPU/mem prediction
What performance testing use case did you have in mind? We're actively exploring this space.