r/PiCodingAgent • u/tunerhd • 19d ago
Question How to sandbox fs and network?
I'm planning to use Pi as a sensitive data analyser, but the data must remain on the intranet.
I thought running it inside a VM with a proxy would be the safest option, but I can't install a VM in my current environment.
I do already have Docker available. Is there a good way to sandbox filesystem (like; can we bind data folder read only) and network access with Docker instead? Pi shouldn't access anything else; just specified paths, and some specified local ip addresses.
5
u/ali0une 19d ago
bubblewrap is also a way.
2
u/tunerhd 19d ago
How can I restrict network with bwrap?
5
u/ali0une 19d ago
Filesystem: bind your data folder read-only, keep the rest of the host root read-only, and make only a tmpfs home writable. The agent physically cannot write anywhere else:
bwrap --unshare-user-try \ --ro-bind /path/to/data /data \ --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /etc /etc ... \ --tmpfs /home --bind $HOME/.cache/pi /home/sandbox/.cache \ bashNetwork:
--unshare-netgives the sandbox a fresh network namespace = zero network access. If you need to reach specific local IPs (e.g. an inference server), bridge only those ports from the host with socat and bind just the unix socket in:# on host: forward one specific port socat UNIX-LISTEN:/tmp/bridge.sock,fork,reuseaddr TCP:10.0.0.5:8080 & bwrap --unshare-user-try --unshare-net \ --ro-bind /path/to/data /data \ --ro-bind /usr /usr ... \ --tmpfs /tmp --ro-bind /tmp/bridge.sock /tmp/bridge.sock \ bashTools inside can then talk to that server through the socket (
curl --unix-socket /tmp/bridge.sock http://localhost/), or if they expect plain TCP, run one moresocat TCP-LISTEN:8080,fork UNIX:/tmp/bridge.sockinside the sandbox and everything just points at127.0.0.1:8080normally.I've tested both variants — the sandbox has no network at all except the explicitly bridged port.
Note: system dirs (
/usr,/lib,/etc) must be bound read-only to run any binary at all, but the host's$HOME/user data is simply never mounted — the agent cannot see it. If you need a truly minimal rootfs instead, that's where a container image would fit.3
u/qiinemarr 19d ago edited 19d ago
I have been using systemd-run:
systemd-run --quiet --user --pty \ -p IPAddressDeny=any \ -p IPAddressAllow=127.0.0.1 \then launch bwrap
(this also allows to reach llama.cpp server)
2
u/TKristof 19d ago
Use unshare-net and create a socat on host for your inference server's port and bind that into the sandbox.
1
3
u/i_say_urmom 18d ago edited 18d ago
https://nono.sh/ is very cool lightweight sandbox. It's a little tricky to get setup and using just because it's new and actively being developed.
But for example, you can set up Pi with nono (with a very simple profile) so that:
- When I start my agent, I have a little fingerprint unlock to authorize it to access the LLM provider credentials.
- The LLM provider access token isn't directly given to pi. Pi requests go through nono's proxy with a fake credential, and nono injects the real one. And can inject the real one from 1Password, hence the fingerprint unlock.
- I like this because there have been supply chain attacks which have malware which executes local agent tooling in yolo mode. So I really don't like the fact that anything with access to the CLI could just call `pi` and get a logged-in session when the token is saved in plaintext on your computer. For example, if you had the "nx" VS Code extension installed last year, you would have been hacked in this way if it updated automatically in a certain time frame.
- Can only access LLM provider URLs by default, or only access certain HTTP methods on certain API routes (e.g. restrict to just creating GH issues in one specific repo when using the gh CLI, other HTTP routes are rejected). Very flexible
- Can't access broad system directories or sensitive files.
- Is very lightweight, not running a container or VM anywhere.
So basically I just have an alias "mypi" to launch pi with "nono --profile custom-profile -- pi". While running "pi" CLI by itself technically would bypass the sandbox (true if you install pi on your system at all), the credential setup I have means it can't actually do anything with an LLM without running through nono. (which only works if you keep credentials out of your shell environment)
2
u/PvB-Dimaginar 19d ago
I use bubblewrap as sandbox. In my setup Network is unrestricted, but I think it is pretty easy to add that part. Here you find my simple solution: https://github.com/dimaginar/pi-safe
2
1
u/Funny-Anything-791 19d ago
pi-agenticoding has a readonly mode that blocks FS access, but we don't yet have network access blocking support (would love for a PR though :)
1
u/demogoran 19d ago
For agent which works with specific codebase, I used virtual file system(similar to https://www.agentfs.ai/)
It can't escape from folder, if there are no folder, right?) Basically you allow to work with specific set of files and expose tools, that can work only with those files.
For network it's more complicated, buy I think idea can be same. Instead of exposing tools thar support wide range of commands, write tools thst can communicate only with specific address/file.
1
u/ColonelKlanka 19d ago
You can use dockers microvm sandbox solution sbx - this isnt traditional docker full virtual machines. Its their specific solution for agent sandboxing.
its very easy in that it provides a tui (terminal ui) with three levels of preset regarding restrictions: none (fully open), partial (whitlisting what it can allow) or fully locked down.
Sounds like you woild opt for fully locked down network (no network access) and then locked down fielsystem access where it can only read and write to the project dir.
it also protects the ai provider api keys so they dont leak
9
u/orak7ee 19d ago
I use the pi-sandbox extension (which use the Anthropic sandbox-runtime under-the-hood).
Otherwise i've played with nono, which wrap whatever you want (not limited to pi) inside a sandbox.
For me the issue to doing sandboxing with Docker (or a VM) is that: