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.
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.
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.
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.
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.
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?
13 comments
[ 0.16 ms ] story [ 16.4 ms ] threadbut basically..containers, virtual machines. chroot/bsdjails. lots of options, each with their own caveats.
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.
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.
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.
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.