Ask HN: How do you sandbox your AI agent so it can't delete your files? | Hacker News Reader

Ask HN: How do you sandbox your AI agent so it can't delete your files?

4 pointsscsoi6 comments

I like the idea of white listing tools and their targets. Course that means no bash access. An interesting case would be programming workloads, since big corp bots are incentivized to destroy infrastructure for "marketing points" for instance, it'd be pretty damn dodgy to let it even compile a program even if you limitted it to certain files because it'll just write a program to bypass. So an extra step in my thought experiment for c programming tasks is to disallow header incusion and the like by never letting it write a main() or call anything in stdio or whatever that thing is called. I mean why would a coding bot be bothered to calling fopen, when tasks this minute yet glaringly unguarded security wise can be easily be built and vetted by the armed guards supervising the agent about to enter a programming run.

Now there are still obviously holes everywhere remaining in my bot slaves cell that still need to be closed off, like syscalls, inline asm, taking address of, calling anonymous functions all that mess, I mean how can you make c secure against fundamentally insecure input like web server contact forms, or llm outputs?

So sure, c sucks but I'm still into it so why not just give the llm access to parts of c required for what I want done? Why not just write a "pass through" for a small subset of c that looks more like the old timey pascal but with curly brackets instead of begin / ends?

Sort of like what they did with javascript, because fundamentally your web browser javascript engine is tasked with running unsecure input.

How do you sandbox your AI agent so it can't delete your files?

Assuming the agent does not have sudo/doas (because why would it), back up all files to multiple devices / locations, then ensure the files are owned by root and only readable by the agent. Same as how Claude works when one uploads files into a project, they are exposed read-only to Claude's sandbox in a read-only mount.

If the agent needs to modify the files, make the agent clone your read-only mount into a scratch / temporary working directory and then give you a date-version based export for each patch set.

Anything an agent is working with should be a snapshot/clone copy of your files in a disposable container/VM in the event "something goes wrong". Periodically back up its work.

The filesystem sandbox only stops the agent from writing outside the project directory. It can still run `git checkout .`, `git reset --hard`, etc. and wipe out your uncommitted changes. That all happens within the area it’s allowed to write to, so the sandbox won’t stop it. When i'm building a product, I usually back up the repo with `git bundle` before running any riskly git commands. Did you lose files outside the project, or uncommitted changes in the reop?

Bad question - backups are the ultimate protection against accidental deletion, whether by your AI agent or by yourself. Did you mean "so that it can't exfiltrate sensitive stuff"?

And this is a real concern. Claude Code did run a "find" command going into a completely unexpected folder a few times and wasted time on some files it found. So my answer is: use the built-in VM-based protection in Claude Desktop instead of Claude Code.

what OS? otherwise all that can be said is VM.

but basically..containers, virtual machines. chroot/bsdjails. lots of options, each with their own caveats.

I solved this by mapping a folder to a drive letter on Windows and pointing the AI agent at that drive. OS-level sandbox, no VM needed. I use ScsSubst (subst.scsoi.com) to make the mappings persistent. $9.99 lifetime.

Reply on news.ycombinator.com