[HN Gopher] Sandboxing AI Agents in Linux
       ___________________________________________________________________
        
       Sandboxing AI Agents in Linux
        
       Author : speckx
       Score  : 73 points
       Date   : 2026-02-03 17:35 UTC (5 hours ago)
        
 (HTM) web link (blog.senko.net)
 (TXT) w3m dump (blog.senko.net)
        
       | jauntywundrkind wrote:
       | Really well targeted!
       | 
       | I'd been thinking of using toolbox or devcontainers going
       | forward, but having to craft containers with all my stuff sounds
       | so painful, feels like it would become another full-time job to
       | make containers
       | 
       | Bubblewrap & passing in a bunch of the current system sounds like
       | a great compromise!
       | 
       | I do wonder what isolation something like systemd-run can offer,
       | if that is enough.
       | 
       | Part #2 to me, I also want observability as to what the agent
       | changed. That was one place where containers are such a clear &
       | huge advantage! Having an overlay that contains the changes to
       | the filesystem is so explicit. There's also works like agentfs,
       | that offer a FUSE filesystem backed by Turso DB (sqlite
       | compatible).
        
         | dgl wrote:
         | > Part #2 to me, I also want observability as to what the agent
         | changed.
         | 
         | You could potentially combine https://github.com/binpash/try
         | with bubblewrap (I'm not sure how well they compose and as the
         | docs say it isn't a full sandbox).
         | 
         | The good (and bad because it's confusing and can lead to
         | surprises if misconfigured) thing about Linux containers is all
         | the pieces of containers can be used independently. The "try"
         | tool lets you use the overlay part of containers on your host
         | system, just like Bubblewrap lets you combine the namespacing
         | parts of containers with your host system.
        
       | athrowaway3z wrote:
       | I'm launching a SaaS to create yet another solution to the AI
       | Sandboxing problem in linux.
       | 
       | My friends and I have spent a lot of time quietly injecting
       | support down into the kernel without anybody raising a flag, and
       | we finally have the infrastructure in place to solve this
       | problem.
       | 
       | We have also poisoned all the LLMs training data with our
       | approach, so our marketing is primed and we wont even need to
       | learn Claude to use our tool.
       | 
       | We're planning a soft launch this month, or maybe next month.
       | Depending on how "in the vibe" (our new word for flow :) our team
       | gets.
       | 
       | We're calling it `useradd`.
       | 
       | Yes, the man page is intimidating, and the documentation is
       | terrible. But once you're over the learning curve, it puts your
       | machine into a kind of 'main frame' mode where multiple 'virtual
       | teletypes' and users can operate on the same machine.
       | 
       | DM me if you want a beta key.
       | 
       | ---
       | 
       | Sorry for the snark, but i cringe at the monuments to complexity
       | I see people building, at least this solution is relative simple
       | and free. Still, dont really see what it buys me.
        
         | tasuki wrote:
         | Well done. It took me all the way up to `useradd`...
         | 
         | Edit: too bad about your edit. The comment was just fine
         | without it.
        
           | athrowaway3z wrote:
           | I wrote my comment to vent my disdain for all the circus
           | projects filled with marketing blurbs and features lists for
           | their overengineered vibeslop.
           | 
           | OP is just sharing the cool utility he found, and how it
           | solved a problem for him.
           | 
           | It felt bad to leave them with the message they shouldn't
           | have, or that he's a big part of the problem.
        
             | senko wrote:
             | OP here, no worries, loved the comment and appreciate the
             | feeling :)
        
         | mystifyingpoi wrote:
         | `useradd` doesn't restrict network access.
        
           | kaffekaka wrote:
           | I have used a separate user, but lately I have been using
           | rootless podman containers instead for this reason. But I
           | know too little about container escapes. So I am thinking
           | about a combination.
           | 
           | Would a podman container run by a separate user provide any
           | benefit over the two by themselves?
        
         | senko wrote:
         | I love using different users for separating services I run on
         | the same box!
         | 
         | For development, I want to be able to access/run/modify/delete
         | the files alongside the AI agent. This can be done if groups
         | and group permissions are set correctly (and the agent
         | correctly chmods everything...), but that feels more fiddly
         | than just isolating it with bubblewrap, systemd, or whatever,
         | and preserving the uid/gid.
         | 
         | Just my 2c - it's great that we have options!
        
           | necovek wrote:
           | Hey Senko, did you consider using ZFS or BTRFS snapshotting
           | feature to simplify some of the things you need?
           | 
           | For GH auth tokens, you could also pull that outside the
           | sandbox, and have the agent push to a local clone exposed to
           | the host, and local host with no agent automatically push on
           | inotify inside the repo -- eg. agent has access to your
           | /agents/scratchpad/my-git-repo, and sync to actual git
           | hosting service like GH (or Launchpad ;) happens with simple
           | script outside it.
        
         | CuriouslyC wrote:
         | I get where this is coming from, and it's not a terrible
         | solution, but VMs are still better in terms of security and
         | isolation. Typical workstation systems are not designed to be
         | secure from their own users, and frontier models are going to
         | get scary good at cracking systems soon.
        
           | carsoon wrote:
           | Fully sandboxed VMs are more secure but not everyone is
           | looking for the most secure option. They are looking for the
           | option that works the best for them. I want to be able to
           | share my development environment with the agent, I have a
           | project with 30 1gb and one 30gb sqlite database. I back it
           | up daily and they can all be reconstructed from the code but
           | it takes a long time. When things change I don't want to have
           | to copy them into a separate vm bloating my storage and using
           | excess resources and then having to rectify them, I want to
           | be sharing the same environment with my agent so I can work
           | side-by-side.
           | 
           | I would rather just have the agent not accidentally delete
           | files outside of its working environment but I am not worried
           | about malicious prompt injection or someone stealing my code.
           | 
           | For me I see the LLM as a dumb but positive actor that is
           | trying to do its best but sometimes makes mistakes, so I want
           | to put training wheels on it while still allowing it to share
           | my working space.
        
       | ATechGuy wrote:
       | I will ask what I've asked before: how to know what resources to
       | make available to agents and what policies to enforce? The agent
       | behavior is not predefined; it may need access to a number of
       | files & web domains.
       | 
       | For example, you said: > I don't expose entire /etc, just the
       | bare minimum How is "bare minimum" defined?
       | 
       | > Inspecting the log you can spot which files are needed and bind
       | them as needed. This requires manual inspection.
        
         | aflag wrote:
         | Ask the agent to bubblewrap itself
        
         | senko wrote:
         | Article author here. I used trial and error - manual inspection
         | it is.
         | 
         | This took me a few minutes but I feel more in control of what's
         | being exposed and how. The AI recommended just exposing the
         | entire /etc for example. It's _probably_ okay in my case, but I
         | wanted to go more precise.
         | 
         | On the network access part, I let it fully loose (no
         | restrictions, it can access anything). I might want to tighten
         | that in the future (or at least disallow 192.168/16 and 10/8),
         | for now I'm not very concerned.
         | 
         | So there's levels of how tight you want to set it.
        
           | ATechGuy wrote:
           | > I feel more in control of what's being exposed and how
           | 
           | Makes complete sense. Thanks for your insights!
        
       | kernc wrote:
       | As a heads up and affirmation that the approach is correct,
       | here's a small shell bubblewrap wrapper that boils the command
       | line down to `sandbox-run claude --dangerously-skip-permissions`.
       | 
       | https://github.com/sandbox-utils/sandbox-run
        
       | aktuel wrote:
       | I like this approach for Nix: https://dev.to/andersonjoseph/how-
       | i-run-llm-agents-in-a-secu... It makes it also easy to give the
       | agent only access to the tools it actually needs.
        
       | muggesmuds wrote:
       | Would love this for MacOS
        
         | davidcann wrote:
         | My app does this on macOS! https://multitui.com
        
         | senko wrote:
         | There's https://code.claude.com/docs/en/sandboxing that uses
         | something called Seatbelt on Mac and bubblewrap (the same thing
         | I used here) on Linux.
         | 
         | No idea how customizable that is.
        
       | aflag wrote:
       | I don't know if I want to create an ad-hoc list of permissions.
       | What I would like would be something like take a snapshot of my
       | current workspace in a VM. Run claude there and let it go wild.
       | After the end of the session, kill the box. The only downside is
       | potentially syncing the claude sessions/projects. But I don't
       | think that'd be too difficult.
        
         | senko wrote:
         | > _take a snapshot of my current workspace in a VM. Run claude
         | there_
         | 
         | Sounds like docker + overlayfs might fit the bill, as long as
         | there's a base image that is close enough to what you need.
         | 
         | I don't think there should be One True Way how to run these,
         | everyone can set it up in a way that best fits their workflow.
        
           | ushakov wrote:
           | both Docker and bubblewrap are not secure sandboxes. the only
           | way to have actually isolated sandboxes is by using VMs
           | 
           | disclaimer: i work on secure sandboxes at E2B
        
             | senko wrote:
             | No disagreement from me. From the article:
             | 
             | > _Bubblewrap and Docker are not hardened security
             | isolation mechanisms, but that 's okay with me._
             | 
             | Edit to add: my understanding is the major flaw in this
             | approach is potential bugs in Linux kernel that would allow
             | sandbox escape. Would appreciate your insight if there are
             | some easier/more probable attack vectors.
        
             | its-summertime wrote:
             | Do you have more information on how to set up such VMs?
        
               | ushakov wrote:
               | for personal use, many ways: Vargant, Docker Sandbox,
               | NixOS VMs, Lima, OrbStack.
               | 
               | if you want multi-tenant: E2B (open-source, self-hosted)
        
             | gf000 wrote:
             | What about cgroups? I know they are not exactly analogous,
             | but to me that seems like a pretty decent solution.
        
         | secure wrote:
         | I recently blogged about how I do this using MicroVMs on NixOS:
         | https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-...
        
       | charcircuit wrote:
       | If you have ssh installed, with network access it can ssh
       | localhost to escape the sandbox.
        
         | senko wrote:
         | Don't give it access to your ssh keys!
        
           | charcircuit wrote:
           | Yes, it should have its own dedicated key instead of sharing
           | one of your own.
        
         | qwertox wrote:
         | You can consider these agents criminals, or treat them like
         | babies. Both can do harm for a while, but one offers a future.
        
         | dist-epoch wrote:
         | `ssh localhost` doesn't work for me. maybe because I have
         | enabled only key-based ssh and my user key is not in
         | authorized_keys? am I missing something?
        
           | charcircuit wrote:
           | You are right in that it would still need to authenticate.
        
       | Jayakumark wrote:
       | Saw something last week using bubblewrap as well in hn
       | github.com/Use-Tusk/fence
        
       | bigwheels wrote:
       | I use Leash [1] [2] for sandboxing my agents (to great effect!).
       | I've been very happy with it, it provides strict policy-level
       | control for all process-level + network-level activity, as well
       | as full visibility and dynamic runtime controls via WebUI. Way
       | better than bubblewrap imo.
       | 
       | I originally saw it here on HN and have been hooked ever since.
       | 
       | [1] Screenshot:
       | https://camo.githubusercontent.com/99b9e199ffb820c27c4e977f2...
       | 
       | [2] https://github.com/strongdm/leash
       | 
       | Fun fact: Do you know what container / sandboxing system is in
       | most widespread use? Not docker containers, certainly not
       | bubblewrap, and not even full VMs or firecracker. It's Chrome
       | tabs.
        
         | observationist wrote:
         | Using Chrome for anything seems like a security failure of
         | itself. It's got great features, but damn do they come at a
         | cost.
        
         | necovek wrote:
         | That's interesting, how does Chrome implement "sandboxing" in
         | Windows and MacOS? For Linux, does it use the same underlying
         | technology as Docker, Podman, LXD, LXC (cgroups,
         | namespaces...)?
         | 
         | Or is a custom "sandboxing" implementation not relying on
         | system level functions (eg. a VM with restricted functions)?
         | 
         | If the latter, I wonder if something like JRE or .NET CLR is
         | still out there in larger numbers, but obviously, Chrome does
         | have billions of users.
        
       | sylvinus wrote:
       | This is the way to go! On my side I've build a very small
       | `claude-vm` wrapper to run each instance in a VM with Lima:
       | https://github.com/sylvinus/agent-vm
        
       | enum wrote:
       | I just have an unprivileged secondary local account and do ssh
       | dummy@localhost.
       | 
       | Is this wrong?
        
       | jhancock wrote:
       | I've started using a container (podman) which is just for the AI
       | tools. I start it up for Codex etc and let it access to the
       | appropriate code directory outside the container.
       | 
       | Anyone else using this approach? Ideas on improvements?
        
       ___________________________________________________________________
       (page generated 2026-02-03 23:00 UTC)