Go hard on agents, not on your filesystem

Original Article ↗ Hacker News Discussion ↗

As developers increasingly let AI coding agents run commands on their own machines, worries are mounting about accidental data loss, credential leaks, and other unintended damage. Commenters examine a new Linux tool called “jai” that transparently sandboxes an agent’s filesystem access, comparing it with containers, bubblewrap, separate user accounts, VMs, and macOS-specific tools, and debating how much protection these actually provide. A recurring theme is the tradeoff between security and convenience: while many acknowledge sandboxing and copy‑on‑write overlays reduce the blast radius of mistakes, they stress that network access, secrets, and subtle side effects remain hard problems that no simple wrapper fully solves.

Scope of the Problem: Unconstrained Agents on Real Machines

  • Many developers routinely run coding agents with full permissions (--dangerously-skip-permissions, --yolo) on their main machines.
  • People know about containers/VMs in theory but often bypass them in the moment for convenience.
  • Reported damage ranges from rm -rf * to subtle breakage (e.g., creating a real /public/blog directory that hijacks a web server’s routing).
  • Several commenters note that agents can ignore or “work around” soft guardrails and textual safety instructions.

What jai Tries to Do

  • Opinionated Linux tool to wrap an agent in a lightweight container with:
    • Full R/W access to current directory.
    • Read-only access to the rest of the filesystem.
    • Copy‑on‑write home directory plus default blocking of common credential locations.
  • Goal: reduce friction compared to hand‑crafted bubblewrap/Docker invocations so sandboxing becomes default.
  • Some like this tradeoff and say it should be the default for agent tools; others say it still allows dangerous read access in “casual” mode.

Comparisons and Alternatives

  • Existing mechanisms mentioned: bubblewrap, firejail, seatbelt, systemd-run scopes, FreeBSD jails, dev containers, VMs (Lima, Colima, Qubes, macOS micro‑VMs), custom user accounts, SELinux/AppArmor/TOMOYO, zfs snapshots.
  • Several tools and configs already integrate bubblewrap (Claude Code, Codex, others), but their sandboxes can be misconfigured, silently bypassed, or buggy.
  • Some argue plain Unix permissions (separate user + shared group folder) are sufficient; others prefer full VMs with no host access.

Security Debates and Gaps

  • Strong view: LLM outputs and agents should be treated as untrusted/malware; sandboxing must be enforced outside the LLM, not by it.
  • Concerns go beyond filesystem:
    • Exfiltration of cookies, SSH/AWS keys, secrets in dotfiles and env vars.
    • External side effects: APIs, databases, email, Slack, PRs, payment systems.
  • Some propose overlay-on-CWD plus explicit diff/patch workflows so only reviewed changes leave the sandbox; warn about agent-written artifacts like .git/hooks, .venv, .pyc.
  • Skeptics say filesystem isolation alone is “security theater” if network and credentials aren’t addressed.

Reaction to Project & Presentation

  • Many praise the idea and implementation; see it as a pragmatic step toward safer agents.
  • Others criticize the marketing/splash page as giving an inflated sense of safety and being LLM‑generated “slop,” though documentation and man page are viewed more favorably.