Sandbox AI Agents Before They Delete Your Files

Two weeks ago, someone on HN reported their AI coding assistant rm -rf'd their home directory. Not a hypothetical. Real files, real data loss, real recovery nightmare.

The agent was trying to clean up a test folder. It got the path wrong.

We give AI agents filesystem access the same way we give house keys to strangers — full trust, zero verification, fingers crossed.

The Problem: YOLO Mode Is Default

Look at how you're using AI agents right now. Cursor. Aider. GitHub Copilot Workspace. Cline (formerly Claude Engineer).

They all work the same way:

1. You grant terminal access
2. Agent runs commands as YOU
3. Agent touches YOUR files
4. No undo button when it deletes the wrong thing

The only protection is "approve before execution" — which everyone disables after three prompts because it's annoying.

Stanford's Secure Computer Systems group just released JAI (Just Another Isolator) to fix this. It's filesystem sandboxing that doesn't suck.

What JAI Actually Does

JAI creates a sandbox where your working directory stays writable, but everything else is either read-only or hidden. Your agent can still install packages, run builds, and modify project files. It just can't touch ~/.ssh, wipe /Documents, or accidentally delete your git repos.

The magic is copy-on-write overlays. Your home directory looks normal to the agent. When it tries to modify a file, the change goes to a temporary overlay. Your original file stays untouched.

Here's the actual workflow:

# Instead of this:
cursor

# Do this:
jai cursor

That's it. One prefix. Same Cursor interface, same AI, same keybindings. But now it's running in a sandbox.

Three Modes, Three Threat Models

JAI has three modes because "isolation" means different things depending on what you're protecting against.

Casual Mode (Default)

• Home directory: Copy-on-write overlay. Agent sees everything, changes nothing.
• Process runs as: Your user (same UID).
• Working directory: Fully writable. Agent can modify project files.
• Use case: Quick coding tasks where you want to prevent accidental damage.

This is what I use for daily coding. If the agent tries to run npm install and it breaks, the break is isolated. My global npm packages stay intact.

Strict Mode

• Home directory: Empty. Agent gets a blank private home.
• Process runs as: Unprivileged jai user (different UID).
• Working directory: Still writable.
• Use case: Running untrusted code or installer scripts you didn't write.

I use this when testing AI-generated deployment scripts. If it tries to curl | bash something sketchy, the damage is contained to a throwaway user.

Bare Mode

• Home directory: Empty, but runs as your UID.
• Use case: NFS home directories where OverlayFS doesn't work.

Most people won't need this. It's for edge cases where your home is network-mounted.

Real-World Use Cases for Solo Builders

I've been testing JAI for two weeks. Here's where it's already saved me:

1. Running AI-Generated Deploy Scripts

I asked ChatGPT to write a deployment script for a Next.js app. It gave me a 40-line bash script with sudo, systemctl, and chown commands.

Old me: Read it carefully, hope I spot issues, run it.

New me:

jai bash deploy.sh

The script tried to overwrite my ~/.bashrc with a PATH modification. Because it was in a JAI overlay, my actual .bashrc stayed untouched. I fixed the script, ran it again, verified it worked, then ran it outside JAI.

2. Testing Agentic Workflows

I'm building a workflow where an AI agent crawls docs, generates test cases, and runs them in a local environment.

During development, the agent kept creating temp files in weird places. /tmp, ~/Downloads, random project folders. Tracking them down manually was a pain.

With JAI, all that mess stays in the overlay. When I'm done testing:

# See what changed
jai inspect

# Kill the session
exit

Overlay disappears. No cleanup needed.

3. Letting AI Refactor Without Fear

I had a 2,000-line TypeScript file that needed splitting into modules. I knew I should do it. I also knew there was a 30% chance I'd break something and spend an hour debugging imports.

So I didn't do it for three months.

Then I tried this:

jai cursor

Told the agent: "Split this file into logical modules. Move each function to its own file. Update all imports."

It did it in 90 seconds. I reviewed the changes, tested, and it worked perfectly.

If it had broken everything? I'd have exited the JAI session and lost nothing.

That psychological safety is huge. I'm now refactoring aggressively because I can test big changes without risking my working state.

What JAI Doesn't Protect Against

JAI is not Docker. It's not a VM. It's not a security guarantee for multi-tenant systems.

If you're sandboxing against a determined adversary, use a proper container or VM. JAI is for casual isolation — preventing accidental damage and limiting the blast radius when agents make mistakes.

That said, casual isolation covers 95% of what solo builders actually need. I'm not defending against nation-state attackers. I'm defending against rm -rf / with the wrong path.

How It Compares to Alternatives

Docker

Docker is great for reproducible builds. It's overkill for ad-hoc sandboxing.

To run an agent in Docker, you'd need to:

1. Write a Dockerfile
2. Build an image
3. Mount volumes correctly
4. Map your project structure
5. Deal with permission issues

JAI is one command. No setup, no config, no friction.

Bubblewrap

Bubblewrap is powerful. It's also a 40-flag invocation that requires you to manually assemble the filesystem view.

JAI wraps bubblewrap (and similar tools) with sane defaults. If you need custom sandboxing rules, use bubblewrap directly. If you want sandboxing that's easier than not sandboxing, use JAI.

Chroot

Chroot is not a security mechanism. Linux docs explicitly say it's not for sandboxing. It has no mount isolation, no PID namespace, no credential separation.

People still use it because it's easy. JAI gives you the ease of chroot with actual isolation.

How to Use It Right Now

Installation is one line:

curl -sSL https://jai.scs.stanford.edu/install.sh | bash

Then prefix any command:

# Sandbox Cursor
jai cursor

# Sandbox Aider
jai aider

# Sandbox a script
jai bash deploy.sh

# Sandbox a shell session
jai

For day-to-day use, I added this to my .bashrc:

alias cursor='jai cursor'
alias aider='jai aider'

Now "normal" is sandboxed. If I need full access, I use the full path: /usr/local/bin/cursor.

The Bigger Picture: Agents Need Guardrails

AI agents are getting more capable. They're also getting more autonomous.

Six months ago, AI agents were glorified autocomplete. Today, they're running multi-step workflows, executing shell commands, and modifying entire codebases.

The default security model — "trust the agent completely" — made sense when agents could only suggest code. It doesn't make sense now that they can delete files, install packages, and modify system configs.

JAI is the first serious attempt at sandboxing that's actually easier than YOLO mode. It's free software from Stanford's research group, not a VC-funded product with a freemium trap.

If you're using AI agents to build things, you should be using something like this. Not because AI is malicious. Because AI makes mistakes.

And mistakes with filesystem access are expensive.

What to Do Next

1. Install JAI: curl -sSL https://jai.scs.stanford.edu/install.sh | bash
2. Test it with your current AI coding setup: jai cursor or jai aider
3. Use it for one week
4. If nothing breaks, make it your default

If you run into issues, the JAI docs cover edge cases and advanced config.

And if you're building agentic workflows where AI modifies production systems? Use strict mode. Always.

Further reading: JAI official site | HN discussion (530 points)